Basic understanding of "JPEG Quality"?

[XnTriq]

The XnView file 'info' displays 'Subsampling', so in principle that could be read and an image resaved using Use estimated original quality (when possible) with the same subsampling, even if you say that is not implemented now?

Could you please rephrase or elaborate on your question, cday?

Code: Select all

Filename            1_converted.jpg
File size           94.87 KiB (97.143)
Format              JPEG TrueColor (v1.1)
Width               580
Height              300
# of bits           24
Color model         RGB
DPI                 72 x 72
Print size          20.46x10.58 cm, 8.06x4.17 inches
Compression         JPEG
Progressive mode    No
Sub-sampling        1x1,1x1,1x1
Estimated quality   100
Images/frames count 1
Origin              Top-Left

Code: Select all

Filename            2_resaved.jpg
File size           55.25 KiB (56.580)
Format              JPEG TrueColor (v1.1)
Width               580
Height              300
# of bits           24
Color model         RGB
DPI                 72 x 72
Print size          20.46x10.58 cm, 8.06x4.17 inches
Compression         JPEG
Progressive mode    No
Sub-sampling        2x2,1x1,1x1
Estimated quality   100
Images/frames count 1
Origin              Top-Left

BTW: A chroma subsampling ratio of 1×1,1×1,1×1 = 4:4:4 = full horizontal + vertical resolution = no sub-sampling

[cday]

And if Use estimated original quality (when possible) is used?

It depends. Let's say your JPEG that was previously saved without chroma subsampling i.e. 1×1,1×1,1×1 (best quality). Re-saving/re-encoding this JPEG with a SubSampling factor of 2×2,1×1,1×1 (default) inevitably introduces additional loss in quality. As mentioned before, the Use estimated original quality if possible setting only takes the (estimated) “quality factor” (1 – 100) into account.

The XnView file 'info' displays 'Subsampling', so in principle that could be read and an image resaved using Use estimated original quality (when possible) with the same subsampling, even if you say that is not implemented now?

Could you please rephrase or elaborate on your question, cday?

You were making the point that resaving inevitably entails loss of perceived image quality. You illustrated that point using an example where the image might, when saved when using Use original quality (when possible), be saved with different subsampling (or whatever) settings, as that parameter wasn't considered.

My point was that xnview software can detect the subsampling (or whatever) settings that were used when the file was last saved -- that information can be determined when the file is opened, and is displayed in the file information display -- therefore saving using Use original quality (when possible) could in principle take account of that information, and so avoid the source of the loss mentioned in you example above.

However, whether xnview software could be modified to eliminate one source of possible perceived image quality loss when a file is resaved is, I accept, a side issue that complicates the immediate discussion relating back to the issue raised in Peter2's original post.

So, if an image were to be opened and then resaved repeatedly, what would you expect the final 'quality' to be if a file with initial Q = 80 is resaved ten times:

0.80 * 0.80 * 0.80 * 0.80 * 0.80 * 0.80 * 0.80 * 0.80 * 0.80 * 0.80 * 0.80 = 0.107 ?

There would be a very obvious loss of perceived image quality?

[cday]

So, if an image were to be opened and then resaved repeatedly, what would you expect the final 'quality' to be if a file with initial Q = 80 is resaved ten times:

0.80 * 0.80 * 0.80 * 0.80 * 0.80 * 0.80 * 0.80 * 0.80 * 0.80 * 0.80 * 0.80 = 0.107 ?

I have now performed a test to find the answer: I selected an image having a high level of detail, in particular straight edges that would be most likely to reveal the predicted loss of detail after being resaved many times, a clock face.

I first saved a downloaded clock face image in XnView MP at Q=80, then used a batch file to save the resulting image to a new file, then saved the resulting image to a further image, and so on until the original high quality image had been resaved a total of 10 times. All saves were made at Q=80 as above, using the following code:

Code: Select all

