bizarre drop in quality on no-op convert on small JPEG

[bugbear]

I think I'm hitting some inappropriate special case code.

I was developing a shell script to do (something trivial).

But my output was poor quality. I edited the script down and down, and eventually found that this command:

convert src.jpg dst.jpg

was enough to cause trouble.

The src is only 122x283 pixels.

But if I do:
convert src.jpg png:- | convert - dst.jpg

everything's fine.

It's something to do with the exact form of the src JPEG. If I edit it in GImp (even trivially) everything's fine.

My version is
Version: ImageMagick 6.6.5-10 2011-11-03 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2010 ImageMagick Studio LLC
Features: OpenMP

running on Fedora 15

Oh - test data you say?

http://www.papermule.co.uk/cgi-bin/pm/w ... es/src.jpg
http://www.papermule.co.uk/cgi-bin/pm/w ... es/dst.jpg

BugBear

[fmw42]

By using PNG as the intermediate, I think you are just getting a change in gamma and rendering intent. That causes a change in coloration (brightness) that makes it look better. If you use MIFF:-, you get the same result as leaving the pipe out.

But I will defer the IM developers. I do not think this is a bug. JPG has to be decompressed when read, then recompressed when written in IM. Thus an inevitable loss in quality. If you just want a copy, then use some other tool such as jpegtran or the like that will copy without the decompression/recompression.

[bugbear]

By using PNG as the intermediate, I think you are just getting a change in gamma and rendering intent. That causes a change in coloration (brightness) that makes it look better. If you use MIFF:-, you get the same result as leaving the pipe out.

But I will defer the IM developers. I do not think this is a bug. JPG has to be decompressed when read, then recompressed when written in IM. Thus an inevitable loss in quality. If you just want a copy, then use some other tool such as jpegtran or the like that will copy without the decompression/recompression.

I didn't post a sample of "success" because dest is visually identical to src. I don't believe this a simple decomp-recomp artefact, the degradation is too extreme.

My actual "use case" was thumbnail generation, but my thumbnail looked also. Careful elimination got it down to the case posted.

To repeat if I pull src.jpg into Gimp, edit a single pixel, and save it back as "newsrc.jpg", at quality 99I can use
convert newsrc.jpg dst.jpg and get a "maximum quality" result.

However, you HAVE demonstrated that whatever the oddness is, it is preserved by the MIFF format.

BugBear

[glennrp]

src.jpg was created with JPEG quality 50.
When converting directly from src.jpg to dst.jpg, the same "50" is used for the second compression and further loss is incurred.
If you convert to PNG and then to JPEG, the original quality from src.jpg is forgotten and convert falls back on its default which is 92.
If you do "convert src.jpg -quality 92 dst.jpg" then dst.jpg is visually indistinguishable from src.jpg

[bugbear]

src.jpg was created with JPEG quality 50.
When converting directly from src.jpg to dst.jpg, the same "50" is used for the second compression and further loss is incurred.
If you convert to PNG and then to JPEG, the original quality from src.jpg is forgotten and convert falls back on its default which is 92.
If you do "convert src.jpg -quality 92 dst.jpg" then dst.jpg is visually indistinguishable from src.jpg

Ah - I can see the "50" in identify -verbose.

But your proposed solution has no effect - dst.jpg still looks terrible.

Might this be a version thing - I'm on 6.7.5-6 under fedora 16?

BugBear

[fmw42]

This works reasonably for me on IM 6.8.0.4 Q16


convert 1src.jpg -quality 100 1dst.jpg


The text is fine, the penguins are slightly blurred. This is to be expected as even with 100% quality, there is still compression losses with jpg.

[glennrp]

Using -quality 92 (or even -quality 99) does have some effect; some of the artifacts are reduced, but the image still looks blocky. I get the same result with 6.7.5-6 and 6.8.0-5.

[bugbear]

I don't think people are seeing what I'm seeing:

I have now run:

