Poor maximum JPEG quality.

[libgd]

Poor maximum JPEG quality.

[imazen-bot]

Hurts me too - I'd have expected no artefacts at quality 100.

BTW, is there some "uncompressed" saving of JPEGs? I'd need them only as mjpeg stream for ffmpeg, any saved CPU load would be welcome.

---

Originally posted by phmarek (phmarek) on May 28 2012 via Bitbucket

[imazen-bot]

afair jpeg8 and later offers lossless compression.

I did not test yet if the 100 quality goes lossless or if we need an extra option.

---

Originally posted by pierrejoye (Pierre Joye) on Apr 16 2013 via Bitbucket

[imazen-bot]

The demo page ( http://oserv.org/bugs/gd/ ) now works again, I re-uploaded it.
Please take a look.

---

Originally posted by ChALkeR (ChALkeR) on Aug 05 2013 via Bitbucket

[ChALkeR]

Hi here =). I am the original issue reporter.

[ChALkeR]

The issue is still valid as of libgd 2.1.1.

[vapier]

if you could attach a small testcase, it would help

[ChALkeR]

@vapier
Testcase:

<?php
$image = imagecreatefrompng('test1.png');
header('Content-Type: image/jpeg');
imagejpeg($image, null, 100);

test1.png: http://oserv.org/bugs/gd/test1.png or http://oserv.org/bugs/gd/test.png

[pierrejoye]

I am not sure what we can change here without providing full tables customization. We simply pass the value to jpeg_set_quality.

And you are right too, current jpeg support does not provide lossless write support.

Which command line or code did you use for imagick? Imagemagick does a lot of magics depending on the arguments :)

[ChALkeR]

@pierrejoye

convert test1.png default.jpg
convert test1.png -quality 100 100.jpg
convert test1.png -quality 90 90.jpg

Any of those are better than gd with quality 100.

[ChALkeR]

On -quality 89 imagemagick starts too look like libgd with quality 100.

[vapier]

comparing the convert -debug all -vvv logs, the difference seems to be:

-  Sampling factors: 1x1,1x1,1x1  # -quality 100
+  Sampling factors: 2x2,1x1,1x1  # -quality 89

and when i make a similar change to gd_jpeg.c, the quality improves:

     jpeg_set_defaults(&cinfo);
+    cinfo.comp_info[0].h_samp_factor = 1;
+    cinfo.comp_info[0].v_samp_factor = 1;

guess we should use the algos in imagemagick's jpeg.c to figure out what samp factors to use ?

[pierrejoye]

The 1st one (q=100) could be done easily but may drastically increase the file size by default as you can see with the images in this report.

This special case is also very particular as it uses anti-aliasing text patterns which per se are impossible hard to compress nicely from a visual point of view.

The default sampling factor in recent libjpeg (turbo) targets photographies more than text or patterns. PNG fits better for that.

One thing I like to add for 2.3 is to expose the parameters for Codecs like jpeg or PNG. Can be handy.

[vapier]

i think a good trade off is to set the scale factor to 1x1 when quality is >= 90, otherwise let jpeg do its default (2x2).

i agree that exposing the lower API makes sense. let's split that into a new issue though ?

[pierrejoye]

--- a/src/gd_jpeg.c
+++ b/src/gd_jpeg.c
@@ -307,6 +307,10 @@

        if(quality >= 0) {
                jpeg_set_quality(&cinfo, quality, TRUE);
+               if (quality >= 90) {
+                       cinfo.comp_info[0].h_samp_factor = 1;
+                       cinfo.comp_info[0].v_samp_factor = 1;
+               }
        }

        /* If user requests interlace, translate that to progressive JPEG */

should do it.

I will apply + test tomorrow.

[vapier]

lgtm!

[vapier]

our 4th oldest issue closed out! :D

[pierrejoye]

:)

Also fixed the test to get the actual diff.

I will also try to add a better perceptual diff for the tests suite. The current is rather useless without threshold for these cases.

[ChALkeR]

Thanks!

[pierrejoye]

@vapier Thanks for fixing the makefile :)

And as reference for future readers or doc about sampling http://www.impulseadventure.com/photo/chroma-subsampling.html