It seems to work okay with the default BMP version, but I think there's a bug that prevents it from working properly with BMPv3 ("BMP3:" or "-define bmp:format=bmp3").
As of v7.0.7-11, the pattern "static char *...[] = {" is hardcoded, and cannot be changed. The "..." is the "base output filename", and I don't see any way to set it independently. There must be many ways to automate the editing that you say you're doing manually. In a ...
One troublesome aspect was that the ImageMagick "Exif" property can contain the JPEG thumbnail image, which isn't strictly a part of Exif. I'm confused. A JPEG thumbnail image is definitely a standard part of Exif. Is there something special about the 'ImageMagick "Exif" propert...
I think it's the dither operation that's very slow when I create certain images with one very large dimension. The time it takes seems to be exponential (correction: quadratic) based on image's larger dimension, and jumps way up at each power of 2(?). Maybe there is a legitimate reason for this, but...
Other than the warning message, I see nothing in the "identify -verbose" output that tells you this. It says "Compression: JPEG" either way. Outside of ImageMagick, you could use tiffinfo from libtiff ("Old-style JPEG" vs. "JPEG"), ExifTool ("JPEG (old-st...
The test_q10.jp2 and test_jp2_q10.jp2 files from your dropbox link are not JPEG2000 files. They are regular JPEG files with an incorrect extension. I tried your commands (with a newer version of ImageMagick) and correctly got JPEG2000 files. However, a quality of 10 seems to be too low to get much m...
BMP is limited to around 10 bits per channel (and more than 8 is rarely supported), so if you really want 32, you can't use BMP format. Assuming you want 32 bits per pixel : Most full-color BMP images have 24 bits per pixel, not 32. A 32-bit BMP could mean (1) there are 8 unused bits per pixel, or (...
The tag we're talking about is 40092 (XPComment), not 59932 (PADDING_DATA). As far as I can tell, 40092 is not supported by IM. It does appear in the EXIFTOOL output above. Support for the tags 40091 through 40095 (and maybe some of 18246 through 18249) might be a nice feature, given that they are c...
The image has 3 "extra samples" per pixel, all of which are labeled as containing "unspecified" data (i.e. not necessarily alpha samples). As far as I can tell, if a TIFF image has one or more extra samples, ImageMagick 6.x always guesses that one of them (I'm not sure which one)...
convert requires an output file, even with the -identify option. If you don't want that, try convert.exe 獅藝學會.jpg info: or identify.exe 獅藝學會.jpg ImageMagick on Windows can handle Unicode filenames on the command line. However, it does not correctly print Unicode to the console, so the filenames are ...
Steps to reproduce, in 6.9.3-4 (-resize and -annotate are not necessary): convert NRM_Map.tga -resize 200x -annotate +20+20 "TGA" temp.tga convert temp.tga temp.png temp.tga and temp.png are flipped. It happens if the input and output formats are both TGA, and the input image has top-down ...
As far as I can tell, there is no such feature, as of ImageMagick 6.9.2-0. IM only ever sets the descriptor/attributes byte to 0, 1, or 8; so bits 5 and 4 are always 0, and the orientation is always bottom-left. (You said bottom-left is 01, but I'm pretty sure it's 00.)
It looks like a bug to me (tested with v6.9.0-2). The Exif thumbnail image has an Orientation tag, and I'm guessing that the -auto-orient routine wrongly thinks that tag applies to the main image.