[Closed] convert BMP 32bits to PNG fails

[luc]

I'm trying to convert BMP 32bits to PNG and I get an Error:
convert.exe: fixed point overflow in cHRM Blue Y `D:\Data2\00_003108.prt.BackView.bmp.png' @ error/png.c/MagickPNGErrorHandler/1751.

What can i do? Any workaround without losing quality?

Thanks

[fmw42]

Post a link to your BMP so the IM developers and others can test with it or see if it is corrupt. Also please identify your version of IM and your platform

[glennrp]

Post a link to your BMP so the IM developers and others can test with it or see if it is corrupt. Also please identify your version of IM and your platform

Also it would be helpful to know what version of libpng you are using. Type "convert -list format" and look at the "PNG" information to find out.

Also, you can try "convert.exe -define png:exclude-chunk=cHRM file.bmp file.png" to work around the problem.

[luc]

I'm working on Windows 7 64bits

PNG* rw- Portable Network Graphics (libpng 1.5.11)
Version: ImageMagick 6.7.8-0 2012-06-28 Q16
Features: OpenMP

I've also tried:
PNG* rw- Portable Network Graphics (libpng 1.5.13)
Version: ImageMagick 6.8.0-5 2012-11-03 Q16

The file can be downloaded at:
http://dl.free.fr/getfile.pl?file=/eU0xBZMf

Thanks

[glennrp]

I found 57-110452_b.prt.LeftView.rar at the download site
(not "BackView). I unpacked it and saw the same warning about cHRM that
you saw.

"identify -verbose *.bmp" shows this:
Chromaticity:
red primary: (6.87195e+08,3.54335e+08)
green primary: (3.22123e+08,6.44245e+08)
blue primary: (1.61061e+08,6.44245e+07)
white point: (0.3127,0.329)

Those numbers are obviously incorrect; they should be between 0 and 1.
The "-define png:exclude-chunk=cHRM" that I suggested works for me with
this file.

[luc]

Thanks for the information. I know what to check now and how to overide my problem.

[glennrp]

There is a bug in the BMP decoder that reads the chromaticity data incorrectly I have a fix which I'll check in shortly. With the fix, your image will be found to have all "x" and "y" values zero and libpng will not try to write a cHRM chunk. Your image has small nonzero "z" values which mess up the normalization step in the bmp decoder, making the zero "x" and "y" become large numbers. It's a very old bug going back at least to IM-5.5.7, but only recent libpng-1.5.x versions notice it.

[luc]

Thanks!