Legacy ImageMagick Discussions Archive

Ah, ok. So, it's the 'hash' signature. Did you try to specify a fixed TIFF output format (with the Rmagick equivalent of "-type" and "-depth")? I think, you should be able to get identical strings (at least in such a test script :)). convert signature_test.tif -black-threshold 78% -format ...

I'm still not sure what you mean with "signatures" here. As long as no other Rmagick users show up, we can't know what Rmagick saves as " image .signature". You only wrote about such return lines so far: signature_test2.tif TIFF 104x16 104x16+0+0 8-bit Bilevel DirectClass 621B But that tells almost ...

Some suggestions: Perhaps you should tell at the very start which programming language/API you're using. (Perl? Ruby? Something?) And what you do in those scripts. (Seems now that you were cropping the image in the first script. And black-/white-thresholding the image in the second script. In order ...

OK. I think I'll wait for the next IM release versions and if there are still problems with these files, I can make a new thread. (I don't use this file type much. But I have one WMF that ImageMagick can't read and most of the EMFs get a bit distorted with the old EMF reader - I think, mainly as IM ...

Thank you!

Exactly - your output is completely correct, Fred. So your version of libtiff is higher than mine and appears to be a beta. Yeah, it's higher. But as I said - the change of the output (in Windows) came between v6.7.3-6 and v6.7.3-7, and both versions appear to have the same libtiff. I don't ...

Also, I believe the emfplus tools works on all EMF formats, so it could replace the legecy delegate. That would be great! I had some problems with EMF and also WMF files in ImageMagick, and usually used the Windows Picture Viewer to decode these files. (I don't know if these are 'normal' EMF files ...

Strange. With IM v6.7.5-6 Q16 Win32, the "tiff:endian" output in "identify -verbose" is still not there. Which libtiff version are you using, Fred? Maybe it has something to do with the different libtiff versions in the Windows binaries. (Though, in both v6.7.3-6 AND v6.7.3-7, libtiff is reported ...

Regarding the Windows command line problems: There are problems with % and ^ signs not only in cmd.exe and .bat files but in process creating and starting with parameters in Delphi - there are not common rules unambigous. Some special characters (especially "^", ">", "<", also line breaks, etc ...

I know that thread. But that's a completely different problem (restricted to JPG in TIFF).

So, it was added a few hours ago?
I can't test it, as there is no 6.7.5.6 Windows binary at the moment, I think. I'll wait.
Thanks!

Did you use Mac Preview, Fred? With IM 6.7.5-5 Q16 on Windows XP, it doesn't work. It's a problem of reading CMYK JPG in TIFF. I was curious and searched the version where it changed. The bug came with v6.6.4-4, it seems. "identify -verbose" with e.g. test.tif shows: Type: ColorSeparation Base type ...

The thread was not about false settings. (The chatter in between was there as Anthony asked about the current TIFF behaviour - for a new IM Examples summary, I presume.) The OP asked whether it's possible that "identify -verbose" shows the byte order of a TIFF file. Up to version 6.7.3-6, the byte ...

However, most of the above is off-topic. :) The problem of the OP was, that "tiff:endian" (the TIFF byte order) can't get output anymore: With v6.7.3-6, this was still possible: convert -define tiff:endian=msb rose: -endian lsb tif:- | identify -verbose tif:- Endianess: LSB ... tiff:endian: msb It ...

Try ImageMagick-6.7.5-4 and let us know if you continue to have problems with tiff:fill-order. Works now. Thanks again. "-define tiff:fill-order" does now the same as "-endian" (for TIFF). And the define takes precedence over "-endian", if both options are specified. Another small difference to the ...