nconvert.exe -out jpeg -q 80 -o  S1.jpg S0.jpg
nconvert.exe -out jpeg -q 80 -o  S2.jpg S1.jpg
nconvert.exe -out jpeg -q 80 -o  S3.jpg S2.jpg
nconvert.exe -out jpeg -q 80 -o  S4.jpg S3.jpg
nconvert.exe -out jpeg -q 80 -o  S5.jpg S4.jpg
nconvert.exe -out jpeg -q 80 -o  S6.jpg S5.jpg
nconvert.exe -out jpeg -q 80 -o  S7.jpg S6.jpg
nconvert.exe -out jpeg -q 80 -o  S8.jpg S7.jpg
nconvert.exe -out jpeg -q 80 -o  S9.jpg S8.jpg
nconvert.exe -out jpeg -q 80 -o S10.jpg S9.jpg

It would be expected from the discussion above that an image resaved 10 times would show a substantial loss of quality, the calculated Q=0.107 value would be a very low quality setting, so how did the final image compare with the original image? Was there indeed a substantial loss of quality?

The image below s0 is the original image that was resaved 10 times:

S1.jpg

[s0]


The image below s10 is the same image after being resaved 10 times at Q=80:

S10.jpg

Compare the two images, is the lower image obviously quite unusable as predicted? For easier comparison, save each image, and then open the two images in adjacent tabs in XnView MP. Then if you like, zoom in and lock the zoom in each image for a really close comparison.

Zooming in, it is possible to see some slight loss of quality, but doesn't the image above remain quite usable for any reasonable purpose?

Details of the two images are: Width 1789px, Height 1752px, DPI 240 x 240, Sub-sampling 2x2, 1x1, 1x1 and 'Estimated quality' 80.

Those file properties are as displayed in XnView MP 'File information', which displayed the second image as still having Q=80...

Although the original file was selected for its high level of detail, the reasonably large image pixel dimensions are probably favourable for maintaining quality. A slight improvement in the output image quality might be expected if sub-sampling 2x2, 1x1, 1x1 were used. File size was very slightly decreased by the first save. The fact that all saves were made using the same software is probably relevant, in this case NConvert.

[XnTriq]

Thank you very much, cday I'll get back to you ASAP!

[XnTriq]

Compare the two images, is the lower image obviously quite unusable as predicted?
Zooming in, it is possible to see some slight loss of quality, but doesn't the image above remain quite usable for any reasonable purpose?

While the (loss in) quality may be acceptable to you and me, most serious photographers probably wouldn't agree.

I selected an image having a high level of detail, in particular straight edges that would be most likely to reveal the predicted loss of detail after being resaved many times, a clock face.

Remember that gradients are susceptible to colour banding caused by JPEG compression.

File size was very slightly decreased by the first save.

Assumingly because the ICC profile embedded in Big_Ben_Clock_Face.jpg @ Wikimedia Commons was discarded.

Code: Select all

-icc              : Use ICC Profile
-keep_icc         : Keep ICC Profile from original file
-icc_in filename  : Input color profile
-icc_out filename : Output color profile
-icc_intent value : Intent value
-icc_bcp          : Black point compensation
-icc_ie           : Ignore embedded ICC profile

[XnTriq]

I apologize for hijacking your thread, Peter

The idea behind it is that I use "nconvert.exe" to add text in multiple lines. Because (at the moment) there is no multiline-feature, I have to repeat "write line - save jpg - write line - save ..."
And I want to avoid the loss of quality.

Recommended workflow:

1. Convert original image from JPEG to PNG.
2. Add text to PNG(s).
3. Convert resulting PNG to JPEG as losslessly as possible.

01.jpg

Code: Select all

