Why "Lossless Jpeg Rotation" still lossy?

[cBlock]

Ok, I know this isn't related to divx or mpeg, but I thought there are lots of similarities between those and jpeg, and experimented coders around here could help.

So, why all the softwares that claim lossless jpeg rotation, don't actually doing it so? The errors are small, but still...
I have little knowledge on jpeg coding, but I know that for a jpeg rotation it isn't required a full decode process, only rearrangements of microblocks in the image and rearrangements of the coeffs within each microblock, as the coordinates are swapped. There shouldn't be any quantization process involved, as the coeffs remain unchanged.

Another problem is saving and reopening many many times a jpeg file with the same software with the same settings (including same quality factor), without editing. Why is this losing detail after a while, when we knew that "quantizing a run of already quantized data with the same quantization factor shouldn't produce any data loss furthermore"?
Thanx.

[communist]

Another problem is saving and reopening many many times a jpeg file with the same software with the same settings (including same quality factor), without editing. Why is this losing detail after a while, when we knew that "quantizing a run of already quantized data with the same quantization factor shouldn't produce any data loss furthermore"?
Thanx.
Original set of data (original image for ex.) -> lossy compression -> new data that resembles original to certain amount (depends on quantization factor) -> decode (for viewing / editing) -> compression -> again new data that even less resembles the original.

They are just doing what is expected, this is not a transcoding process but a decode / encode (reencode) process.

[foxyshadis]

For plain opening and closing: Roundoff errors. They accumulate fast. (On encode, there's colorspace conversion, truncating to 8-bit, then quantizing the fft, and reversing on decode means lots of roundoffs.)

For rotating: You're changing the input even more. Of course the way it gets transformed is going to change, along with the roundoff errors.

Lossless jpeg is simple and fast and it's stupid that some software claims it when they really don't have it, but what do you expect? Hype sells.

[MfA]

Are you talking about a 90 degree multiple rotation? Otherwise there won't be a 1 to 1 mapping between coefficients (once you start blending coefficients you obviously have to requantize).

[sysKin]

So, why all the softwares that claim lossless jpeg rotation, don't actually doing it so? The errors are small, but still...

There shouldn't be any. 90/180 degree rotation, mirror and upside-down - which are the possible lossless transforms - can be really lossless....
Unless the quantization matrix is not symmetrical maybe?

"quantizing a run of already quantized data with the same quantization factor shouldn't produce any data loss furthermore"?Oh it should and will. Encoders are free to drop and reduce (round down, with a large dead zone too) whatever coefficients they feel like. The result is that if you continuesly quantize and dequantize the same coefficients, they will eventually all change to zeros.

[bb]

JPEG rotation in steps of 90 degrees and JPEG mirroring along the vertical or horizontal axis can be done in the compressed domain - provided that the picture width and height are multiples of 8, if I remember correctly.

JPEG rotation by 90 degrees may be done the stupid way, too, i.e. the picture gets fully decoded, rotated, and encoded to JPEG again. This is what all graphics programs can do if they have a rotate function. This way the picture can be rotated by any angle you like, not just in steps of 90 degrees. But you lose quality this way because of the re-encoding.

@sysKin:
No, the coefficients will never all change to zero. Think about it ;)

bb

[sysKin]

@sysKin:
No, the coefficients will never all change to zero. Think about it ;)

Really? Well I'm not sure what jpeg encoders usually do, but for example xvid's inter (agreed, not intra) quantization first subtracts (towards zero) half the quantization step, then divides by quantization step. So if you did quant-dequant-quant-dequant etc, rounding would make the coefficient one step smaller than last time, every time.

Either way, a jpeg encoder *can* do the same ;) Especially if it has some Trellis RDO.

[foxyshadis]

You still have to have a DC coeff for each. :p