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?
0.84: JPEG lossless cropping is completely off
Moderators: XnTriq, helmut, xnview, Dreamer
Re: 0.84: JPEG lossless cropping is completely off
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.
Re: 0.84: JPEG lossless cropping is completely off
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.
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.
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=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).
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.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.
Re: 0.84: JPEG lossless cropping is completely off
Thank you for confirming the bug, XnTriq. The correlation could well be.XnTriq wrote: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).
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?
Re: 0.84: JPEG lossless cropping is completely off
O.k., thank you, I can also reproduce the problem. Issue 1123 & Issue 1124 are fixed in next version.
Pierre.
Re: 0.84: JPEG lossless cropping is completely off
This problem is supposed to be fixed in XnView MP 0.85 beta 1. Please check and confirm the bug fix here.
Pierre.
Re: 0.84: JPEG lossless cropping is completely off
Confirmed fixed.
Re: 0.84: JPEG lossless cropping is completely off
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.
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