JPG banding issue

[jfoster]

I have noticed banding in JPG renders of images with featureless skies (with a slight vignette added to them) for some time in PWP8. I have finally had a chance to investigate. I took the same 48-bit tif image and rendered it as a 4:4:4 100% jpg in both PWP7 and PWP8. Then I used the brightness curve transformation to exaggerate the contrast in both jpgs. PWP7 does a good job with slight tonal variations in a featureless sky (with a slight vignette). PWP8 doesn't do as good a job, with visible banding showing in the resulting image. See attached images.

PWP 7 JPG render:

PWP7.jpg (94.79 KiB) Viewed 3154 times

PWP 8 JPG render:

PWP8 v1.jpg (55.27 KiB) Viewed 3154 times

[jsachs]

PWP 7 used Leadtools libraries to read and write JPEGs while PWP 8 uses the Microsoft WIC libraries that are come with Windows, so I am not surprised there are small differences between them. JPEG is a rather loose standard and different implementations can produce different results, so this is not really unexpected. Not much I can do in any case since continuing to use Leadtools was not a viable option for PWP 8.

What you don't illustrate is how the original image (reduced to 8-bits/channel which is what JPEG uses) compares with the two JPEGs.

[jfoster]

Here are the (high contrast) 8-bit/chan tiff's from PWP7 and PWP8 per your suggestion:

24bit tif from PWP7:

HC_1_48bit_TIF_cnv2_24bit_TIF_first_PWP7.jpg (36.5 KiB) Viewed 3130 times

24bit tif from PWP8:

HC_1_48bit_TIF_cnv2_24bit_TIF_first_PWP8.jpg (36.5 KiB) Viewed 3130 times

[jsachs]

Interesting.

Another problem with comparing JPEG implementations is that there is no standard for what different quality settings mean. One implementation's 95% may give a different compression ratio than another. What this looks like to me is that at 100%, the Microsoft JPEG code is throwing away slightly more information than the Leadtools code. The differences are mostly in the low order bits which, under normal viewing, are nearly impossible to see. Or possibly Leadtools is doing some extra smoothing or some other proprietary processing.

What about the file sizes of the two 100% JPEG versions?

[jfoster]

The PWP7 file size of the JPEG is: 108,091 bytes

The PWP8 file size of the JPEG is: 119,252 bytes

(File size is actual file size, not "size on disk".)

JPEG rendered from same 48-bit tif using 4:4:4 100%Q. For PWP7, I unchecked "Include Profile" and "Include Comments".
For PWP8, I set Metadata to "None".

[mjdl]

JPEGsnoop is a good tool for analyzing JPEG characteristics and compression levels (open source, Windows executable, no installation required, but only for people who know all about the JPEG format, which I don't).

Anyway, I attach the output for the two jpeg images of the first post in this topic. (Can we have *.txt as an allowed file type for attachments? I had to zip these files to attach them...)

The overall compression for the PWP 8 image (Compression Ratio: 27.44:1 Bits per pixel: 0.87:1) is higher than the PWP 7 image (Compression Ratio: 15.93:1 Bits per pixel: 1.51:1). So, as you say, notions of what "100%" quality factor may mean in practice really do make a difference!

BTW, instead of using the Microsoft built-in JPEG routines for PWP8, why not try something like lib-jpeg-turbo which is an actively maintained, BSD licensed codec? There is even a NuGet package for recent Microsoft compilers https://www.nuget.org/packages/TurboJpegWrapper/ and in any case extensive documentation on the codec behaviour itself.