0.84: JPEG lossless cropping is completely off

[helmut]

XnView: MP 0.84
OS: Windows 10 - 64bit

When using JPG lossless cropping, the crop result is completey off if automatic EXIF rotation is used.

Effect: JPG cropping is not usable. Images are destroyed.

To reproduce:
1. Download this JPEG image and save it on your computer.
2. Make a copy of the image
3. Select the copied image and open it in Viewer
4. Select an area around one of the objects shown in the image. (Remember this area).
5. Select "Tools > JPEG lossless transformations > Crop"
6. Confirm the message (if there should be any).
Actual behaviour (bug): XnView performs cropping. The cropped image has nothing to do with the are that you have previously selected.

Expected behaviour: XnView performs cropping. The cropped image matches the area previously selected.

Note: XnView Classic creates backups when using JPEG lossless operations named <filename.xnbak>. I can't find such backups when cropping in XnView MP, are there really no backups or am I missing something?

[vertigo]

Reproduced. And no backup file in the directory containing the image or in the program directory. Also, I see undo is an option here, which is confusing both because we've discussed it before and it was said it was too difficult to implement and because it doesn't do anything. This is extremely dangerous, IMO, because it will lead the user to think that if something goes wrong (as it does here) they can simply hit undo and get back to where they need to be, when in fact their file could be toast.

[XnTriq]

There's a correlation between this issue and the bug concerning the selection ratio: Both problems can be avoided by resetting the EXIF orientation or by deactivating Rotate images according to EXIF orientation tag (Tools → Settings... → General→ General).

8< – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – >8

Lossless JPEG cropping has to be performed along the MCU (Minimum Coded Unit) boundaries. The MCU block size of a given JPEG depends on the chroma subsampling.

After subsampling, each channel must be split into 8×8 blocks. Depending on chroma subsampling, this yields Minimum Coded Unit (MCU) blocks of size 8×8 (4:4:4 – no subsampling), 16×8 (4:2:2), or most commonly 16×16 (4:2:0).

The subsampling factor of P1010331.JPG is 4:2:2 (2×1,1×1,1×1) which results in block dimensions of W16×H8 pixels.

The top and left edge of a JPEG image must lie on an 8 × 8 pixel block boundary, but the bottom and right edge need not do so. This limits the possible lossless crop operations, and also prevents flips and rotations of an image whose bottom or right edge does not lie on a block boundary for all channels (because the edge would end up on top or left, where – as aforementioned – a block boundary is obligatory).

[…]

When using lossless cropping, if the bottom or right side of the crop region is not on a block boundary then the rest of the data from the partially used blocks will still be present in the cropped file and can be recovered.

Because XnView always uses the lowest common denominator (16×16), cropping will inevitable be off by at least a few pixels, unless the user makes the selection exactly along the MCU bounderies. That's why I've been advocating the implementation of an equivalent to Jpegcrop's Block Grid and Endpoint Snap.

• XnView MP
  • Jpeg losseless rotation isn't lossless
  • EXIF orientation info is wrong
  • EXIF:orientation is always top-left(1)
  • "cmd_rotate" & "Change EXIF orientation ONLY"
  • Lossless crop errors
  • 0.84: Set selection ratio
• XnView Classic
  • MCU grid
  • Rotation sans perte et message d'avertissement sans raison

[helmut]

There's a correlation between this issue and the bug concerning the selection ratio: Both problems can be avoided by resetting the EXIF orientation or by deactivating Rotate images according to EXIF orientation tag (Tools → Settings... → General→ General).

Thank you for confirming the bug, XnTriq. The correlation could well be.

The info that you gathered and gave on the current limitation of JPEG cropping are also very interesting. Perhaps that's something for the FAQ?

[xnview]

O.k., thank you, I can also reproduce the problem. Issue 1123 & Issue 1124 are fixed in next version.

[xnview]

This problem is supposed to be fixed in XnView MP 0.85 beta 1. Please check and confirm the bug fix here.

[vertigo]

Confirmed fixed.

[bitz4]

So this is when the backup file retention started to misbehave. In the past MP used to make xnbak files that were deleted if the operations were successful, but recently these files remained. I have a few questions, a few times in the past XnViewMP gave errors during lossless operations and the xnbak files were there alongside corrupt modified jpgs. If I disable the create backup files options, will MP return to the "old" behaviour?... making backup files in case of critical errors, removing them if operations finish successfully or keeping them if critical errors happened?... or will it not make any kind of backups even in case of critical errors?

Side note, yes, rotating image along Exif is more of a guided rotation, it's not the actual rotation of the image. It has its uses on gyroscopic devices, but on PC's it should be deactivated, showing images as they are binary. I used to have the same issue, since then, it's off and my cropping is propper.