Convert will affect number of channel when image is simple

[clhsieh]

When I use convert or mogrify to modify some simple image like black, white or little object with large transparent area.
It will change its format, both windows explorer or OpenCV can read only one channel.
It seems like a good compress way to save space, but it will let program after it blow up.

[snibgo]

Some more information would help.

Can you supply an image that shows this problem, and the exact command you used, and the output file?

[clhsieh]

This is my test image and result
http://www.mediafire.com/?2qz74kq2aq95ti2
How I generate image using opencv:

Code: Select all

Mat black(858, 2048, CV_16UC3, Scalar(0, 0, 0));
imwrite("black.png", black);

How I convert image

Code: Select all

convert black.png black_.dpx
convert black_.dpx black_.png

Windows explorer shows black.png is 48bit and black_.png is 1bit
And OpenCV will get wrong format

Code: Select all

Mat image = imread("black_.png", -1);
cout<<image.cols<<"x"<<image.rows<<endl;
cout<<image.channels()<<endl;
cout<<image.depth()<<" "<<CV_8U<<" "<<CV_16U<<endl;

Will output

Code: Select all

2048x858
1
0 0 2

Shows it get a one channel 8bit image and is totally not what I want.
I use OpenCV 2.4.3 and ImageMagick 6.8.1-10, both the latest stable version on Ubuntu 12.04.

[clhsieh]

Either the identify result is not the same.
identify black.png
black.png PNG 2048x858 2048x858+0+0 16-bit sRGB 10.3KB 0.000u 0:00.000
identify black_.png
black_.png PNG 2048x858 2048x858+0+0 8-bit RGB 2c 1.78KB 0.000u 0:00.000
identify black_.dpx
black_.dpx DPX 2048x858 2048x858+0+0 16-bit RGB 10.55MB 0.000u 0:00.000

[clhsieh]

viewtopic.php?f=3&t=20431
I think this thread denote same bug
When the image is 8-bit this can be solve by PNG32, but there are no PNG64 or PNG48 for 16-bit image.
I think the correct way is not to change the format or add a option to keep it not over compress.

[fmw42]

try

convert black.png PNG24:black2.png

does that keep the file the way you want it?

[snibgo]

Black.png has three channels of 1 bit each, indexing into a 16-bit-per-channel palette. As all the pixels are black, IM convert usually tries to optimize for size. It's still a valid PNG file, as far as I can see. However, ...

Code: Select all

"%IMG680%convert" b2.dpx -define png:bit-depth=16 b2.png

... will force a 16-bit palette, just like the source.

[clhsieh]

It is 3 channel right, but it becomes 8-bit and I want keep it 16bit and there are no PNG48 or PNG64 like I mention above.
And this method only works when I know what I exactly want, but at most time I just want it keep the same with original image.
The source is 3 channel 16-bit, I can get 3 channel 16-bit.
The source is 4 channel 16-bit, I can get 4 channel 16-bit.
The source is 3 channel 10-bit, I can get 3 channel 16-bit cause png doesn't support 10-bit but use 16-bit can prevent data loss.
The source is 4 channel 10-bit, I can get 4 channel 16-bit cause png doesn't support 10-bit but use 16-bit can prevent data loss.
The source is 3 channel 8-bit, I can get 3 channel 8-bit.
The source is 4 channel 8-bit, I can get 4 channel 8-bit.
And use only convert command or add a simple option but not case sensitive, just keep it like origin.

[clhsieh]

Yes, I know I can force it to any what I want (in most case).
But I just want it same as origin.

[glennrp]

The simplest solution for you is probably to always write 16-bit RGBA.

convert in.png -define png:big-depth=16 -define png:color-type=6 out.png

Sometimes the output will be much larger in filesize than the input,
but your broken application should be able to read it.

[glennrp]

The simplest solution for you is probably to always write 16-bit RGBA.

Beginning with ImageMagick-6.8.2-0 (SVN revision 10809), the PNG48 and PNG64 output sub-formats
will be available, for writing 16-bit RGB and 16-bit RGBA, respectively. I plan to implement PNG00
as well, which will mean to inherit the color-type and bit-depth from the input PNG image.

[clhsieh]

The simplest solution for you is probably to always write 16-bit RGBA.

Beginning with ImageMagick-6.8.2-0 (SVN revision 10809), the PNG48 and PNG64 output sub-formats
will be available, for writing 16-bit RGB and 16-bit RGBA, respectively. I plan to implement PNG00
as well, which will mean to inherit the color-type and bit-depth from the input PNG image.

Thanks, I think PNG00 is really what I need, is this only works when input is png?

[glennrp]

The simplest solution for you is probably to always write 16-bit RGBA.

Beginning with ImageMagick-6.8.2-0 (SVN revision 10809), the PNG48 and PNG64 output sub-formats
will be available, for writing 16-bit RGB and 16-bit RGBA, respectively. I plan to implement PNG00
as well, which will mean to inherit the color-type and bit-depth from the input PNG image.

Thanks, I think PNG00 is really what I need, is this only works when input is png?

Correct. The decoder and the encoder have to cooperate for PNG00 to work. Other decoders
don't store a color-type. Most store a depth, normally 8 or 16, which the PNG encoder will
recognize. Please note that if you rescale an 8-bit image, that operation might create
16-bit pixels due to interpolation of colors, which increases the depth to 16. Using the
-depth 8 option will prevent (or undo) that. The PNG color-type is meaningless to other
decoders, so they can't store an input color-type.

The PNG00 "format" is also available as of ImageMagick-6.8.2-0.