Code: Select all

convert src.jpg dst.jpg 
convert src.jpg -quality 80 dst80.jpg 
convert src.jpg -quality 95 dst95.jpg 
convert src.jpg -quality 100 dst100.jpg 

used "xv" to display them all on a gray wallpapered desktop, and made a screen shot using GIMP, saved a png.

Here it is, showing
src, dst, dst80, dst95, dst100.



That cannot be right. Event dst100 is monstrously degraded.

My version is

Code: Select all

convert -version
Version: ImageMagick 6.7.5-6 2012-08-11 Q16 http://www.imagemagick.org
Copyright: Copyright (C) 1999-2012 ImageMagick Studio LLC
Features: OpenMP    

I wouldn't be worried, but I've now run across this issue (which I mentally think of as "poisoned jpegs") in a context where my "png stream" workaround cannot be applied.

BugBear

[snibgo]

The source is CMYK. Gimp is converting to RGB. By default, IM isn't (or perhaps is converting to RGB then converting back to CMYK). When I do this ...

Code: Select all

convert src.jpg -colorspace RGB -quality 100 srcS.jpg

... I get the same sharp result as Gimp.

[bugbear]

The source is CMYK. Gimp is converting to RGB. By default, IM isn't (or perhaps is converting to RGB then converting back to CMYK). When I do this ...

Code: Select all

convert src.jpg -colorspace RGB -quality 100 srcS.jpg

... I get the same sharp result as Gimp.

Hell's teeth! I think you've at least narrowed it down. Thankyou!

So; my issue relates (somehow) to CMYK images.

And the "png" technique I described above (happens to...) convert the CMYK to RGB.

Code: Select all

convert src.jpg png:- | convert - dst.jpg

My question now becomes more specific; why does saving a CMYK in JPEG blur so badly?

Moreover (in my other testing) I have found that some RGB JPEGS, when converted to CMYK
and saved as JPEG blur very badly (regardless of quality setting), but others do not.

I have yet to isolate the driving factor for this.

BugBear

[bugbear]

This is just getting weirder.

Whatever the driving factor is, it survives conversion to png.

In other words, if

convert rgb_sample.jpg -colorspace CMYK -quality 95 dst.jpg

shows the blurring in dst.jpg,

convert rgb_sample.jpg intermediate,png
convert intermediate,png -colorspace CMYK -quality 95 dst.jpg

also shows the blurring in dst.jpg.

Clues (very much) welcomed.

BugBear

[bugbear]

I have now tried the converse. The "poison" does NOT survive raw format:

http://www.imagemagick.org/script/formats.php

Code: Select all

convert src.jpg -depth 8 cmyk:- | convert -size '122x283' -depth 8 cmyk:- -quality 95 dst.jpg

Gives a "perfect" quality output, in cmyk.

Further

Code: Select all

convert dst.jpg- -quality 95 dst2.jpg

gives a dst2.jpg of good quality; the poison is gone.

Here is a diff of identify -verbose on src.jpg and dst.jpg

Code: Select all

