Re: [GD-DEVEL] Color bug in JPEG output with 2.0.36

hi Ethan,

On Sun, Mar 30, 2008 at 7:50 PM, Ethan A Merritt
<[email protected]> wrote:
> On Sunday 30 March 2008 08:50, Pierre Joye wrote:
>  > On Sun, Mar 30, 2008 at 11:48 AM, Pierre Joye <[email protected]> wrote:
>  > > Hi Ethan!
>  > >
>
> > I figured out the source of the "brown" red and posted the explanation in:
>  >
>  > http://sourceforge.net/tracker/index.php?func=detail&aid=1929002&group_id=2055&atid=102055
>
>  Right.  However there is still a bit of a mystery.
>  The following set of commands demonstrates that the quality setting of the
>  jpeg compression is critical:
>
>   echo "set term png; test" | gnuplot > test.png
>   convert -quality 88 test.png test88.jpeg
>   convert -quality 90 test.png test90.jpeg
>
>  The first conversion shows the red->muddy brown artifact.
>  The second does not.
>
>  However, the gnuplot gd.trm already sets the jpeg quality setting to 90,
>  yet the color artifact still occurs.  Is there a difference between what
>  ImageMagick thinks is "quality 90" and what libgd thinks?

As I was supposing, the quality can be improved (by supresing the ant
ialiasing created by the downsampling sampling) using a custom
sampling or no sampling at all. The attached image don't use any
(4:4:4) and looks nearly like a lossless compressed image. A simple
patch to test this feature is available here:

http://bugs.libgd.org/?do=details&task_id=156 (take the 2nd patch).

I think that iss the source of the mystery.

About imagemagick's convert, it uses no sampling when the quality is
larger or equal to 90 (max. is 100):

      if (image->quality >= 90)
        for (i=0; i < MAX_COMPONENTS; i++)
        {
          jpeg_info.comp_info[i].h_samp_factor=1;
          jpeg_info.comp_info[i].v_samp_factor=1;
        }

Where MAX_COMPONENTS is three in this case.

I hope it helps to provide better answers to your users (it helps me at least :)

Cheers,
-- 
Pierre
http://blog.thepimp.net | http://www.libgd.org