0.84: JPEG lossless cropping is completely off

Reported bugs that have been closed and/or resolved

Moderators: XnTriq, xnview, Dreamer

User avatar
helmut
Posts: 8127
Joined: Sun Oct 12, 2003 6:47 pm
Location: Frankfurt, Germany

0.84: JPEG lossless cropping is completely off

Postby helmut » Mon Feb 20, 2017 10:38 pm

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. :bug:

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
Posts: 112
Joined: Wed Feb 15, 2017 3:49 pm

Re: 0.84: JPEG lossless cropping is completely off

Postby vertigo » Tue Feb 21, 2017 12:45 am

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.

User avatar
XnTriq
Moderator & Librarian
Posts: 5190
Joined: Sun Sep 25, 2005 3:00 am
Location: Ref Desk

Re: 0.84: JPEG lossless cropping is completely off

Postby XnTriq » Tue Feb 21, 2017 5:00 am

There's a correlation between this issue :bugconfirmed: 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 (ToolsSettings...GeneralGeneral).

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.

Wikipedia (JPEG → Block splitting) wrote: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.

Wikipedia (JPEG → Lossless editing) wrote: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.


User avatar
helmut
Posts: 8127
Joined: Sun Oct 12, 2003 6:47 pm
Location: Frankfurt, Germany

Re: 0.84: JPEG lossless cropping is completely off

Postby helmut » Tue Feb 21, 2017 3:42 pm

XnTriq wrote:There's a correlation between this issue :bugconfirmed: 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 (ToolsSettings...GeneralGeneral).
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?

User avatar
xnview
Author of XnView
Posts: 28775
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: 0.84: JPEG lossless cropping is completely off

Postby xnview » Mon Feb 27, 2017 3:40 pm

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

User avatar
xnview
Author of XnView
Posts: 28775
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: 0.84: JPEG lossless cropping is completely off

Postby xnview » Thu Mar 16, 2017 8:54 am

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

vertigo
Posts: 112
Joined: Wed Feb 15, 2017 3:49 pm

Re: 0.84: JPEG lossless cropping is completely off

Postby vertigo » Thu Mar 16, 2017 9:50 am

Confirmed fixed.


Return to “Closed/Resolved”

Who is online

Users browsing this forum: No registered users and 0 guests