Re: [Gimp-user] GIMP's equivalent of adjustment Layer in PS?
On Thursday 11 January 2007 13:46, Steve Thompson wrote: I guess that about says it all, right? We listen to our users, but adjustment layers is a pointless discussion. You're not listening. It's pointless because adjustment layer support is already in the roadmap. Need heard. Need understood. Approach to resolving need defined. Work toward that end in progress. What more do you want? You want Sven and company to drop everything else they're doing in order to implement adjustment layers RIGHT NOW, integrating this new feature into an architecture that will be immediately abandoned and replaced as soon as 2.4 is out the door? Doing what you seem to want will: 1. Delay 2.4 2. Delay the next, GEGL-based version which will... 3. Delay 8bpc support 4. Delay CMYK support 5. Delay a whole raft of other desireable features All so that you can have adjustment layers just a bit sooner -- maybe. Depending on the complexity of implementing adjustment layers in the current engine, it's entirely possible that you'll get your feature *LATER* than if you wait for the GEGL-based version!!! Sheesh. Even as a corporate developer, I'd get pissed off at a manager who tried to push that kind of stupid decision on me. Why would anyone be surprised that VOLUNTEER developers would get annoyed at similar pressure from people that have no authority over them, and are unwilling to help out? /rant Shawn. ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] GIMP's equivalent of adjustment Layer in PS?
On Monday 08 January 2007 23:10, Steven Woody wrote: in Photoshop, there is a tool 'adjustment layer', what's the equivalent in Gimp? thanks. GIMP doesn't have any equivalent. I believe it's in the plan for future releases. I know the new graphics engine will make adjustment layers very simple to implement, so I wouldn't expect to see them implemented before the new engine goes in, and I would expect them to be implemented very soon after. For now, you just have to make the adjustments directly on your image layer. I usually copy the image layer before applying an adjustment to it, in case I decide to remove the adjustment. Shawn ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
[Gimp-user] Suggestions for RAW workflows
Hi, This isn't strictly a GIMP question (although the GIMP may well be a component of the solution), but it seems likely that some of the people here will have some good ideas. I'm experimenting with various approaches to turning my RAW images into high-quality TIFF or JPEG files for printing and/or on-screen viewing, and I'm looking for suggestions from others who are doing the same thing on Linux. So far, I've found that using GIMP and the ufraw plugin, I can get conversions that are fairly nice in most respects. Manipulating the exposure and the curves in the ufraw dialog even allows me to take advantage of the greater contrast that the RAW format captures, compressing or stretching the dynamic range prior to converting to 8-bit color depths so that highlights aren't blown out and details aren't lost. There are a couple of problems, though. First, the ufraw plugin, and the dcraw program, seem to fall down in one respect: my converted images are often much noisier than the JPEGs produced by the in-camera processing. I shoot in RAW+JPEG so I have both, and in some cases I've been able to get a better final image out of the JPEG than the RAW, simply because of the noise issue. I have found that the GIMP 'selective gaussian blur' can be used to get rid of much of the noise, but it has to be used very carefully to avoid losing too much detail or distorting portions of the image. I'd like to find a less 'fiddly' solutuion. The second problem is that I'd like to print some of my images in relatively large sizes (11x14 or so), and it seems to me that if I want the best quality possible, it's not a good idea to convert to 8-bit color. Of course, that rules out using the GIMP to clean up noisy areas, since it doesn't yet support higher bit depths. Cinepaint doesn't have the selective gaussian blur filter, nor does ImageMagick. So, are there any other RAW photographers who use Linux or *BSD and want to share their photo processing workflow? Thanks, Shawn. ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Save For Web Option?
On Wednesday 05 April 2006 01:03, Mark Sargent wrote: am a rather experienced Linux user for the past 2yrs or so, but, not much with Gimp. I used to use Fireworks/Photoshop on Windows some time back, and am wondering where within Gimp I can just save as for web, and it allows me to resize etc. I can't seem to find that option anywhere in the menus. All I see is, save, save as, save a copy, save as template. I have a 14.5mb file that I need to get to under 500kb or less. Could someone point this non-gui fool in the right direction? Cheers. Well, if you're a non-gui fool, I'd suggest a non-gui tool. I'd use imagemagick, something like: convert infile.bmp -resize 500x500 -quality 75 outfile.jpg ImageMagick uses the file extension on the output to decide what type of image compression to use, so it will save as a JPEG. The -resize option by default will not stretch your image so the above will resize your image to be at most 500 pixels on each side. Finally the -quality is used by the JPEG compressor and takes a number between 0 and 100. Smaller numbers give you worse images, but 75 is a good tradeoff which gives you good image quality and good compression. You can easily play with the numbers to get larger or smaller image sizes. If you do want to use the GIMP (certainly not a bad choice), you should use Image-Scale Image to shrink the resolution down, then Save As and enter a file name with a .jpg extension. The GIMP will then prompt you for a quality level and if you click the Show Preview in image window you can see the effects of dragging it back and forth, and you can also see the file size right undernath the quality slider. Have fun, Shawn. ___ Gimp-user mailing list Gimp-user@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-user
Re: [Gimp-user] Poor print quality with GIMP on Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Monday 04 October 2004 10:04 pm, Shawn Willden wrote: Scaling is set to 100.0%. As Sven pointed out in private e-mail, I misstated here. That's what I get from going from memory. My goal is to avoid scaling (and the quality reduction that may occur), so what I've been doing is using the Use Original Image Size button and verifying that the Scaling is the right number of PPI (in PPI mode, not Percent mode). I have been seeing the blurriness without scaling up to the full size of the page, as would happen if Scaling was really at 100%. Shawn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBYrJE6d8WxFy/CWcRAgbQAJ9dSCT8qibquVtjQ5cxRfQBWZRBxACgkfzE Rn24Gv2L9ONiwTkLW3lBLbM= =fEUM -END PGP SIGNATURE- ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Poor print quality with GIMP on Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 (I hope you don't mind if I post this back to the list, Sven) On Tuesday 05 October 2004 09:04 am, you wrote: I have been seeing the blurriness without scaling up to the full size of the page, as would happen if Scaling was really at 100%. I have no idea what is causing your problems then. I have been told that the gimp-print drivers would create superb printouts. Perhaps you should ask your question on the gimp-print mailing-list. They should know better. The gimp-print project has it's homepage at http://gimp-print.sourceforge.net/. Well, I didn't post there because I'm not using the gimp-print drivers. The gimp-print drives don't support my printer, so I'm using the hpijs driver from HP. My assumption was that the print dialog and whatever it generates to send to the drivers is on the gimp application side, rather than on the gimp-print side, which I believe is only drivers. Is this not correct? Thanks, Shawn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBYs2M6d8WxFy/CWcRAuSQAJ9YhWHjDXdzcxUR27q8qwRG/a6fUwCfaHeb nzwUvnjYO6+ITYqwCE/EzmU= =sa0D -END PGP SIGNATURE- ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] Poor print quality with GIMP on Linux
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tuesday 05 October 2004 11:27 am, Sven Neumann wrote: I replied to the list (and to you) so the discussion has been on-list all the time... Apparently my filters are putting your replies in my Inbox, rather than in my GIMP folder. I'll have to look into why that is. Anyway, sorry for the confusion. The plug-in that ships with GIMP has been written by the gimp-print developers and it uses libgimpprint. So you are using the gimp-print drivers. I do not know exactly what the plug-in is doing in case of your setup. The gimp-print folks should know better. Okay, thanks. I'll take my questions over there. Shawn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFBYtxK6d8WxFy/CWcRAursAKCEXfxxTAdBxoQKom/+ZiVk+XvnFACgkzHb xU8/bHScEX8ZVTTzQ7ekVkk= =fNR5 -END PGP SIGNATURE- ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
[Gimp-user] Poor print quality with GIMP on Linux
I have an HP Photosmart 7260 printer which prints great photos when I print from other Linux applications, particularly KDE apps with kprinter. To get good photos I do have to explicitly set the printing mode in the driver settings, but it works well. It works well in every application *except* the GIMP, that is. The GIMP appears to do some rescaling and adjustment that makes the output look noticeably blurry. I've configured the GIMP to print through kprinter (with command kprinter -dPhoto --stdin) so that the kprinter dialog pops up and allows me to set the print mode. What's really annoying about the GIMP not printing nicely is that it makes printing photos a multi-step process. The image viewers I've tried print okay, but they assume 72dpi, rather than whatever I really want (usually 300dpi, but sometimes more or less, depending). So, my current process is to load the image in the GIMP, use scale image to adjust the dpi setting (usually without actually scaling the image) and then save the image as a postscript file. Then I can load the .ps file up in kghostview or whatever and it prints very nicely. Any ideas what I can do to fix this? I have the GIMP's Image/Output Settings set to all the defaults (Image Type: Photograph, Output: Type Color, all the parameters on the Adjust Output dialog to 1.000). I'm careful to ensure that I don't have to do any scaling from the print dialog, either... Scaling is set to 100.0%. What else... the printing system is CUPS v1.1.21rc1, the driver for the printer is Foomatic v3.0.2 + hpijs v1.6.2 (configured through the KDE printing manager) the system is Debian unstable, with a 2.6.8 kernel and the GIMP is version 2.0.5. Thanks for any suggestions, Shawn. pgpunbXcT9xLa.pgp Description: PGP signature
Re: [Gimp-user] Re: frontend to help classify images
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Saturday 08 May 2004 12:43 pm, Helge Hielscher wrote: On Sat, 08 May 2004 14:02:32 -0400, h121 wrote: Short: I'm looking for a front-end tool to help me process (qualify and classify / catalog) about 10,000 scanned images. You may want to have a look at KimDaBa. http://ktown.kde.org/kimdaba http://kde-apps.org/content/show.php?content=10065 I second the recommendation. A little more information: KimDaBa uses an XML file to store all of the image metadata. While this solution isn't ideal for huge image databases, because it has to load the entire metadata database into RAM to get reasonable performance, it will be just fine with only 10,000 images (I have about 7,000 images in mine). Once all of the metadata is in XML format, you can write a little code to put it in any other format you like. KimDaBa supports arbitrary classification schemes. Basically, you define a set of categories (you called them dimensions), and the values for each category. The image classification window is customizable, so you can arrange the defined categories for convenience. Though it may not be applicable for your application, you can also define groups within a category. Groups contain values or other groups. After images are categorized, you can drill down pretty much any way you like. Selecting one criterion, then another, then another, until you've identified the set of images you want, or at least narrowed it down far enough to make a manual search reasonable. KimDaBa will also allow you to mark up images, rotating them, drawing on them, etc., but all of the modifications are stored as metadata, without modifying the actual image file. When you display the photo with KimDaBa, the markup is visible, the image is rotated, etc. KimDaBa reads date/time and rotation data from EXIF, if available. One thing KimDaBa does not do (AFAIK) well is provide convenient ways to zoom in. Also, it's a bit slow to display each image. I think this is because it just uses the KDE image code to decompress and display images, and it isn't terribly fast. In a KDE photo manipulation tool I wrote, I had to resort to trading off some RAM to cache the last few and the next few images. I think JPEG decoding time was the biggest part of the problem, but frankly didn't look into it that much after I found an acceptable solution. Also, it sound like you might need something more flexible than KimDaBa's HTML generation for the final image database. One other plus, the primary author, Jasper Pedersen, is generally quite responsive, so if you can make a case that some need of yours is likely to be shared by others, he's likely to add your requested feature, and quickly. The code is reasonably clean also, so if you're a C++ programmer you can always look into adding whatever bits you need yourself. Shawn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAnUUIp1Ep1JptinARAhjxAJ9YBgjNoDPAd8QDkrYpLlkASqLQ0QCfR02P Py5ESlyHoy8ORMdB+0y5xP8= =YwRn -END PGP SIGNATURE- ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] How to treat several pictures at once?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Wednesday 04 February 2004 12:05 pm, Dirk Völlger wrote: Hi there, I am a new gimp user as well as a new list member. I have got the following question: I took a series of pictures (measures) and I have to normalize and equalize them to see any result. Is there any perl skript or smth. else that does this step with all the pictures I have because it is impossible to treat ~ 50 pictures seperately (no time ...) I have never used perl, so I also do not know how to use it with gimp. Any help, tutorial or hint would be cool because it is quite urgent. Assuming it can do the job (and it can do a lot of jobs), your best option is probably not the GIMP, but rather ImageMagick, which provides set of command line tools for doing all sorts of image operations. You mentioned normalizing and equalizing. To do that with ImageMagick, you would just run, e.g.: mogrify -normalize -equalize *.JPG Done! If you find that ImageMagick won't do it, then you should look into scripting the GIMP. I recommend writing your scripts in Python, but it really depends on what you're most comfortable with -- or most interested in learning. Shawn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQFAIc3ap1Ep1JptinARAmzaAJ9943rllPjruAJYqdAp+rOMEkbbVACfWPTz iwM+0yHuXJHILRbvMq74nMQ= =mw9v -END PGP SIGNATURE-
[Gimp-user] Channel Mixer for 1.3?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Has anyone ported the plugin? Or is there similar functionality elsewhere? Thanks, Shawn. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (GNU/Linux) iD8DBQE/vZQKp1Ep1JptinARAklaAJ9X8QT5OrtylczJMDFIubKfU+m+MACeIp0t KeZKkbEeTizUW2GbqOJwRok= =+IXX -END PGP SIGNATURE- ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
Re: [Gimp-user] RGB to BGR script works, but how to run auto levels?
On Sat August 30 2003 12:06 pm, Walter Francis wrote: I also run auto levels on the images when I'm done, but so far it looks like this is not possible from Script-fu. Any updates on there? I submitted a bug report (http://bugzilla.gnome.org/show_bug.cgi?id=119233) and a patch to add a PDB entry for auto levels. If you don't mind applying the patch and building the GIMP yourself, you should be able to get auto levels to work from your script. The patch is at: http://bugzilla.gnome.org/showattachment.cgi?attach_id=19053 Apply the patch to tools/pdbgen/pdb/color.pdb, then do the typical configure, make, make install process, taking care to add the --with-pdbgen option to the configure command line so the PDB code will be updated. If you're not comfortable with patching and building, you'll probably have to wait until the patch gets applied by the developers. If you use Debian, drop me a line and I'll send you patched versions of the Sid .deb files. Shawn. ___ Gimp-user mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-user
