Re: [Gimp-developer] jpeg quality factor.
On Sun, 08 Jul 2007 07:22:24 +0200, Guillermo Espertino [EMAIL PROTECTED] wrote: In Gimp, it saves the file directly, without asking for the compression setting. Result: an image over-compressed with artifacts. Smaller size than the original. In Photoshop, it shows the quality settings the first time you hit CTRL+S. I think we're finally getting closer to the truth. There is something non standard in the file the camera is producing. It seems that PS knows there's a problem and thus prompts for the quality parameter, gimp it would seem is either reading this value as the IJG quality when it isn't or is applying a not too good default when it fails to read it. If it's an incorrect value put in by the camera that gimp is correctly reading it's not a gimp issue. If it is a missing value gimp should probably use it's jpeg default of 85 (or prompt as you suggest) which it does not seem to be doing. If you have imagemagick installed, use the following to see what information is in one of your camera images before you affect it with either gimp or ps and then again after gimp (and/or PS) does a save on it: identify -verbose unadulterated_image.jpeg That should give some info on what is in the jpeg header. thx. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On 7/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Sat, 07 Jul 2007 21:38:57 +0200, Øyvind Kolås [EMAIL PROTECTED] wrote: the image used in the JPEG Generation Loss figure in the example in the following text uses an image that shows how JPEG compression keeps different aspects of the image intact across multiple encode/decode cycles: http://pippin.gimp.org/image_processing/chap_dir.html#id2526295 /Øyvind K. -- yes there does seem to be an issue here. I snipped the generation 0 part of that image did File | Save As... then reopened the new version and repeated the save several times. There is continual degradation. This should not happen with an identical image. This seems to suggest that either there is a bug in the compression or that the decompression is not producing an identical image from the stored data. This is not a bug but a consequence of how the lossy compression of JPEG works, hence you should NEVER should use JPEG as an intermediate format in your workflow, but only for publishing the end result. It is theoretically possible, to keep the compressed version of unchanged parts of an image around, and only recompressing in the neighbourhood of regions that have actually changed by comparing with JPEG that one is saving over. But a full decode/encode/decode cycle of JPEG / DV / MJPEG etc will accumulate more and more errors/artifacts. This accumulated error would be smaller with a higher default quality though. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Hi, On Sat, 2007-07-07 at 22:13 -0300, Guillermo Espertino wrote: Back to the topic: I propose to display the quality settings when an image is resaved as jpeg for the first time, if it's possible. I don't know how it's done, but when I take my image to PS from my camera, it asks me to adjust the quality when I press CTRL+S for the first time. After that it saves normally. Due to the way file plug-ins are implemented in GIMP, it is not trivial to do this. But you can easily work around it by assigning Ctrl-S to Save As. Then you will always be prompted with the dialog asking you for the save parameters. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On Sun, 08 Jul 2007 12:10:30 +0200, Øyvind Kolås [EMAIL PROTECTED] wrote: But a full decode/encode/decode cycle of JPEG / DV / MJPEG etc will accumulate more and more errors/artifacts. This accumulated error would be smaller with a higher default quality though. /Øyvind K. -- Obviously what Guillermo is doing is fine as an exercise but his first save should be to a non lossy format or if his first save is his final save at least use Save As to get the full dlg and save it to the same name if that's what he wants. Personally I would always keep any original image so even a 'first save = last save' would get a new name and hence go through the dlg with the quality option. You clearly know more about the detail of this than I do but isn't there a direct one-to-one mapping once the original compression is done? Any deviation from that must be errors in the decoding, so is what you posted a symptom of continual rounding errors in the decoding altering the image each time? Then the growing artifacts are a result of the limited colour resolution of 8 bits per channel used by gimp. Thx /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On 7/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: You clearly know more about the detail of this than I do but isn't there a direct one-to-one mapping once the original compression is done? Nope. Any deviation from that must be errors in the decoding, so is what you posted a symptom of continual rounding errors in the decoding altering the image each time? Then the growing artifacts are a result of the limited colour resolution of 8 bits per channel used by gimp. Also by the fact that in JPEG greyscale and color information is decoupled and the color information is stored with lower spatial resolution than the greyscale data. Thus there is additional rounding that has to be done to get back to a RGB raster. The bottom line is that JPEG, DV (for video) and other similar lossy compressions do introduce generational loss, like mp3 and similar codecs do for audio. /Øyvind K. -- «The future is already here. It's just not very evenly distributed» -- William Gibson http://pippin.gimp.org/http://ffii.org/ ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Date: Sun, 08 Jul 2007 11:44:17 +0200 From: [EMAIL PROTECTED] On Sun, 08 Jul 2007 07:22:24 +0200, Guillermo Espertino [EMAIL PROTECTED] wrote: In Gimp, it saves the file directly, without asking for the compression setting. Result: an image over-compressed with artifacts. Smaller size than the original. In Photoshop, it shows the quality settings the first time you hit CTRL+S. I think we're finally getting closer to the truth. There is something non standard in the file the camera is producing. It seems that PS knows there's a problem and thus prompts for the quality parameter, gimp it would seem is either reading this value as the IJG quality when it isn't or is applying a not too good default when it fails to read it. If it's an incorrect value put in by the camera that gimp is correctly reading it's not a gimp issue. If it is a missing value gimp should probably use it's jpeg default of 85 (or prompt as you suggest) which it does not seem to be doing. If you have imagemagick installed, use the following to see what information is in one of your camera images before you affect it with either gimp or ps and then again after gimp (and/or PS) does a save on it: identify -verbose unadulterated_image.jpeg That should give some info on what is in the jpeg header. This appears to be the case. The original image gives me this: $ identify -verbose /images/dcim/193canon/img_9309.jpg Image: /images/dcim/193canon/img_9309.jpg ... Filesize: 2.96358mb ... Compression: JPEG Quality: 98 Orientation: LeftBottom JPEG-Colorspace: 2 JPEG-Sampling-factors: 2x1,1x1,1x1 However, when I save it out, it's clearly not using the original quality setting: $ identify -verbose /tmp/img_9309.jpg Image: /tmp/img_9309.jpg ... Filesize: 901.654kb ... Compression: JPEG Quality: 85 Orientation: TopLeft JPEG-Colorspace: 2 JPEG-Sampling-factors: 2x2,1x1,1x1 If I explicitly save it out using the same settings as what came from the file, I wind up with a slightly shrunk file: $ identify -verbose /tmp/img_9309.jpg Image: /tmp/img_9309.jpg ... Filesize: 2.65972mb ... Compression: JPEG Quality: 98 Orientation: TopLeft JPEG-Colorspace: 2 JPEG-Sampling-factors: 2x1,1x1,1x1 Note that GIMP is not the only application that does this; KPhotoAlbum also changes the quality setting (to 75!). In this case, I suspect that it simply doesn't tell the appropriate library what the actual quality setting is from the original file. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Hi, On Sun, 2007-07-08 at 08:17 -0400, Robert L Krawitz wrote: Note that GIMP is not the only application that does this; Why should any application do what you suggest? If you open a JPEG file and save it again as JPEG, then the original quality factor is completely irrelevant. You are doing a lossy operation, there is no way to save the file with the same quality again. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On Sun, 08 Jul 2007 14:35:30 +0200, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Sun, 2007-07-08 at 08:17 -0400, Robert L Krawitz wrote: Note that GIMP is not the only application that does this; Why should any application do what you suggest? If you open a JPEG file and save it again as JPEG, then the original quality factor is completely irrelevant. You are doing a lossy operation, there is no way to save the file with the same quality again. Sven It would seem reasonable to assume that if the user has selected a size/quality trade-off given by a specific value, say, quality=98 he does not want to have to explicitly remake that decision every time he touches it. Also this info I part of the header and part of specification of that file so arbitarily changing it would seem to me to be a spec violation. Does your reply indicate you take a this feature not a bug approach here and you think is the best way gimp should deal with this situation? Thx. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Hi, On Sun, 2007-07-08 at 14:53 +0200, [EMAIL PROTECTED] wrote: Does your reply indicate you take a this feature not a bug approach here and you think is the best way gimp should deal with this situation? Indeed. When you open a JPEG file, then you have a decoded image. The settings that were used to encode it are irrelevant since encoding it again as a JPEG file would not yield the same image anyway. Thus it is better to use the default values. Since we will very soon allow the user to change these defaults, this should be the best way we can handle this. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On Sun, 08 Jul 2007 15:12:03 +0200, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Sun, 2007-07-08 at 14:53 +0200, [EMAIL PROTECTED] wrote: Does your reply indicate you take a this feature not a bug approach here and you think is the best way gimp should deal with this situation? Indeed. When you open a JPEG file, then you have a decoded image. The settings that were used to encode it are irrelevant since encoding it again as a JPEG file would not yield the same image anyway. I'm sorry I find that a rather forced logic. As we have seen the image will not be _identical_ due rounding errors and such , that does not make the existing choice of jpeg_quality irrelevant. It represents the users choice of size/quality trade-off. I see no justification to discard that choice as irrelevant. File | Save should save the image as it is. Save_As is there as a means to change things. Gillermo's real world example where the file size shrank by a factor of two and the quality took a serious hit can hardly be described a straight-forward save. It's doing a major change to the image and changing the compression parameters (quality and sampling_factor!), this should only happen through the Save_As with a full dlg. Thus it is better to use the default values. Since we will very soon allow the user to change these defaults, this should be the best way we can handle this. Sven Allowing the user for redefine the default is fine but I see no bearing on this issue. This is not a lifestyle choice it's a per image choice. It's irrelevant to this discussion. I'd always assumed that the default 85 only applied to untitled images on the first save not that it was silently forced on an unwary public as some sort of hidden gimp knows best feature. Abritarily throwing away half the image data without so much as a 'by your leave' , incredible. I'm really surprised that you dont see this as a bug. I would ask you to seriously consider if this is appropriate. Please take time to reflect on this before replying and preferable sound out a few other opinions. Thanks for the reply. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
From: Sven Neumann [EMAIL PROTECTED] Date: Sun, 08 Jul 2007 15:12:03 +0200 On Sun, 2007-07-08 at 14:53 +0200, [EMAIL PROTECTED] wrote: Does your reply indicate you take a this feature not a bug approach here and you think is the best way gimp should deal with this situation? Indeed. When you open a JPEG file, then you have a decoded image. The settings that were used to encode it are irrelevant since encoding it again as a JPEG file would not yield the same image anyway. Thus it is better to use the default values. Since we will very soon allow the user to change these defaults, this should be the best way we can handle this. Think of the quality setting as an indication of expectations rather than a specific outcome. It may not be possible to get the exact same outcome (and obviously -- at least to us -- there's no way to retroactively improve the result), but the quality setting could be treated as the user's expectation for the result. It's certainly true that a couple of iterations of saving at a quality setting of 85 (say) will yield a substantial degradation, and a couple of iterations at 65 will yield even more degradation, but a couple of iterations at a setting of 98 won't yield very much degradation at all. By this reasoning, if a user opens a file with a quality setting of 98, her expectation when saving the file is that the quality will still be very high, while if the quality setting of the incoming file is only 85, her expectations will be lower. A single default setting won't cover all cases. If the choice really is that arbitrary (and you make a good argument to that effect), why not simply use the quality setting of the incoming file as the implied default? I think it would at least align better with user expectations, particularly for files shot at high quality settings on digital cameras. BTW, on the Canon S3, the Superfine, Fine, and Normal settings correspond to 96, 90, and 68 respectively. So anyone who shoots in one of those two settings and then decides to do a quick edit will get a rude surprise. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On 7/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Sun, 08 Jul 2007 15:12:03 +0200, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Sun, 2007-07-08 at 14:53 +0200, [EMAIL PROTECTED] wrote: Does your reply indicate you take a this feature not a bug approach here and you think is the best way gimp should deal with this situation? Indeed. When you open a JPEG file, then you have a decoded image. The settings that were used to encode it are irrelevant since encoding it again as a JPEG file would not yield the same image anyway. I'm sorry I find that a rather forced logic. As we have seen the image will not be _identical_ due rounding errors and such , that does not make The image may well be quite unlike the input due to lossy compression -- see below. the existing choice of jpeg_quality irrelevant. It represents the users choice of size/quality trade-off. I see no justification to discard that choice as irrelevant. AFAICS, Sven is saying that it is irrelevant, because it is *impossible* to numerically represent the overall quality of the image to be saved. The quality setting of the input file, assuming that it is correctly calibrated to the IJG scale, would be multiplicative: when you save a jpeg file with quality 75, you are saying 'throw away a certain amount of the image data' -- and saving it again with quality 75, you are saying 'discard that much again'. You can't save with the same quality, because you've already thrown away much of the data that was used to create the first JPEG. Actually getting a quality that is notionally '75% of full detail' when saving a jpeg output from a jpeg input, is trial and error -- so really, presenting a preview would improve the situation. As for the practice of saving jpg outputs from jpg inputs, my personal experience has been that it's a BD thing; basically the only two possibilities are a) Image mutilation b) filesize inflation (ie. you can preserve quality.. by choosing something that effectively renders JPEG's compression ineffective (quality = 96 or above, IME) -- this often inflates the filesize beyond that of lossless image formats like PNG.) About the only thing GIMP could do to help here, is to warn the user if they are saving a jpeg file and the image was originally loaded from a jpeg file. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Date: Mon, 9 Jul 2007 00:26:21 +0930 From: David Gowers [EMAIL PROTECTED] On 7/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Sun, 08 Jul 2007 15:12:03 +0200, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Sun, 2007-07-08 at 14:53 +0200, [EMAIL PROTECTED] wrote: Does your reply indicate you take a this feature not a bug approach here and you think is the best way gimp should deal with this situation? Indeed. When you open a JPEG file, then you have a decoded image. The settings that were used to encode it are irrelevant since encoding it again as a JPEG file would not yield the same image anyway. I'm sorry I find that a rather forced logic. As we have seen the image will not be _identical_ due rounding errors and such , that does not make The image may well be quite unlike the input due to lossy compression -- see below. The question to my mind is what's going to be closest to the user's expectations in terms of quality and size, not what's going to be pixel for pixel identical. When saving (or, I'd argue, exporting) an image from a lossless format (png, or even more so xcf) to a lossy format, we can really only guess, and in that case having a settable default is good. However, when we're working with JPEG files, we have a bit more information about what the user likely wants, based on the quality setting and perhaps the file size. the existing choice of jpeg_quality irrelevant. It represents the users choice of size/quality trade-off. I see no justification to discard that choice as irrelevant. AFAICS, Sven is saying that it is irrelevant, because it is *impossible* to numerically represent the overall quality of the image to be saved. The quality setting of the input file, assuming that it is correctly calibrated to the IJG scale, would be multiplicative: when you save a jpeg file with quality 75, you are saying 'throw away a certain amount of the image data' -- and saving it again with quality 75, you are saying 'discard that much again'. You can't save with the same quality, because you've already thrown away much of the data that was used to create the first JPEG. Sure, but if the image was originally saved at quality 98, and then you resave it at 75, you're going to wind up with a lot more artifacts, which would be a surprising result if you don't understand how JPEG works. If the original image was saved at 60, and you resave it at 98, you might wind up with a much bigger image (I'm less certain of that), which is also not what I think would be expected. The issue at hand is a special, but IMHO important, case -- a very high quality JPEG gets minor edits (perhaps to remove redeye or the like) and resaved; the result is *markedly* lower quality because the default of 85 is much less than the original. Actually getting a quality that is notionally '75% of full detail' when saving a jpeg output from a jpeg input, is trial and error -- so really, presenting a preview would improve the situation. As for the practice of saving jpg outputs from jpg inputs, my personal experience has been that it's a BD thing; basically the only two possibilities are a) Image mutilation b) filesize inflation (ie. you can preserve quality.. by choosing something that effectively renders JPEG's compression ineffective (quality = 96 or above, IME) -- this often inflates the filesize beyond that of lossless image formats like PNG.) What about the case where the original quality was 96 or 98, and it's resaved at the same quality level? My quick test showed a slight decrease in file size, but probably very little in the way of image degradation. About the only thing GIMP could do to help here, is to warn the user if they are saving a jpeg file and the image was originally loaded from a jpeg file. That would be a good idea, but I believe that there are at least some common cases where it's possible to do a bit better. -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Sven Neumann schreef: Hi, On Sun, 2007-07-08 at 14:53 +0200, [EMAIL PROTECTED] wrote: Does your reply indicate you take a this feature not a bug approach here and you think is the best way gimp should deal with this situation? Indeed. When you open a JPEG file, then you have a decoded image. The settings that were used to encode it are irrelevant since encoding it again as a JPEG file would not yield the same image anyway. Thus it is better to use the default values. Since we will very soon allow the user to change these defaults, this should be the best way we can handle this. Perhaps not a bug, but IMHO gimp's JPEG handling violates the principle of least surprise. I had a quick look at the source code and found out that the quality setting (and other parameters) are saved in a global variable jsvals, which is initialized with the default values (85 for the quality), but gets overwritten after save as: 1. open a.jpg 2. save a.jpg - a.jpg is saved with the default quality, 85. Fine by me. 3. save a.jpg with save as, with quality say 55 - as expected it is saved with quality 55. 4. open b.jpg 5. save b.jpg - b.jpg is saved with quality 55 instead of 85!! Wouldn't it be better if gimp acted in one of those two ways: 1. always save with the default quality, except when save as is used. 2. read the quality when loading a jpeg, and used that to save the image (if save as is not used). -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On Sun, 08 Jul 2007 19:55:30 +0200, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Sun, 2007-07-08 at 17:37 +0200, Roel Schroeven wrote: 2. read the quality when loading a jpeg, and used that to save the image (if save as is not used). Last time we discussed this (a couple of years ago), libjpeg didn't allow us to read the JPEG quality factor that was used to save the image. I don't know if that has changed, but I assume that it hasn't. Sven thanks , that explains why it was done this way. Probably ought to be checked, hopefully they've made a bit of progress in the intervening time. imagemagick seems to have no trouble getting this info and it does depend on jpeg pkg. Of course if there is an inadequacy in jpeglib they may have worked around it by reading the file header anyway, I'm pretty sure it's readily available. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Hi, On Sun, 2007-07-08 at 17:37 +0200, Roel Schroeven wrote: 2. read the quality when loading a jpeg, and used that to save the image (if save as is not used). Last time we discussed this (a couple of years ago), libjpeg didn't allow us to read the JPEG quality factor that was used to save the image. I don't know if that has changed, but I assume that it hasn't. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] ANNOUNCE: GIMP 2.2.16 Release
Hi, a new GIMP 2.2 release has been uploaded to ftp://ftp.gimp.org/pub/gimp/v2.2/ GIMP 2.2.16 is a bug-fix release in the stable GIMP 2.2 series. It fixes security problems in some file load plug-ins and improves robustness and forward compatibility of the XCF loader. In particular the following issues have been addressed: - improved input value validation in several file plug-ins (bug #453973) - improved handling of corrupt or invalid XCF files - guard against integer overflows in several file plug-ins (bug #451379) - fixed handling of background alpha channel in XCF files (bug #443097) - improved forward compatibility of the config parser - fixed crash when previewing some animated brushes (bug #446005) As usual, we only release source code. But for some of the various supported platforms binary packages are already available. Others should follow soon. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] [Gimp-announce] ANNOUNCE: GIMP 2.2.16 Release
Hi, I would like to say special thanks to Mukund and Raphaël who both helped during the last week to fix the reported and some unreported security problems in our file load plug-ins. Without your help we wouldn't have been able to respond to the vulnerability report so quickly. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On Sun, 08 Jul 2007 17:37:28 +0200, Roel Schroeven [EMAIL PROTECTED] wrote: 1. open a.jpg 2. save a.jpg - a.jpg is saved with the default quality, 85. Fine by me. 3. save a.jpg with save as, with quality say 55 - as expected it is saved with quality 55. 4. open b.jpg 5. save b.jpg - b.jpg is saved with quality 55 instead of 85!! Wouldn't it be better if gimp acted in one of those two ways: 1. always save with the default quality, except when save as is used. 2. read the quality when loading a jpeg, and used that to save the image (if save as is not used). thanks for digging that out. is that from todays svn, Sven committed a patch earlier today that may affect that. the default setting now settable by the user (thanks Etienne). see bug #63610 ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On Sun, 08 Jul 2007 17:53:59 +0200, Robert L Krawitz [EMAIL PROTECTED] wrote: What about the case where the original quality was 96 or 98, and it's resaved at the same quality level? My quick test showed a slight decrease in file size, but probably very little in the way of image degradation. Thanks, I suspect that could be the result of some of the less important parameters getting a similar default, the encoding method (int/fp) or simply the algorithm efficiencies. eg An earlier post indicated Jpeg:sampling-factor also changed from 2x1,1x1,1x1 to 2x2,1x1,1x1. /gg ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
[EMAIL PROTECTED] schreef: On Sun, 08 Jul 2007 17:37:28 +0200, Roel Schroeven [EMAIL PROTECTED] wrote: 1. open a.jpg 2. save a.jpg - a.jpg is saved with the default quality, 85. Fine by me. 3. save a.jpg with save as, with quality say 55 - as expected it is saved with quality 55. 4. open b.jpg 5. save b.jpg - b.jpg is saved with quality 55 instead of 85!! Wouldn't it be better if gimp acted in one of those two ways: 1. always save with the default quality, except when save as is used. 2. read the quality when loading a jpeg, and used that to save the image (if save as is not used). thanks for digging that out. is that from todays svn, Sven committed a patch earlier today that may affect that. I first tried with gimp/trunk from svn revision 22893 (from 2007-07-06 22:47:44 +0200); I now tried it again with svn revision 22902 (from 2007-07-08 17:34:25 +0200), which presumable includes the patch you mention; the behavior I described is still the same. the default setting now settable by the user (thanks Etienne). see bug #63610 I haven't tried changing the defaults to see if that changes anything. -- If I have been able to see further, it was only because I stood on the shoulders of giants. -- Isaac Newton Roel Schroeven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
OMG, at last! That's what I was trying to say since the beginning. I know jpeg is a lossy format (I knew that for at least ten years). I know, and always knew, that it has generational degradation. I didn't know that PS compression scale doesn't follow the jpeg specification. Thanks for the information, I know it now. Despite the scale thing, most of the people know that jpeg loses image information. I don't know the internal structure of a jpeg file, but please don't tell me. I'm talking from the user perspective here. What I didn't know (and wouldn't expect) is that Gimp will destroy my pictures without warning me. And that's exactly what I get. I have a picture taken at 95, open it and save it, and it ends up at 85. Why is that? I'm a professional designer. I'm not using jpeg for professional work. I used tiff and PSD with PS and now I'm using xcf. I know that. Don't try to explain me how to work, because I know it. But I'm a person too, not just a designer, and use to take some family pictures. The camera that I use (an old Nikon Coolpix 800) saves in jpeg and tiff format. Tiff format is huge and slow, jpeg is more handy. During a weekend with my family, I took a couple of pictures. Some of them were under-exposed. It doesn't matter. I open them, tweak the curves a little, and save them, for instance. Nobody will be using other formats for intermediate work in such case. It's a single tweaking. This is a VERY COMMON practice. And if you think that is perfectly normal that the program recompresses the images without warning, let me tell you that you're wrong. As others already said: One expects that a fine quality picture from a camera will be saved with a similar quality. Not a half. If gimp can't read the quality setting from the image, then it should display the export settings EVERY TIME you save a jpeg image as jpeg. Destroyed image data is not a expectable feature. Sven wrote: Why should any application do what you suggest? If you open a JPEG file and save it again as JPEG, then the original quality factor is completely irrelevant. You are doing a lossy operation, there is no way to save the file with the same quality again. Yes, but if you had a great looking photo you don't expect to have a heavily compressed image with lots of artifacts, bad edges and color bleeding. You expect a similar quality. If once the image is decoded the quality factor doesn't matter anymore, why don't you display the export options when saving? It would make sense to do that. The user wants control over the exporting process, but for now Gimp is taking the decision for him. Sven wrote: Due to the way file plug-ins are implemented in GIMP, it is not trivial to do this. But you can easily work around it by assigning Ctrl-S to Save As. Then you will always be prompted with the dialog asking you for the save parameters. The problem is not me. I know the problem now and I won't use CTRL+S for mi jpegs anymore. I'm concerned about lots of users that will learn that too in the hard way, destroying some irreplaceable images. There seems to be a big gap between developers and users here. Developers base their opinions on technical issues but seem to forget the problems that pop up in the everyday use. I'm a user, I plan to keep using Gimp everyday, and this jpeg exporting issue is (from the user perspective) definitively a PROBLEM. From the user perspective, the way that Gimp processes the jpeg images now isn't tha obvious. I had to start this discussion here to find out how it works, and now I have it clear. But what happens with the thousands of users out there? ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Hi, On Sun, 2007-07-08 at 18:31 -0300, Guillermo Espertino wrote: What I didn't know (and wouldn't expect) is that Gimp will destroy my pictures without warning me. And that's exactly what I get. I have a picture taken at 95, open it and save it, and it ends up at 85. Why is that? Because you are using JPEG despite better knowledge that it will do exactly that. Sorry for the harsh tone, but I am only replying the way you are putting it. I already explained that the JPEG plug-in cannot access the settings that were used to save the file. We can also not easily change the code to always show the settings dialog because then we would have to do show the dialog for all file plug-ins. There might be a way out of this, but there is certainly not an easy one. So please calm down and let the developers deal with this. After all this is a developer list. Your harsh comments are not helpful. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Hi, here's what I suggest that we do (short-term). It should be a simple change and it will avoid that what happened to Guillermo happens to others in the future. The JPEG plug-in should not use the last-used values when being run non-interactively from the Save action. It should use the, now user-configurable, default values. Of course if the jpeg-save-options parasite is set on the image that is being saved, then those values should be used. As far as I can see now, this means removing a single line in jpeg.c. I will have a closer look tomorrow morning. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
On Sun, 08 Jul 2007 23:48:28 +0200, Sven Neumann [EMAIL PROTECTED] wrote: Hi, On Sun, 2007-07-08 at 18:31 -0300, Guillermo Espertino wrote: What I didn't know (and wouldn't expect) is that Gimp will destroy my pictures without warning me. And that's exactly what I get. I have a picture taken at 95, open it and save it, and it ends up at 85. Why is that? Because you are using JPEG despite better knowledge that it will do exactly that. He knew it was potencially a lossy format but he was using a very high quality setting, he did not know gimp would arbitarily change down the quality and wreck his image. jpeg at 98 looses hardly loses any quality visually. To be fair you should be accurate, what he did was sensible and should not have produced the results it did. You almost seem to be saying that anyone who uses jpeg is a fool so it doesn't matter if gimp destroys their work. Sorry for the harsh tone, but I am only replying the way you are putting it. Well he has been very patient and has had to repeatedly post to get us to see what he was reporting was not PEBKAC. I would hardly criticise a bit of polite annoyance on his part. It was hard to believe at first that gimp would wreck an image like this. Let alone that it should be considered a feature. I already explained that the JPEG plug-in cannot access the settings that were used to save the file. That is not accurate. Imagemagick does it , gimp can. If libjpeg still cant do this ( to be verified ) then another way to read the file header needs to be found. It's not complicated. We can also not easily change the code to always show the settings dialog because then we would have to do show the dialog for all file plug-ins. Agreed , that's probably not the correct solution. Sven Thanks for bringing this up Guillermo , and thanks for having the perseverance to keep posting until we got what was really happening. Hopefully we will work out a better way to deal with this. Once we're all agreed this is not very satisfactory we will certainly come up with a solution. Oof, it's been a busy one. Goodnight! ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
So please calm down and let the developers deal with this. After all this is a developer list. Your harsh comments are not helpful. I'm not being harsh. At least it wasn't my intention. In fact, this list is commonly considered to be harsh by many people, but now I learn that there's sensitive people here :-) I'm just trying to explain my point. I just want to help the project with my experience as a user, because I can't code. What makes sense for you, may not make sense for users. You find the quality setting of the original file to be irrelevant, but obviously it isn't irrelevant for regular users like me. Because you are using JPEG despite better knowledge that it will do exactly that. If you say that a user must understand the jpeg internal structure before saving a single image, there's no much to talk about. I'll uninstall Gimp and will be working with Imagemagick via command line for processing my images. :-p Seriously talking: Gimp is a program with a GUI, it's having great useability improvements. It's obviously a program to be used by users, not just by developers. For a user, a non-linear scale and a destructive re-save without a warning are not obvious things. I already explained that the JPEG plug-in cannot access the settings that were used to save the file. We can also not easily change the code to always show the settings dialog because then we would have to do show the dialog for all file plug-ins. There might be a way out of this, but there is certainly not an easy one. This is very different. If that had been your first answer I wouldn't say anything else. The problem is real, but the solution isn't that easy because it implies a complete change in the saving plugins? That's fine. But don't start saying that the problem doesn't exist or it's irrelevant, because it is not. Anyway, don't think I'm pissed off. I'm cool with all the replies. We may agree or not, but we all try to take Gimp to a higher level (some people coding, some people using it and trying to report problems like this). :-) Gez. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
From: Sven Neumann [EMAIL PROTECTED] Date: Sun, 08 Jul 2007 23:48:28 +0200 On Sun, 2007-07-08 at 18:31 -0300, Guillermo Espertino wrote: What I didn't know (and wouldn't expect) is that Gimp will destroy my pictures without warning me. And that's exactly what I get. I have a picture taken at 95, open it and save it, and it ends up at 85. Why is that? Because you are using JPEG despite better knowledge that it will do exactly that. Sorry for the harsh tone, but I am only replying the way you are putting it. Sven, I do think you're being unreasonably hard on Guillermo. Never mind that using JPEG per se won't do exactly that -- what's really degrading the quality so badly is GIMP's choice of a quality factor compared to that of the original JPEG. Not to mention that I think Guillermo is being quite reasonable. A lot of people (particularly folks who just casually want to lighten a shot or remove redeye) don't know it. All they know is that they have a picture that their camera took, they've corrected it, and all of a sudden the image quality fell apart. They don't know anything about JPEG's, or compression (lossy or otherwise), all they know is that GIMP ruined their photo. That's not going to be very helpful to anyone. I already explained that the JPEG plug-in cannot access the settings that were used to save the file. We can also not easily change the code to always show the settings dialog because then we would have to do show the dialog for all file plug-ins. There might be a way out of this, but there is certainly not an easy one. So please calm down and let the developers deal with this. After all this is a developer list. Your harsh comments are not helpful. Well, as was noted ImageMagick is able to access this information, so it's apparently there. Maybe this isn't going to be an easy problem to solve, and that's OK, but I think that this is a real problem, not simply a user error (and even if it is a user error, wouldn't it be best to help users not make this kind of error?). -- Robert Krawitz [EMAIL PROTECTED] Tall Clubs International -- http://www.tall.org/ or 1-888-IM-TALL-2 Member of the League for Programming Freedom -- mail [EMAIL PROTECTED] Project lead for Gutenprint --http://gimp-print.sourceforge.net Linux doesn't dictate how I work, I dictate how Linux works. --Eric Crampton ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Guillermo Espertino writes: I didn't know that PS compression scale doesn't follow the jpeg specification. There is no such specification for a compression scale or quality factor. Inside an JPEG image, what actually defines the lossiness of the compression are a set of so-called quantization tables. A quantization table is a table of 64 8- or 16-bit integers. (Typically 8-bit values are used.) Typically, one such table is used for the Y channel (luminance, i.e. BW information) and another for the Cb and Cr channels (colour information). These tables are actually stored inside each JPEG image. (There are not some standard one(s) that would implicitly be referenced to by some single index that would say use standard table 1 or something like that. In retrospect, that might have been a good idea I think.) I.e. what actually determines the lossiness and loss style of the compression, what information is thrown away, are 128 (or just 64, or even 192) numbers (!). Not a single quality value. (It is in fact even possible to use different quantization tables for different parts of an image, I think. I have no idea how common such JPEG images are, and if any software in common use produces such.) The single quality value 1..100 that GIMP uses is passed to libjpeg's jpeg_set_quality() function. This function is used to scale two sample quantization tables given in the JPEG specification. But nothing forces some application to use linear scalings of these sample quantization tables. I don't know if the sample tables are even normative in the standard, or just informative. One might imagine some application even doing a clever analysis of an individual image to come up with image-specific quantization tables. The website http://www.impulseadventure.com/photo/jpeg-quantization.html seems to have a good collection and comparison of quantization tables used by different firmware and software implementations of JPEG compression. http://markcox.googlecode.com/svn/trunk/jpegdump/jpegdump/ has sources to a nice program one can dump the contents of a JPEG file, if one wants to have a look at the quantization tables used. There is another program with the same name at http://www.programmersheaven.com/download/17054/download.aspx that is less useful in general, but has one nice feature: it attempts a guess at the libjpeg-style quality factor used for the quantization tables. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Sven Neumann writes: I already explained that the JPEG plug-in cannot access the settings that were used to save the file. Actually, it shouldn't be that hard to at least try. If the quantization tables used in an image correspond exactly (or closely enough) to those produced by libjpeg with some setting of jpeg_set_quality(), it would be nice if GIMP remembered that as the default quality to use for the file. Or something like that... One might even consider keeping and re-using the original quantization tables instead of using jpeg_set_quality() in case the quantization tables don't seem to be produced by libjpeg. --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Tor Lillqvist writes: One might imagine some application even doing a clever analysis of an individual image to come up with image-specific quantization tables. http://citeseer.ist.psu.edu/cache/papers/cs/1634/ftp:zSzzSzftp.cs.wisc.eduzSzpubzSztech-reportszSzreportszSz94zSztr1257.pdf/rd-opt-an-efficient.pdf --tml ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] jpeg quality factor.
Tor Lillqvist wrote:One might even consider keeping and re-using the original quantization tables instead of using jpeg_set_quality() in case the quantization tables don't seem to be produced by libjpeg. Which is what I understand Photoshop does, thereby giving users the least level of surprise when they casually open/modify/save a JPEG file. Graeme Gill. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
