by XnTriq (Posted Tue Feb 21, 2017 5:00 am)
There's a correlation between this issue![:bugconfirmed:]( "Bug - Confirmed")
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.
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.
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.
Read Main Topic
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.
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. It is also possible to transform between baseline and progressive formats without any loss of quality, since the only difference is the order in which the coefficients are placed in the file.
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
- XnView Classic
Read Main Topic