quality of downsampled images once JPEG compressed

[NicolasRobidoux]

Another reason I like -distort resize:

If you care about the overall quality of a destructively
compressed jpeg, a reasonable thing to do is to compare the visual
quality for a fixed final image size. In the following, I omitted the
final sharpening step. The lanczoses are pretty sharp to start with,
and sharpening makes the final file larger and also introduces more
"JPEG ringing" around sharp interfaces.

Code: Select all

# quality levels producing about the same size file:
# resize lanczos:        75 (size: 72916)
# distort lanczos:       76 (size: 71746)
# distort lanczossharp:  76 (size: 72361)
# resize lanczos2:       76 (size: 71928)
# distort lanczos2:      78 (size: 72990)
# distort lanczos2sharp: 76 (size: 72499)
# resize triangle:       80 (size: 72780)
# distort triangle:      79 (size: 72249)

# test image from http://www.pbase.com/konascott/image/69543104/original
infile="69543104.bHSz3aSK.Downsampletestimage.jpg"
filt="lanczos"
fact=25

# IM compiled with --enable-hdri

# Note: I'd rather use LAB instead of YCbCr but I can't seem to make
# it work right.

filtering="-filter $filt -distort resize"
convert $infile \
-colorspace YCbCr \
$filtering $fact% \
-colorspace sRGB \
-sampling-factor 4:2:0 -quality 76 -strip distort$filt.jpg

filtering="-filter $filt -resize"
convert $infile \
-colorspace YCbCr \
$filtering $fact% \
-colorspace sRGB \
-sampling-factor 4:2:0 -quality 75 -strip resize$filt.jpg

If you now visually compare the results of -resize and -distort resize (the two methods that give, in my opinion, the best results overall), you will see that the "JPEG ringing" is less obstrusive with -distort resize, and the -distort resize result's sharpness is more natural (which, arguably, means "softer"). Yet, the distort lanczos file is smaller.

Again, although this is subjective, it is my opinion that when combined with JPEG compression, distort lanczos (and variants) give slightly better results than their resize counterparts. (IMHO, this is also the case when no compression is used.)

There is a theoretical reason for this: EWA Jinc-windowed Jinc appears to be a better >>2D<< low-pass filter than tensor Sinc-windowed Sinc. It is, after all, a windowed version of the "ideal" (isotropic) 2D low-pass filter.

-filter lanczossharp does really well too.

P.S.

When I have a minute I'll fix the virtual pixel policy in the code. This may be skewing the results.

[NicolasRobidoux]

I just noticed that -distort resize leaves a one-pixel wide "light" band around the edge of the image.

Corrected: It is not -distort resize that leaves a "light" band around, it is unsharp. I imagine this can be fixed with an appropriate choice of alpha/virtual-pixel.

[fmw42]

I just noticed that -distort resize leaves a one-pixel wide "light" band around the edge of the image.

perhaps try different virtual-pixel methods

[NicolasRobidoux]

Anthony:

It would appear to me that it would make sense to have -distort resize automatically pick a virtual pixel policy which is consistent with resizing.

Comments?

Corrected: I think it already does. (blush)

[NicolasRobidoux]

