Page 1 of 1
bizarre drop in quality on no-op convert on small JPEG
Posted: 2012-09-24T08:20:21-07:00
by 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
Re: bizarre drop in quality on no-op convert on small JPEG
Posted: 2012-09-24T10:25:29-07:00
by 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.
Re: bizarre drop in quality on no-op convert on small JPEG
Posted: 2012-11-09T07:37:58-07:00
by bugbear
fmw42 wrote: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
Re: bizarre drop in quality on no-op convert on small JPEG
Posted: 2012-11-09T08:31:26-07:00
by 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
Re: bizarre drop in quality on no-op convert on small JPEG
Posted: 2012-11-12T10:17:29-07:00
by bugbear
glennrp wrote: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
Re: bizarre drop in quality on no-op convert on small JPEG
Posted: 2012-11-12T12:20:25-07:00
by 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.
Re: bizarre drop in quality on no-op convert on small JPEG
Posted: 2012-11-12T12:42:47-07:00
by 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.
Re: bizarre drop in quality on no-op convert on small JPEG
Posted: 2012-12-18T10:34:34-07:00
by 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
Re: bizarre drop in quality on no-op convert on small JPEG
Posted: 2012-12-18T11:09:05-07:00
by 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.
Re: bizarre drop in quality on no-op convert on small JPEG
Posted: 2012-12-19T02:59:08-07:00
by bugbear
snibgo wrote: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
Re: bizarre drop in quality on no-op convert on small JPEG
Posted: 2012-12-19T03:23:16-07:00
by 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
Re: bizarre drop in quality on no-op convert on small JPEG
Posted: 2012-12-19T03:47:12-07:00
by 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
Re: bizarre drop in quality on no-op convert on small JPEG
Posted: 2012-12-19T07:19:15-07:00
by 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.
Re: bizarre drop in quality on no-op convert on small JPEG
Posted: 2012-12-19T08:24:27-07:00
by bugbear
glennrp wrote: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
