Hi )
XnConvert and XnView MP have is bad quality in decoding from JPEG files
Previous I considered the issue in the topic viewtopic.php?f=79&t=48274&p=202831#p202831 , but all still worse than I thought )
Giant_planes_comparison.svg - original picture
svg_to_bmp.bmp - this is transcoding from SVG to BMP in XnView MP
bmp_to_jpg.jpg - this is transcoding from BMP to JPG in XnView MP with maximum quality for JPEG plugin all set on maximum quality
from-jpeg-to-bmp-xn.bmp - this is backward transcoding from JPEG to BMP in XnView MP
from-jpeg-to-bmp-acd.bmp - this is backward transcoding from JPEG to BMP in ACDSee Pro 8
If compare images , so can see diffirence in colors in original and XnView MP , but this diffirence absent if compare original and ACDSee Pro
PSNR if compare svg_to_bmp.bmp to bmp_to_jpg.jpg - 59,81
PSNR if compare svg_to_bmp.bmp to from-jpeg-to-bmp-xn.bmp - 36,8
PSNR if compare svg_to_bmp.bmp to from-jpeg-to-bmp-acd.bmp - 59,81
That's why I think , what need increase quality JPEG decoding in XnView MP and XnConvert )
Also digital noise in XnView MP /XnConvert make files bigger if perform transcoding to any other compression format )
This is happening if use progressive compression ) , backward transcoding from progressive JPEG not coincide with original JPEG file and transcoded JPEG progressive to BMP file
Bad quality decoding JPEG files
Moderators: XnTriq, helmut, xnview
-
- Posts: 197
- Joined: Sat Jan 05, 2019 1:16 pm
Bad quality decoding JPEG files
You do not have the required permissions to view the files attached to this post.
-
- Posts: 197
- Joined: Sat Jan 05, 2019 1:16 pm
Re: Bad quality decoding JPEG files
Here error , I'm export as BMP RGB565 for XnView MP , I'm not understand , why about this not was report to me ?
You do not have the required permissions to view the files attached to this post.
-
- Moderator & Librarian
- Posts: 6427
- Joined: Sun Sep 25, 2005 3:00 am
- Location: Ref Desk
Re: Bad quality decoding JPEG files
Is this due to rounding errors during color space transformation from YCrCb to RGB, Pierre?
-
- Moderator & Librarian
- Posts: 6427
- Joined: Sun Sep 25, 2005 3:00 am
- Location: Ref Desk
Re: Bad quality decoding JPEG files
My tests so far:
XnView_Classic.png ≠ Adobe_Potoshop_CS2.png ≠ Gimp.png ≠ MS_Paint.png
FYI: According to Progressive JPEG Visualization Tool, bmp_to_jpg.jpg is a progressive JPEG with 13 (!) scans.
- I converted bmp_to_jpg.jpg to BMP with several programs.
- I converted the resulting BMPs to PNG with PngOptimizer.
- I did a binary comparison of the resulting PNGs with Compare It!.
XnView_Classic.png ≠ Adobe_Potoshop_CS2.png ≠ Gimp.png ≠ MS_Paint.png

FYI: According to Progressive JPEG Visualization Tool, bmp_to_jpg.jpg is a progressive JPEG with 13 (!) scans.
-
- Posts: 197
- Joined: Sat Jan 05, 2019 1:16 pm
-
- Moderator & Librarian
- Posts: 6427
- Joined: Sun Sep 25, 2005 3:00 am
- Location: Ref Desk
Re: Bad quality decoding JPEG files
- StackExchange: Is a JPG guaranteed to produce the same pixels?
- XnView Forum: Discrepancies in display of JPEG images
https://github.com/google/knusperli wrote:The goal of Knusperli is to reduce blocking artifacts in decoded JPEG images, by interpreting quantized DCT coefficients in the image data as an interval, rather than a fixed value, and choosing the value from that interval that minimizes discontinuities at block boundaries.
-
- Moderator & Librarian
- Posts: 6427
- Joined: Sun Sep 25, 2005 3:00 am
- Location: Ref Desk
Re: Bad quality decoding JPEG files
I'm referring to RGB to YCbCr conversion:
- JPEG encoding = RGB → YCbCr
- JPEG decoding = YCbCr → RGB
You do not have the required permissions to view the files attached to this post.
-
- Moderator & Librarian
- Posts: 6427
- Joined: Sun Sep 25, 2005 3:00 am
- Location: Ref Desk
Re: Bad quality decoding JPEG files
https://photo.stackexchange.com/questions/83745#83892 wrote:No, decoding is not guaranteed to always be the same. However, the differences are guaranteed to be very, very small.
[…]
Unlike bmp or png, a jpeg doesn't store the pixels themselves but a description of the image. To reconstruct the individual pixels a complex mathematical algorithm is used. After every step, the algorithm stores the result in memory. This is where things can go wrong: a value in memory has a certain precision, the machine precision. Because of this the value has to be rounded. While the specifications ensure that a minimal precision is used for, there is no maximum. The rounding may thus be different for each implementation. It can even be depending on the hardware used, as some processors use more bits of precision than demanded. Some early Pentium processors even did it plain wrong.
Tiny oversimplified example: calculating 5 * 0.12 by repeated addition.
Storing intermediate values using one digit of precision, a computer might do this: 0.12 + 0.12 = 0.24, store intermediate result as 0.2 (rounding down). Then calculate 0.2 + 0.12 = 0.32, store as 0.3 (again, rounding down). Continue this pattern and the result will be 0.5 instead of the expected result of 0.6. If a higher precision was used (two digits, for example), the result would have been different.