Lossless Rotate Bug?, image size gets altered when using lossless rotate bug? Options

[fbakan]

Hi,

don't know if this is OS/2-specific, but here's my problem:

For example I have a .jpg file 454x480 pixels. When I now chose
rotate lossless 180 degree the size gets altered and now is 448x480.
This is not lossless, the picture loses some pixels!
There is even no option for 'undo', so the original image gets destroyed.

I think this is a rather severe bug or am I wrong?

(version 3.40, but at least 3.31 also has this bug)

Thanks for listening
Franz

[BSWAdmin1]

From a previous forum post about this issue found using the forums search feature:

Yes, this image size change is expected. It has to do with the "block size" of the JPEG encoding. This will occur if the image size is not evenly divisible by 16 (or sometimes 8).

Read the full reply with further details in this topic about the JPEG losless rotate feature

As for the Undo option, JPEG lossless rotation operates directly on the file on disk, so there is not a temporary file for undo operations.

--
Thanks,
Brandon

[Peter]

Correct. The image width/height needs to be divisible by 8, the size of one MCU block (8x8).

Since the size of your image isn't divisible by 8, it has probably already been subject to a lossy transformation. Lossless transformation will generate garbage out of partial MCU blocks. Instead of presenting the garbled edges to the user, PMView does what most users probably prefer and cuts out the garbled blocks.

Usually this is not an issue, since camera originals typically have a size that is divisible by 8 and can be rotated losslessly without the need to throw away anything.

Peter

[fbakan]

Thanks for the explanations.

I see that I have to avoid the lossless transformations for those jpgs

But I would expect at least a warning before the image gets irreversible
cropped without undo option.
This is my wish for the next release.

Franz