Legacy ImageMagick Discussions Archive

I'm dealing with some Phase One .IIQ RAW images. It looks like ImageMagick doesn't yet support these, but like most RAW images, they smell like TIFFs and get processed as such, although IM uses the preview image embedded in the file rather than the full image. If I force ImageMagick to treat it as a ...

For some real-world images (usually TIFFs or TIFF-like images, e.g. NEF), we find that there are multiple images in the format, e.g. a preview thumbnail as well as the main image. For our image processing we iterate through them using MagickGetNumberImages() and MagickSetIndex() looking for the ...

For those of you using ImageMagick programatically:

Looks like this topic covers the same issue exactly:

viewtopic.php?f=1&t=15572

Thanks. Does -alpha off only affect unassociated alpha, or all alpha? I.e. can I use it as a default for all images I process. Otherwise, is there a way I can detect unassociated alpha programatically? Is there a reason why converting to JPEG behaves differently to scaling and then converting to ...

I have a problematic TIFF which a) does not display correctly in imdisplay.exe - the dimensions of the image are correct, but only a thin strip of the image is rendered on a transparent background b) converts to JPEG correctly at full size - the output is the whole image c) does not convert to JPEG ...

Thanks for your input guys.

I've removed the TIFF for the moment, but left the other output referenced in this thread. If any developers want to pursue the fault, give me a shout, I can re-supply the TIFF.

Apologies for -geometry. (I'm not really an IM command line user, I program using the IM APIs, and when things go wrong, I try to find the command line equivalents to see whether convert behaves as expected and it's my use of the API that's wrong.) FWIW I've verified that -geometry 300x300 and ...

The previous identify output was indeed from an old ImageMagick as you suspected (6.2.8 from CentOS 5.10). Below is the output from 6.8.9-2, which reverses the Alpha min/max. Although the post subject references PNG, that's mainly because converting to PNG was the easiest way to reproduce the fault ...

I'm using ImageMagick 6.8.9-2 (which exhibits the same behaviour as 6.7.7-7, the oldest version I tested), built from source on Linux. The problem was reported in a system that uses 6.7.1 on Windows (installed using the official installer, i.e., it's probably nothing to do with how I'm building from ...

Sadly MagickSetColorspace() doesn't appear to have any effect, at least not with the versions of ImageMagick I've been working with (6.7.7-7 is the one we're currently working with). No matter what I set the colourspace to, after reading the image with MagickReadImage() I seem to have a CMYK image ...

Ah no I was mistaken; it's left me with a CMYK JPEG which looks correct but isn't what I'm after.

Thanks, that appears to have done the trick. The following code now produces a much better image: defconst MAGICK_RGBColorspace = 1 def main () { local infile = info("argv 1") local outfile = info("argv 2") local w = NewMagickWand() MagickSetImageColorspace(w, MAGICK_RGBColorspace) MagickReadImage(w ...

My question relates to EPS colorspace conversions, but ultimately it's really about how to change the format of an image in memory. I'm using IM 6.7.5-4 (with later versions we have issues with dark JPEGs which we've not yet got to the bottom of). I have a CMYK EPS file which I convert to RGB JPEG ...

In ImageMagick 6.7.9-4, there are several code paths in SetImageAlphaChannel (magick/channel.c) that will always return MagickFalse. The 'status' variable that is ultimately returned is initialised to MagickFalse, but the switch cases for ActivateAlphaChannel and DeactivateAlphaChannel (for example ...