nconvert.exe -text_font InputMono 16 -text_color 255 255 255 -text_back 0 0 0 -text_pos 8   8 -text " second  generation " -out png -clevel 9 -o X:\Test\02.png X:\Test\01.jpg
nconvert.exe -text_font InputMono 16 -text_color 255 255 255 -text_back 0 0 0 -text_pos 8  28 -text " third   generation " -out png -clevel 9 -o X:\Test\03.png X:\Test\02.png
nconvert.exe -text_font InputMono 16 -text_color 255 255 255 -text_back 0 0 0 -text_pos 8  48 -text " fourth  generation " -out png -clevel 9 -o X:\Test\04.png X:\Test\03.png
nconvert.exe -text_font InputMono 16 -text_color 255 255 255 -text_back 0 0 0 -text_pos 8  68 -text " fifth   generation " -out png -clevel 9 -o X:\Test\05.png X:\Test\04.png
nconvert.exe -text_font InputMono 16 -text_color 255 255 255 -text_back 0 0 0 -text_pos 8  88 -text " sixth   generation " -out png -clevel 9 -o X:\Test\06.png X:\Test\05.png
nconvert.exe -text_font InputMono 16 -text_color 255 255 255 -text_back 0 0 0 -text_pos 8 108 -text " seventh generation " -out png -clevel 9 -o X:\Test\07.png X:\Test\06.png
nconvert.exe -text_font InputMono 16 -text_color 255 255 255 -text_back 0 0 0 -text_pos 8 128 -text " eighth  generation " -out png -clevel 9 -o X:\Test\08.png X:\Test\07.png
nconvert.exe -text_font InputMono 16 -text_color 255 255 255 -text_back 0 0 0 -text_pos 8 148 -text " ninth   generation " -out png -clevel 9 -o X:\Test\09.png X:\Test\08.png
nconvert.exe -text_font InputMono 16 -text_color 255 255 255 -text_back 0 0 0 -text_pos 8 168 -text " tenth   generation " -out jpeg -q 100 -opthuff -dct 2 -smoothingf 0 -subsampling 2 -o X:\Test\10.jpg X:\Test\09.png

10.jpg

Code: Select all

-clevel value      : PNG Compression level (default : 6)
-q value           : JPEG/FPX/WIC/PDF quality (default : 85)
-opthuff           : Optimize Huffman Table (JPEG)
-dct value         : DCT method
    0  : Slow
    1  : Fast
    2  : Float
-smoothingf value  : Smoothing factor (0-10)
-subsampling value : Subsampling factor
    0  : 2x2,1x1,1x1
    1  : 2x1,1x1,1x1
    2  : 1x1,1x1,1x1

[cday]

The idea behind it is that I use "nconvert.exe" to add text in multiple lines. Because (at the moment) there is no multiline-feature, I have to repeat "write line - save jpg - write line - save ..."
And I want to avoid the loss of quality.

I was going to return to Peter2's problem, and to report the results of a further test I did yesterday. My test, in the same way as XnTriq's test above, wrote successive lines of text to an image, so that any perceptible loss of quality as the image was repeatedly resaved could be seen.

In my test successive output images were resaved as JPEGs, so the perceived level of quality loss in each resave is directly relevant to the discussion above as it has evolved, however the use in XnTriq's test of the PNG format as a lossless format for the intermediate images created is a valuable advance on best meeting Peter2's need.

This was the result of my test in which 10 lines of text were written successively with each resulting image resaved with Q=80 :

S10.jpg

Writing text to an image of typical pixel dimensions in some ways isn't easy, as the number of pixels available to form the text characters will often be quite limited. At a quick look, the above result could be considered passable for general use, where it will be looked at quickly to read the text rather than critically examined.

Looking more closely, and especially zoomed in on the downloaded image, a slight but clear deterioration in the quality of the text characters can be easily seen, with typical JPEG compression artifacts in the form of faint 'smudges' outside the edges of the characters. The lines were written in numerical order from the top, so lines high up have been resaved more times than those lower down. On closer inspection a slightly lower compression setting would be better, though.

Another illustration of the possibilities and the limitations of JPEG resaving, but for Peter2's problem until multi-line text support is added to NConvert, XnTriq's use of PNG for intermediate lossless resaving is a valuable contribution.

This again illustrates that repeated resaving of a JPEG image does not inevitably result in a rapid loss of quality.

[Updated.]

[Peter2]

Hi @cday and @XnTriq

after some days of missing emails I just saw the progress of the discussion here and I'm sure that many users will benefit from this high level contributions.

