[scribus] Image cropping

[Louis Desjardins]

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.net/pipermail/scribus/attachments/20110302/32a7665a/attachment.htm>