2011/3/2 Peter Nermander <span dir="ltr"><<a href="mailto:peter@nermander.se">peter@nermander.se</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">> afaik, cropping a jpeg is a lossless operation: so there is no change between the original image and the cropped one in the pdf...<br>
> or, at least, it can be done in a lossless way and without resampling it.<br>
<br>
</div>Yes, it can be done without resampling, but not without recompression.<br>
<br>
The way a JPEG is compressed it has to be recompressed after any<br>
change. Change one pixel and the image has to be recompressed. That is<br>
why using JPEG as a working format during image editing is no good.<br></blockquote><br>Hi,<br><br>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.<br>
<br>Cheers!<br><br>Louis<br><br><span class="il">JPEG</span> is a lossy format, to be able to describe what happens when you do this is<br>
outlined in steps below:<br><br>
1.1) The camera sensor provides the original image signal (pixel raster)<br>
1.2) The camera performs white balance adjustment according to<br>
setting/automatically determined white point<br>
1.3) The camera does <span class="il">jpeg</span> compression on the signal, discarding pieces<br>
of the actual content<br>
of the image in a perceptually little degrading manner. (removing<br>
color resolution and keeping luminance information and giving<br>
preferential room for certain spatial frequencies (DCT quantization.).<br>
2.0) GIMP decodes <span class="il">JPEG</span> trying to reconstruct the signal from 1.2 based<br>
on the bits actually provided by 1.3.<br>
2.1) Levels adjustment<br>
2.2) Curves<br>
2.3) Colors<br>
2.4) The image is scaled actually improving the amount of data since<br>
we're now approximating the original signal at this scale better (more<br>
compressed bits per pixel).<br>
2.5) The image is saved as <span class="il">JPEG</span> throwing away information in the same<br>
manner as 1.3 but<br>
with different thresholds for how much precision should be maintained.<br>
3.0) The image is loaded in GIMP or an other application in the same<br>
manner as 2.0, trying<br>
to reconstruct as signal based on not quite precise knowledge.<br><br>
GIMP could perhaps even warn a user the first time he presses Ctrl+S<br>
on a an opened <span class="il">JPEG</span> image warning him that even with minimal or no<br>
real changes to the image the signal will be degraded. This should be<br>
a warning of such a level of non-expertise that it perhaps could be<br>
turned on in the configuration/one of the initial tips of the day. And<br>
for each of them of course have the ability to say do not show this<br>
warning again.<br><br>
Ideally <span class="il">JPEG</span> compression involves a human operator that decides what<br>
acceptable <span class="il">loss</span> is through visual inspection. A power user GUI for<br>
doing this would probably allow you to switch<br>
between the full signal and a reconstructed one in the viewport,<br>
perhaps with a zoomed in view with enlarged pixels in the dialog<br>
itself that can be panned, but uses the center of the<br>
image by default. The inputs needed in such a dialog would probably be<br>
a target file size<br>
entry (I often aim to make <span class="il">JPEG</span> images ~100kb at web publishing<br>
resolutions.) I would then<br>
consider whether I've actually lost too much information and increase<br>
the quality until I find it acceptable. For my use of this slider I do<br>
not even need values of 0 and 100, I would actually expect 0.0 to<br>
yield a completely grey image if it should make intuitive sense, keep<br>
0% of the signal vs keep 100%. A scale going from low to high quality<br>
makes more sense than any numerical values, like many other sliders it<br>
makes sense to be able to tweak a transfer function to make the<br>
results of interaction perceived as more uniform (another examples is<br>
gaussian blur where you do not want a linear scale of the radius,<br>
since that would give you a poor selection of smaller radiuses where<br>
small differences matter more than in the large part of the sliders<br>
range.)<br><br>
A more immediate simpler enhancement is probably to use a higher<br>
quality/produce larger files by default. I haven't taken the time to<br>
do comparisons of how much is information is thrown away at each<br>
generation of save, but it seems to be quite a bit, the image used in<br>
the "<span class="il">JPEG</span> Generation <span class="il">Loss</span>" figure in the example in the following text<br>
uses an image that<br>
shows how <span class="il">JPEG</span> compression keeps different aspects of the image intact<br>
across multiple encode/decode cycles:<br><br><a href="http://pippin.gimp.org/image_processing/chap_dir.html#id2526295" target="_blank">http://<span class="il">pippin</span>.gimp.org/image_processing/chap_dir.html#id2526295</a><br>
<br>
/Øyvind K. <br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
It seems however it is possible to do lossless cropping if you crop<br>
along the borders of the "blocks" the image is made up of.<br>
<br>
And if that is true that would probably be a working solution.It would<br>
of course mean that the cropped images might become a little bigger<br>
than the frame, but not more than 30 pixels (assuming worst case with<br>
16 pixel blocks, giving 15 pixels on each side).<br>
<font color="#888888"><br>
/Peter</font></blockquote><br>