Page 1 of 1

Different depth in result between gif and png

Posted: 2016-04-13T22:45:49-07:00
by ddemerre
I get a different result in the bit-depth of a generated image, between gif and png target, with the same recipe.
This happens if I put two annotation of different colours.
The gif file remains 8 bit, while the png file is to 16 bit.
If I put two annotations in the same colour, both images produced (gif and png) are 8 bit.

This difference caused a transparency Issue in the program QLab 3 on Mac, where the 16bit png format
was not transparent anymore.
If I force the creation to 8bit (using -depth 8), the transparency issue in Qlab is resolved.

However the (hidden?) "upgrade" to 16 bit for png (and not for gif),... caused some confusion.

The code

Code: Select all

# result surprisingly in png of 16 bit, BUT gif of 8 bit
for e in png gif; do
    convert -size 30x30 xc:none -annotate +0+30 "A" -fill orange -annotate +4+30 "C" \
            target.${e} ;
    identify target.${e} ;
done ;
# results in output
# target.png PNG 30x30 30x30+0+0 16-bit sRGB 687B 0.000u 0:00.000
# target.gif GIF 30x30 30x30+0+0 8-bit sRGB 16c 150B 0.000u 0:00.000
When forcing to 8 bit, both files remain of the same type:

Code: Select all

# result in png of 8 bit, AND gif of 8 bit
for e in png gif; do
    convert -size 30x30 xc:none -annotate +0+30 "A" -fill orange -annotate +4+30 "C" \
            -depth 8 target.${e} ;
    identify target.${e} ;
done ;
# results in
# target.png PNG 30x30 30x30+0+0 8-bit sRGB 638B 0.000u 0:00.000
# target.gif GIF 30x30 30x30+0+0 8-bit sRGB 16c 150B 0.000u 0:00.000

So the Issue I'm reporting (indicated a possible mishap in QLab), is only concerning the "unexpected" bit depthening for png in comparison to the gif result.

I'm using
OsX 10.10.5
ImageMagick via brew upgrade:
Version: ImageMagick 6.9.3-7 Q16 x86_64 2016-03-27 http://www.imagemagick.org
greetings.

Re: Different depth in result between gif and png

Posted: 2016-04-14T04:58:16-07:00
by snibgo
You are using Q16. Thus, images are stored internally with 16 bits/channel/pixel. Images are saved according to the current "-depth" setting, but possibly also limited by the file format, eg GIF and JPG are limited to 8.

There is also optimisation: if you are saving PNG, but it only needs 8 bits/c/p, that's what will happen.

This is expected behaviour. I can't see a bug in what you describe.