On Thursday 17 February 2005 11:24, Alexander Rabtchevich wrote:

There are some lossless jpeg transformations - flip and rotate (as Ifran view does under Windows). Are there any plans to introduce them in GIMP?

Hmmm.

No.
They would not make much sense in the GIMP.

Once an image is open, the GIMP doesn't 'know' were it came from - but for it's name and save options.
For this to work, the transform tools would have to be 'jpeg aware' - moreover, no other image editing of any kind could be done besides the rotate or flip, before the image is saved back again.

In short: you'd better doing these trasnforms with another program that doesn't do general editing of a image.

Ok - I can think of one way of this being feasible - when the structure for the macro recorder is in place, or when an API for the undo steps is in place, the Jpeg filter could check, on save, if a) The image was loaded from a jpeg, and the original file is still available
b) The only operations performed on the image were images that can be performed in lossless way
And them it would:
c) Discard the Gimp image data, and perform the transform by itself on the orginal file.

--That means, that the jpeg plug-in would do the job, not the GIMP. It would be feasible, but I do not see it making much sense, and would be a terrible hack.

On Thu, Feb 17, 2005 at 06:02:31PM +0200, Alexander Rabtchevich wrote:

Could it be done via additional menu item: open for the lossless transformations with only few operations active? The operation itself has sense for digital images with portrait orientation. It would be nice to store the original images without data loss but with corrected orientation.

I think it makes very little sense to put this into the gimp. The extra work is IMHO just not worth it, a specialized extra application would be more useful.

Or a plug-in. The number of (useful, lossless) operations that can be done on jpegs is very limited.

By the way, I'm just curious, is it possible to apply different jpeg settings to the different parts of an image?

Yes, you can vary quantizazion factors, but i don't think the jpeg library can handle that. The best you can do with respect to such tricks is to use scan scripts to achieve some effects, for example, the image at URL has the monochrome
parts first which has the effect of first showing the grayscale image on slow-enough connections.

mean if the jpg image haven't undergo transformations affected the whole image, the unaffected parts of the image could be saved as the original compressed data without recompression (at least beyond adjacent points). These pixels could be obtained by the simple comparison with the original file.

That would be easy iff the underlying jpeg library supports it, and could be limited to the jpeg plug-in. However, if you only use the ijg jpeg library and take care of not changing the quantization factors you will see that the pixels will already not change, i.e. there will be losless compression.

So there is probably little demand for that. It would be far more useful to have a way of knowing the quality the file was saved with (by the ijg library) so it can be saved with the same quantizazion factor again, if possible (i.e. as long as you use the same library to compres/decompress the file).