Legacy ImageMagick Discussions Archive

...What don't you like about the gray color-type? Does it cause problems? Yes. When stitching together many tiles into the same final image, with some tiles being all black, IM seems to key off of the first tile in the append operation to determine what the output image will be. If the first tile ...

Groan...this has to be done per-format? Seriously, why is this not the default?

I don't want to have to specify the color type, then. I just want IM to carry it through from source to output.

I'm working more with IM and trying to get it to crop output files from render applications prior to appending them together. In this example, the render application is outputting an RGBA PNG with 8 bits per channel. Some tiles are all black, but others contain non-black color and alpha data in some ...

fmw42 wrote:Just saying to use IM 7 to get a Q16 HDRI install.

Tried that, throws the same error message.

snibgo wrote:As I said earlier:

Can you upload a problem tiff and paste the link here?

Yep, give this a shot:

www.kostov.com/IM/32biterror.tif

So, are you trying to say that I have to specify additional command line switches when I run identify? Doesn't that negate the primary purpose of running identify at all?

Ahh...nothing more than a bunch of older Q8 and Q16 stuff there.

That's not an option for me, since I'd have to have Cygwin installed and running everywhere I want to run the binary. Anyone know if there are third-party compiled binaries somewhere?

There is a Q32 or Q64??? I don't see any compiled Windows binary listed higher than Q16 on the download page. Does that mean I'd have to compile my own? (Ick)

I'm trying to work with some TIFF output images from some newer render apps, and I'm having a bit of trouble. When attempting to run a simple identify -verbose someimage.tif, I get this output at the end: identify.exe: Sorry, can not handle images with 32-bit samples. `c:\Users\joe\Desktop\someimage ...

Yea! That works as expected. I'm not so sure the default of that should be "over", but I'm happy to have that solved. Too bad it took so long to find. :^)

Convert doesn't have the same issue as montage, since I use convert to crop each output tile to only the portion of the image with information prior to using montage. I may have to resort to using convert, though, if none of the devs care about making montage work correctly.

The post on the bugs forum has gone all of nowhere so far. I would have thought it would be taken at least somewhat seriously due to it being easily reproducible with the files I provided. The nature of the flaw is objectively obvious. Anyone?

After more tests, it is clear that montage is shifting the dynamic range *of each channel independently*. If it's going to do it by default, it should at least do so equally to all channels. I still propose it shouldn't shift the dynamic range whatsoever. After all, its primary job is just to join ...

I have a thread in the users section about this that has all the details and links to sample files. In summary, montage appears to be shifting the dynamic range of 16bit EXR's when stitching the final output. The thread on the users forum is here: http://www.imagemagick.org/discourse-server ...