Legacy ImageMagick Discussions Archive

There seems to be at least one ImageMagick bug here. Its clipboard handler manufactures a BMP file header, but in that header it doesn't always set the bfOffBits field correctly. I'm referring to this line in coders/clipboard.c: offset=((unsigned int) p[0])+BMP_HEADER_SIZE; It ought to also add the ...

I think it's bug-like enough to move there. The issue I'm talking about is that some of the 1-bit PCX files created by IM are not as portable as they could be. I believe the cause is the combination of the PaletteType field set to 1, and a white-then-black palette (FF FF FF 00 00 00) at offset 0x10 ...

I'm not sure I understand your question. But I see that, in some cases, depending on the JPEG, IM (7.0.8) will write a 1-bit PCX file that has [ff ff ff 00 00 00] in the palette area at offset 0x10. And that seems... bad. To the best of my knowledge, there is no portable way for a 1-bit PCX to be ...

Your rslt.bmp file looks okay in the viewers and web browsers I tried, and is correct based on what I know about BMP format. But it is an uncommon type of BMP, not supported by everything. I guess you are using a viewer that does not support the combination of a BMPv5 header (which ImageMagick calls ...

Your file is a PICT file by all rights, though it's being used as a thin wrapper around a Photo CD (PCD) file. Probably, everything you care about is in the PCD part. It should be safe to delete the correct number of bytes (1202 in this case) from the beginning of the file, and use it as a PCD file ...

Yeah, your command results in what we're supposing is the smallest uncompressed file size. But it uses a fixed grayscale palette, which is unnecessarily restrictive (though it might not make a huge difference in this case). I don't know much about tuning IM's color quantization. Before long I'd ...

BMP's RLE8 (for 256-color images) and RLE4 (for 16-color images) compression schemes are not too exotic, though I have no way to guess whether your software supports them. And unfortunately, ImageMagick (as of this writing) doesn't encode RLE8 optimally, and AFAIK doesn't encode RLE4 at all ...

BMP does not have a grayscale image type. boot.bmp is an 8-bits/pixel RLE-compressed color paletted image, which (I guess) ImageMagick pretends is grayscale, since all its colors are gray. Note the Class is "PseudoClass", which is IM's term for paletted. boot-backup.bmp is a 24-bits/pixel ...

To clarify my libtiff comment, I mean that libtiff does not have an option to compile in JPEG2000 compression support. An app like ImageMagick could presumably implement its own JPEG2000 codec, and register it with libtiff at runtime. But the current version of IM does not appear to ever do that.

I don't think that libtiff directly supports JPEG2000 compression. Can you point me to a sample file, or some format documentation? I'd guess that a single-strip TIFF/JPEG2000 image like yours simply contains an embedded "JPEG 2000 codestream". If so, it should have the byte pattern 0xFF 0x4F 0xFF ...

(For recent discussion of these options, see https://www.imagemagick.org/discourse-server/viewtopic.php?f=1&t=33334 , https://www.imagemagick.org/discourse-server/viewtopic.php?f=2&t=33344 .) Right. I didn't make it clear, but these option are implemented as hints . They'll be ignored if, for ...

Sorry, but I don't think I want to try to make a pull request for this. Even just figuring out the minimal changes to fix the bug would take some time. As for refactoring the whole thing to use CF_DIB, one issue is that ideally I'd want clipboard.c and bmp.c to share a lot of code, and I don't even ...

I can reproduce this, and it seems like a bug to me. A process should be able to read the same clipboard data multiple times. Looking at the source code, this looks suspicious: coders/clipboard.c: OpenClipboard(NULL); bitmapH=(HBITMAP) GetClipboardData(CF_BITMAP); hPal=(HPALETTE) GetClipboardData(CF ...

I haven't looked at this closely, but I confirm that the ARGB1555 option seems to write a 24bpp image if the image has no transparency (and more than 256 colors). If the image has transparency, then it writes a 16bpp image as expected. Looks like a bug to me.

I could not figure out how to download mch's example file with a web browser. What I ended up with was always either a JPEG or HTML file. I was able to download it with wget. It is BMPv3 16-bit RGB555, not RGB565. BMPv3 supports 16-bit images with arbitrary RGB (though not RGBA) color formats. You ...