1c1
< Image: src.jpg
---
> Image: dst.jpg
21,24c21,24
<       mean: 38.4949 (0.15096)
<       standard deviation: 71.549 (0.280584)
<       kurtosis: 2.34845
<       skewness: 1.86117
---
>       mean: 38.4855 (0.150923)
>       standard deviation: 71.5152 (0.280452)
>       kurtosis: 2.3415
>       skewness: 1.85984
28,31c28,31
<       mean: 32.7909 (0.128592)
<       standard deviation: 64.7241 (0.25382)
<       kurtosis: 3.5187
<       skewness: 2.12547
---
>       mean: 32.7908 (0.128591)
>       standard deviation: 64.7217 (0.253811)
>       kurtosis: 3.51931
>       skewness: 2.1256
35,38c35,38
<       mean: 26.5976 (0.104304)
<       standard deviation: 59.6359 (0.233866)
<       kurtosis: 4.37049
<       skewness: 2.36316
---
>       mean: 26.6068 (0.10434)
>       standard deviation: 59.634 (0.233859)
>       kurtosis: 4.37225
>       skewness: 2.3635
42,45c42,45
<       mean: 5.79291 (0.0227173)
<       standard deviation: 26.0172 (0.102028)
<       kurtosis: 30.3506
<       skewness: 5.31594
---
>       mean: 5.81214 (0.0227927)
>       standard deviation: 26.0192 (0.102036)
>       kurtosis: 30.322
>       skewness: 5.31426
50,53c50,53
<       mean: 25.9191 (0.101643)
<       standard deviation: 58.1846 (0.228175)
<       kurtosis: 6.05043
<       skewness: 2.65617
---
>       mean: 25.9238 (0.101662)
>       standard deviation: 58.1733 (0.228131)
>       kurtosis: 6.04483
>       skewness: 2.65537
72c72
<   Quality: 50
---
>   Quality: 95
75,85c75,76
<     date:create: 2012-11-09T14:39:40+00:00
<     date:modify: 2012-11-09T14:39:40+00:00
<     exif:DateTime: 2012:09:20 13:24:04
<     exif:ExifImageLength: 283
<     exif:ExifImageWidth: 122
<     exif:ExifOffset: 134
<     exif:ImageLength: 283
<     exif:ImageWidth: 122
<     exif:ResolutionUnit: 2
<     exif:XResolution: 72/1
<     exif:YResolution: 72/1
---
>     date:create: 2012-12-19T10:44:31+00:00
>     date:modify: 2012-12-19T10:44:31+00:00
87,96c78,79
<     jpeg:sampling-factor: 2x2,1x1,1x1,2x2
<     rdf:Alt:   
<     signature: 703a8ea16261924b55f06cf4a1f615ece8d7f8a0760d76b5fdc97c524152c684
<   Profiles:
<     Profile-8bim: 94 bytes
<     Profile-exif: 166 bytes
<     Profile-iptc: 36 bytes
<       unknown[2,0]: 
<       Image Name[2,5]: 64624-10-4.id425811.pdf
<     Profile-xmp: 3496 bytes
---
>     jpeg:sampling-factor: 1x1,1x1,1x1,1x1
>     signature: fd4b70bce6bd5ed717ed30e7a48337eaaeb5a9f84c25003dcf6ded8c5e2c75c3
100c83
<   Filesize: 8.55KB
---
>   Filesize: 15KB
102,104c85,87
<   Pixels per second: 3.453MB
<   User time: 0.000u
<   Elapsed time: 0:01.009
---
>   Pixels per second: 345.26TB
>   User time: 0.010u
>   Elapsed time: 0:01.000

The two most likely culprits appear to be Quality (but we've sort of eliminated that already) and "jpeg:sampling-factor"

Anyone know how Properties:jpeg:sample-factor is managed?

BugBear

[glennrp]

No downsampling is used when quality is 91 or more. For lower values of quality, the U and V channels are downsampled by a factor of 2. You can override that default behaviour with "-define jpeg:sampling-factor=geometry". Look at "-define" and "-quality" on the Commandline-Tools/Options page.

[bugbear]

No downsampling is used when quality is 91 or more. For lower values of quality, the U and V channels are downsampled by a factor of 2. You can override that default behaviour with "-define jpeg:sampling-factor=geometry". Look at "-define" and "-quality" on the Commandline-Tools/Options page.

I think my bug is caused by a defined jpeg:sampling-factor propagating inappropriately from the input to the output of a convert, although it only seems to affect CMYK outputs.

I tried (as per documentation):

Code: Select all

convert src.jpg +define "jpeg:sampling-factor" dst.jpg

but got:

Code: Select all

convert: no such option `jpeg:sampling-factor' @ error/convert.c/ConvertImageCommand/1144.

BugBear