2011/3/2 Peter Nermander <peter at nermander.se> > > afaik, cropping a jpeg is a lossless operation: so there is no change > between the original image and the cropped one in the pdf... > > or, at least, it can be done in a lossless way and without resampling it. > > Yes, it can be done without resampling, but not without recompression. > > The way a JPEG is compressed it has to be recompressed after any > change. Change one pixel and the image has to be recompressed. That is > why using JPEG as a working format during image editing is no good. >
Hi, Below is an excerpt from the GIMP's devs mailing list, a post by ?yvind K. followed by a link leading to a page that is worth reading too. Cheers! Louis 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. > > It seems however it is possible to do lossless cropping if you crop > along the borders of the "blocks" the image is made up of. > > And if that is true that would probably be a working solution.It would > of course mean that the cropped images might become a little bigger > than the frame, but not more than 30 pixels (assuming worst case with > 16 pixel blocks, giving 15 pixels on each side). > > /Peter -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.scribus.info/pipermail/scribus/attachments/20110302/32a7665a/attachment.htm>
