0.84: JPEG lossless cropping is completely off

Reported bugs that have been closed and/or resolved

Moderators: XnTriq, xnview, Dreamer

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

0.84: JPEG lossless cropping is completely off

Post by 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: 115
Joined: Wed Feb 15, 2017 3:49 pm

Re: 0.84: JPEG lossless cropping is completely off

Post by 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: 5313
Joined: Sun Sep 25, 2005 3:00 am
Location: Ref Desk

Re: 0.84: JPEG lossless cropping is completely off

Post by 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 → [url=http://en.wikipedia.org/wiki/JPEG#Block_splitting]Block splitting[/url]) 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 → [url=https://en.wikipedia.org/wiki/JPEG#Lossless_editing]Lossless editing[/url]) 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: 8145
Joined: Sun Oct 12, 2003 6:47 pm
Location: Frankfurt, Germany

Re: 0.84: JPEG lossless cropping is completely off

Post by 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: 30032
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: 0.84: JPEG lossless cropping is completely off

Post by 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: 30032
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: 0.84: JPEG lossless cropping is completely off

Post by 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: 115
Joined: Wed Feb 15, 2017 3:49 pm

Re: 0.84: JPEG lossless cropping is completely off

Post by vertigo » Thu Mar 16, 2017 9:50 am

Confirmed fixed.

bitz4
Posts: 36
Joined: Sun Apr 18, 2010 5:03 am

Re: 0.84: JPEG lossless cropping is completely off

Post by bitz4 » Sat Mar 17, 2018 3:49 pm

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.
MP 0.90 x64, Win 7 64-bit

Post Reply