On 7/7/07, Guillermo Espertino <gespertino@xxxxxxxxx> wrote: > The images I get from the camera are fine. My problem is that if adjust > them, scale them and re-save them without explicitly change the quality > setting they turn out really distorted. > Even though I understand (now) the difference between that scales, I'm > still concerned about that quality loss in my images. > I repeat: I just open them from the camera and they look great (Nikon > Coolpix 800), adjust levels, curves and color (they still look great), > scale them down, and save them using CTRL+S. When I re-open them they > are distorted. > I'm not talking about repetitive openings and saves. JPEG is a lossy format, to be able to describe what happens when you do this is outlined in steps below: 1.1) The camera sensor provides the original image signal (pixel raster) 1.2) The camera performs white balance adjustment according to setting/automatically determined white point 1.3) The camera does jpeg compression on the signal, discarding pieces of the actual content of the image in a perceptually little degrading manner. (removing color resolution and keeping luminance information and giving preferential room for certain spatial frequencies (DCT quantization.). 2.0) GIMP decodes JPEG trying to reconstruct the signal from 1.2 based on the bits actually provided by 1.3. 2.1) Levels adjustment 2.2) Curves 2.3) Colors 2.4) The image is scaled actually improving the amount of data since we're now approximating the original signal at this scale better (more compressed bits per pixel). 2.5) The image is saved as JPEG throwing away information in the same manner as 1.3 but with different thresholds for how much precision should be maintained. 3.0) The image is loaded in GIMP or an other application in the same manner as 2.0, trying to reconstruct as signal based on not quite precise knowledge. GIMP could perhaps even warn a user the first time he presses Ctrl+S on a an opened JPEG image warning him that even with minimal or no real changes to the image the signal will be degraded. This should be a warning of such a level of non-expertise that it perhaps could be turned on in the configuration/one of the initial tips of the day. And for each of them of course have the ability to say do not show this warning again. Ideally JPEG compression involves a human operator that decides what acceptable loss is through visual inspection. A power user GUI for doing this would probably allow you to switch between the full signal and a reconstructed one in the viewport, perhaps with a zoomed in view with enlarged pixels in the dialog itself that can be panned, but uses the center of the image by default. The inputs needed in such a dialog would probably be a target file size entry (I often aim to make JPEG images ~100kb at web publishing resolutions.) I would then consider whether I've actually lost too much information and increase the quality until I find it acceptable. For my use of this slider I do not even need values of 0 and 100, I would actually expect 0.0 to yield a completely grey image if it should make intuitive sense, keep 0% of the signal vs keep 100%. A scale going from low to high quality makes more sense than any numerical values, like many other sliders it makes sense to be able to tweak a transfer function to make the results of interaction perceived as more uniform (another examples is gaussian blur where you do not want a linear scale of the radius, since that would give you a poor selection of smaller radiuses where small differences matter more than in the large part of the sliders range.) A more immediate simpler enhancement is probably to use a higher quality/produce larger files by default. I haven't taken the time to do comparisons of how much is information is thrown away at each generation of save, but it seems to be quite a bit, 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. -- «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@xxxxxxxxxxxxxxxxxxxxxx https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