For my current user case I have to handle maybe 200-300 photos a day, taken a simple documentation of the situation and progress on a construction site. This is why "I'm swimming in rather shallow water" and don't have to work for professional photographers requirements. I will take the code from XnTriq in the post above and see what results I will get.

Thanks a lot and good luck!

[XnTriq]

Danke for reporting back, Peter!


@Pierre: What's the value range of nConvert's -q parameter (0-99 or 1-99 or 0-100 or 1-100)

Ranges of quality settings differ in each implementation, but the IJG values range from 99 (best) to 1 (worst). Please note that these are not percentages, nor is there a direct correlation with the final file size. The example at the top of the page uses an IJG quality setting of 50, and has a file size ratio of roughly 20:1. Anytime you read that an image has been compressed with 10:1 Jpeg quality, you should know that this is slightly misleading (see digital cameras below).

[XnTriq]

The idea behind it is that I use "nconvert.exe" to add text in multiple lines. Because (at the moment) there is no multiline-feature, I have to repeat "write line - save jpg - write line - save ..."
And I want to avoid the loss of quality.

XnView v2.49.5 (LIBFORMAT v7.70):

• Ghostscript detection
• TIFF - viewtopic.php?f=35&t=41136
• HEIF plugin - viewtopic.php?f=36&t=41104
• Old versions of ghostscript not recognized
• NConvert: -use_org_quality - viewtopic.php?f=57&t=41397
• NConvert: multiple text lines - viewtopic.php?f=57&t=41358

[Peter2]

Thanks @XnTriq

in the meantime the multiple-single-line version is under testing, but I will take a look.

[Peter2]

.. I will take a look.

5min quick-test: Works fine with \n for Linefeed

Code: Select all

"c:\Program Files (x86)\XnView\nconvert.exe" -out jpeg -ratio -rtype lanczos -rflag decr -text_font "MS Shell Dlg 2" 20 -text_color 255 0 0 -text_back 255 255 255 -text_flag top-left -text_pos 10 10 -text_rotation 0 -text "Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Morbi congue velit ac nisl. Pellentesque viverra volutpat sem. Cra.\nlobortis, massa et adipiscing sollicitudin, pede dui tempor lorem, at scelerisque massa nunc vitae magna. Etia.\nlaoreet. Aliquam volutpat, ipsum eget accumsan egestas, mi eros euismod tortor, sit amet vulputate leo orc.i " -o "d:\xxx\aus.jpg"   "d:\xxx\ein.png"

[j7n]

When an image is repeatedly saved with color subsampling, the bleeding will progressively increase because the chroma is interpolated on load into XnView and decimated again. I do not know about the command-line application. There would be little generation loss if the color was left "blocky , but it would usually look worse with natural images. Text and drawings could benefit from it and avoid the gamma error that occurs during interpolation leading to dark glow in extreme color transitions.

The Cambridge in Colour gradient does does not contain any detail to show the effect. But it is apparent around artificial text with color around it or other fine lines (such as the image that says "tenth generation").

5 and 15 generations with other software I made earlier, but the same library.
https://i.imgur.com/wzRB4BE.png

[XnTriq]

Your post from last year also fits right in, j7n

What quality setting would you recommend? How big should a photo be (file size, 880px height)?

JPEG is close to being perceptually lossless in a photo at about q 95 and no color subsampling (1x 1x 1x). Very clean, artificial images might require q 98. The useful range of the quality slider is between 90 and 99. The IJG scale is rather misleading with so many steps of extreme quantization, and subsampling being enabled by default in most programs. Photoshop only goes as low as about 60 on its 1-12 scale.

If the image already has low sharpness (due to being upscaled in the camera) or contains noise, then the additional degradation from JPEG might not be noticable at around q 90. At a height of only 880 pixels, your image will likely be viewed at a close distance and can't tolerate any quality reduction.

The file size at a given quality depends on the amount of detail (texture, noise) and whether that detail varies greatly in color.

Would you mind sharing which diff software you used?

5 and 15 generations with other software I made earlier, but the same library.
https://i.imgur.com/wzRB4BE.png

[j7n]

I used layer blending mode Difference in Photoshop, and increased the contrast with Levels.