Legacy ImageMagick Discussions Archive

I'm not sure what effect, if any, the -format option has on 'convert'. Try
convert wallpaper.png BMP3:wallpaper.bmp

It's not a bug. The algorithm used does not retain the hidden colors, and there's no (easy) way to change it to do so.

Here's a 24-bit BMP image that contains a (suggested) palette: rgb24pal.bmp Test case: convert rgb24pal.bmp test.png (tested with version 6.8.0-5) Expected result: A colorful image. Actual result: An all-black image. Not all such images fail. It depends on the bit depth, and the palette size. Here's...

Version 6.8.0-4 supports the transparency in the these BMP images: rgba16-4444.bmp rgba32.bmp , but 6.8.0-5 does not. Here's what changed in the code: 6.8.0-4:coders/bmp.c:846 image->matte=(bmp_info.alpha_mask != 0) || ((bmp_info.compression == BI_RGB) && (bmp_info.bits_per_pixel == 32)) ? M...

KinectSnapshot-04-47-09.bmp technically does not have an alpha channel. Its Type is identified incorrectly. http://msdn.microsoft.com/en-us/library/dd183376%28v=vs.85%29.aspx says "The value for blue is in the least significant 8 bits, followed by 8 bits each for green and red. The high byte in...

glennrp wrote:"convert rose: -matte rose.bmp" creates a transparent image, when viewed by another app.

I'm not seeing this problem. With IM 6.8.0-4, I get an image that uses 0xff as the transparency/opacity value. As far as I know, that's correct (opaque).

The image is valid, and not transparent. As a workaround, try convert image.bmp -alpha off image.png I think IM just assumes that all 32-bit BMP images use transparency. That's not right -- if anything, it should assume that they don't. Some BMP viewers try to guess, based on the contents of the ima...

I guess that ImageMagick reads the image, converts it from sRGB (or a similar colorspace) to linear color, and writes it out as linear color, but (mis)labels it as sRGB. And it does this because the (paletted) image's pixels all happen to be shades of gray. The immediate problem is that the output i...

I reviewed the Exif spec with respect to JPEG files, and it confirms that there can be no more than two IFDs in the primary IFD list, and the second one is only used for a thumbnail. So maybe there's never any reason to look at the "next IFD" pointers at all. If so, this could easily be fi...

The TIFF file is malformed. It has a bad pointer to Exif metadata.
It claims the Exif data starts at byte 90950736, but the file is only 550406 bytes in size.

Possible test case here. I found an image whose thumbnail contains an orientation tag, and modified the tag (but not the thumbnail image) to be top-right. I agree that it looks like a bug, and it's probably not limited to the orientation.

The Windows ZIP file (ImageMagick-6.7.9-3-Q16-windows.zip) contains two imdisplay.exe files that differ only by the case of the filename. Windows filesystems don't allow that. 8314368 Defl:X 3607926 57% 09-01-12 19:01 ff947ef0 ImageMagick-6.7.9-3/IMDisplay.exe 5592064 Defl:X 2306624 59% 06-22-12 21:...

Right; the YCbCr conversion is sometimes considered to be a part of the data compression process, as opposed to being an actual colorspace. A deficiency in the JPEG file format is that there is no standard way to indicate what color format an image uses. The JFIF subformat provides a standard way to...

Most JPEG files do not have enough precision to store all possible 24-bit RGB colors in this way. The main issue here is that color JPEGs usually use the YCbCr colorspace, not RGB, and some information is lost in the translation. One solution would be to use higher precision (12 bits per sample inst...

A BMP palette can start at byte 0x1a, 0x36, 0x42, 0x7a, or 0x8a. When I create a BMP file with 'convert', I usually see ASCII "BGRs" at offset 0x46, and the palette starts at offset 0x8a. If you get a different result, or believe that that is invalid (as opposed to just unusual), then we p...