(I'll repost when I figure out how to unsharp without the boundary "red drift.")

[NicolasRobidoux]

Results with reference file size the result of -filter lanczos -resize with JPEG compression 85:

Code: Select all

# quality levels producing about the same size file:
# resize lanczos:        85 (size: 98510)
# distort lanczos:       86 (size: 97547)
# distort lanczossharp:  86 (size: 98353)
# resize lanczos2:       86 (size: 99094)
# distort lanczos2:      87 (size: 96826)
# distort lanczos2sharp: 87 (size: 98918)
# resize triangle:       88 (size: 97843)
# distort triangle:      88 (size: 99790)

# test image from http://www.pbase.com/konascott/image/69543104/original
infile="69543104.bHSz3aSK.Downsampletestimage.jpg"
filt="triangle"
fact=25

# IM compiled with --enable-hdri

# Note: I'd rather use LAB instead of YCbCr but I can't seem to make
# it work right.

# distort:

filtering="-filter $filt -distort resize"
convert $infile \
-colorspace YCbCr \
$filtering $fact% \
-colorspace sRGB \
-sampling-factor 4:2:0 -quality 88 -strip distort$filt.jpg

# resize:

filtering="-filter $filt -resize"
convert $infile \
-colorspace YCbCr \
$filtering $fact% \
-colorspace sRGB \
-sampling-factor 4:2:0 -quality 88 -strip resize$filt.jpg

Again,

Code: Select all

-filter lanczos2sharp -distort resize

performs extremely well. It is a nudge softer than, say,

Code: Select all

-filter lanczos -resize

, but the JPEG and haloing artifacts are definitely reduced.

Code: Select all

-filter lanczossharp -distort resize

,

Code: Select all

-filter lanczos -distort resize

,

Code: Select all

-filter lanczos2 -distort resize

and of course

Code: Select all

-filter lanczos -resize

also give good results. For this test picture/task, I think that lanczos2sharp and lanczossharp distort resize are the best preformers.

[NicolasRobidoux]

When I have a minute, I'll try the idea described at the end of the first post of http://imagemagick.org/discourse-server ... =1&t=18522.

I think it's my best idea to improve the production of destructively compressed JPEG thumbnails (or at least, smaller version of the original) so far.

[anthony]

I just noticed that -distort resize leaves a one-pixel wide "light" band around the edge of the image.

Corrected: It is not -distort resize that leaves a "light" band around, it is unsharp. I imagine this can be fixed with an appropriate choice of alpha/virtual-pixel.

If you are using the DIY version of Distort resize instead of the build in one (whcih is just a direct internal implementation selecting between a no-alpha and an two pass alpha enabled version), then you could do the unsharp operation immediately after the distort, while the virtual pixels and alpha channels are still in place. Then when the alpha is turned of and the edges ae striped you will get no edge effects.

Alturnativally, just turn on alpha again, enable VP-transparent do the unsharp and turn it off. Your test image has no alpha anyway, though distort resize will have filled out the alpha channel!

Remember the same technique distort resize uses to remove VP effects, also applies to all other convolution methods, including unsharp, blur, and morphology.

[NicolasRobidoux]

Slightly improved test code:

Code: Select all

# test image from http://www.pbase.com/konascott/image/69543104/original
# reduced by 50% using -filter lanczos -distort resize 50%
infile="house.png"

# IM compiled with --enable-hdri

# The following quality levels give about the same file size:

qual="30"

convert $infile \
-colorspace YCbCr \
-separate \
\( -clone 1 -morphology Convolve '3x3: 0.0625,.125,0.0625 .125,.25,.125 0.0625,.125,0.0625' \) \
\( -clone 2 -morphology Convolve '3x3: 0.0625,.125,0.0625 .125,.25,.125 0.0625,.125,0.0625' \) \
-delete 1-2 \
-set colorspace YCbCr \
-combine \
-colorspace sRGB \
-sampling-factor 2x2 -quality $qual -strip 2x2\_$qual\_new.jpg

convert $infile \
-colorspace sRGB \
-sampling-factor 2x2 -quality $qual -strip 2x2\_$qual.jpg

# Alternative blurs:

# \( -clone 1 -morphology Convolve '3x3: 0.0,.125,0.0 .125,.5,.125 0.0,.125,0.0' \) \
# \( -clone 2 -morphology Convolve '3x3: 0.0,.125,0.0 .125,.5,.125 0.0,.125,0.0' \) \

# \( -clone 1 -define convolve:scale=.1111111111111111 -morphology Convolve '3x3: 1.,1.,1. 1.,1.,1. 1.,1.,1.' \) \
# \( -clone 2 -define convolve:scale=.1111111111111111 -morphology Convolve '3x3: 1.,1.,1. 1.,1.,1. 1.,1.,1.' \) \

Preliminary conclusions:

It appears that prefiltering the chroma leads to a reduction in file size
of roughly 1 to 3% with -sampling-factor 1x1 with minor
visual quality improvement (it sometimes improves matters near
sharp edges without ever making them worse: look at the sides of the
chimney).

With -sampling-factor 2x2 (the IM, and generally
accepted, default), the decrease in file size is minuscule (.1-1.%), but the
tiny quality improvement near (some) sharp edges is still there.

(Presumably, the size benefits are larger if the image being compressed
is not as smooth. -filter lanczos -distort resize is a pretty good low-pass
filter.)

I've tried many quality levels from 30 to 95, and -sampling-factor 1x1 and 2x2.

[fmw42]

Nicolas,

Is this a typo?


# test image from http://www.pbase.com/konascott/image/69543104/original
# reduced by 50% using -filter resize -distort resize 50%
infile="house.png"

What is -filter resize?

I presume you meant something else or have I missed something new?

Fred

[NicolasRobidoux]

...Is this a typo?...

Yes. Fixed now.

[NicolasRobidoux]

It is dangerous to make conclusions based on one test image (a good one, but no less only one), but here is:

If you absolutely want to squeeze every bit out of a JPEG without affecting the sampling of the luma, prefilter the chroma. This won't affect the visual quality much (if anything, it may improve it) but it will reduce the file size a little bit, esp. if the quality level is >= 90, even more so if you have turned off chroma subsampling (you may trim more than 5% off the final file size then; on the other hand, you probably should always turn on chroma subsampling so this last gain is kind of moot).

[NicolasRobidoux]

I'm not the first one to notice that smoothing can reduce file size without a noticeable change in quality: http://www.ampsoft.net/webdesign-l/jpeg ... ssion.html

P.S.: Apparently the GIMP asks about how much smoothing to apply when saving as JPEG: http://www.ams.org/samplings/feature-co ... ompression

(Of course my idea was to only pre-smooth the chroma channels, but anyway...)

[NicolasRobidoux]

I've put a script and some results that compares various ways of producing smaller images here
http://web.cs.laurentian.ca/nrobidoux/m ... seTest.tgz (Warning: this is fairly big.)

You probably should use the small.sh script with IM compiled so it supports hdri.

The comparison involves:

• Various distort resize methods (the filters lanczos2sharp, lanczos and lanczossharp)

• One resize method (with filter lanczos)

• Doing it "straight" ("no blur" postfix) and doing it by enlarging -define filter:blur depending on the requested quality ("blur" postfix)

The intermediate computation is done in YCbCr. Not totally sure its necessary. You certainly should NOT use this conversion if QUANTUM=8, and probably not if QUANTUM=16.

To me, it is fairly clear what combination is best for a given final file size.

Comments welcome.

[fmw42]

Doing it "straight" ("no blur" postfix) and doing it by enlarging -define filter:blur depending on the requested quality ("blur" postfix)

Can you explain what you mean by this? Sounds like minifying by enlarging, but that seems rather strange.

Unfortunately, I am not in HDRI mode right now to play with it.

Is any Q level OK in HDRI, ie. Q8 HDRI or Q16 HDRI or do you mean only Q32 HDRI?

Fred