Inconsistent behavior for -type, -depth and -colors

[mikro]

Hi,

I needed a simple thing, to rotate and write some png file in 1-bit depth, it didn't matter what format (gif, png, you name it). As it turned out, it's quite a problem in IM. My first approach was (<input> is 1-bit colormap PNG if it matters):

Code: Select all

convert <input> -type Palette -depth 1 output.png

as PNG nicely support palette-based format. No luck, stored as 8-bit. Second try:

Code: Select all

convert <input> -type Palette -depth 1 output.gif

and

Code: Select all

convert <input> -type Palette -depth 1 output.bmp

Still 8-bit. Desperate try:

Code: Select all

convert <input> -type GrayScale -depth 1 output.png

Success! After some tests it seems PNG can be stored only as GrayScale when one wants 1-bit depth. Why? Palette-based format is perfectly valid => BUG here!

Another strange behavior:

Code: Select all

convert <input> -type Palette -depth 1 output.bmp

stores 8-bit as I write above. But

Code: Select all

convert <input> -type Palette -depth 1 -colors 2 output.bmp

stores 1-bit! Not only it's strange, it's also confusing! Aren't colors and depth redundant parameters? This "trick" seems to work for GIF, too but unfortunately, not for PNG

My version of IM is 6.6.4-10 2010-10-10 Q16 ...

I'd love to see I did something wrong... I tried also +antialias and +dither but no luck either.

[fmw42]

try using gif as it supports bi-level (not sure PNG does)

convert input -monochrome -type bilevel result.gif

or

convert input -colorspace gray +dither -colors 2 -type bilevel result.gif

[mikro]

Well, my point isn't to get it working by some workaround. I did this with using .bmp + -colors 2. I'd like to know why PNG doesn't work, i.e. if it's bug or some unclear documentation issue.

[fmw42]

see http://www.imagemagick.org/Usage/formats/#png_formats and http://www.imagemagick.org/Usage/formats/#png_write

[mikro]

ehm, yeah, right... this is exactly what doesn't work, that's the point i'm talking about here.

EDIT: ah, ok, I overlooked the notes. So it seems it's disabled for palette modes as a "feature"...

[fmw42]

you can always post an enhancement request to the Developers forum - but no guarantee how quickly that might happen

[mikro]

OK, I see I messed things here. Basically, your links confirm expected behavior, i.e. indexed palette mode should support 1, 2, 4 and 8 color bit depth. However, when I do the most simple thing:

Code: Select all

convert input.png -define png:bit-depth=1 -define png:color-type=3 output.png

it gives me (even with input.png being 1-bit colormap!) :

convert: Cannot write image with defined PNG:bit-depth or PNG:color-type.

Funny things is when I type:

Code: Select all

convert input.png output.png

the result is 1-bit (correct) grayscale (incorrect!!!). To me it seems like there's hardcoded implication 1-bit => grayscale, totally forgetting palette-based mode.

Dear developers, there are three bugs:

1. Error in documentation

-define png:bit-depth {depth}

(should be png:bit-depth={depth})

2. Unclear relationship with -colors and -depth / png:bit-depth (documentation states under which condition png:bit-depth overrides -depth, fair enough, but no word about when one should (not) use -colors)

3. Actual bug in IM, command about must work or documentation is wrong.