Legacy ImageMagick Discussions Archive

If following this thread: see resolution in 'bugs' folder : http://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=26262 Why have applied a patch that will use FILLORDER_MSB2LSB unless specified otherwise with the 'tiff:fill-order' setting. Thank you for reporting this. The fix will be ...

Thanks very much , I look forward to trying that soon. I also can't quite understand the behaviour of the 'endian' flag, after figuring out that it's the fill-order that is causing trouble I found that if I inculde jsut the +endian flag, it saves in order '1' instead of '2', however this flag is ...

The new version has 'fill order' set to '2' whereas the old version has 'fill order' set to '1' 'Fill order 2' is not supported universally and is not required to be supported by baseline TIFF standard. As my command did not specify any special fill order, there are two possible expected behaviours ...

The new version has 'fill order' set to '2' whereas the old version has 'fill order' set to '1' 'Fill order 2' is not supported universally and is not required to be supported by baseline TIFF standard. As my command did not specify any special fill order, there are two possible expected behaviours ...

You could download Imagej for free

There doesn't seem to be date-specific data causing diff's because the same command shows no diff between the prior result of mine and the result of the command as you suggested without the leading define-quantum-floating business, executed on a different day. I have started deeper investigation of ...

snibgo wrote:from32f_out.tiff:
https://dl-web.dropbox.com/get/from32f_ ... SvULA&dl=1

I can't (don't know how?) to access this file. I have logged into drobpox and I still get "no permission, you have to log in" message

why are we talking about 8bit values?

with quoteDifferent behaviour between installation versions HI, I have a command that was working to give the correct ressult, I have compiled the current version of ImageMagick and now it gives a wrong result. The command converts a 32-bit floating point TIFF in which the values lie in the range 0 ...

They are not identical. $ diff image_from_version_6.7.5.10.tif image_from_version_6.8.9.7.tif Binary files image_from_version_6.7.5.10.tif and image_from_version_6.8.9.7.tif differ Because you are using ImageMagick to compare the values that ImageMagick reads in the images, you are getting the same ...

Snibgo said:, So we need to divide by 4365/0.0666056 = 65536 (more or less). That is what I said in the first place before the discussion about the handling of quantization. Here is the command: convert -define quantum:format=floating-point projections/p_00000.tif -evaluate divide 65536.0 -define ...

But when I examine input_image.tif: %IM32f%identify -verbose input_image.tif I get: Channel statistics: Gray: min: 0 (0) max: 1.87475e+13 (4365) mean: 3.77842e+12 (879.731) standard deviation: 2.69001e+12 (626.316) kurtosis: -1.1503 The mean value is about 3 million million, which is substantially ...

okay .. but it's ImageMagick that is telling you this? I placed a screenshot of ImageJ opening that same file displaying the value at a test point of 2017.0 as expected (in the same FTP folder) Why did I get the desired output in version 6.7.5-10 ? This is the burning question. If the image is ...

The results of the command originally mentioned: convert -define quantum:format=floating-point input_image.tif -evaluate divide 65536.0 -define quantum:format=integer -depth 16 image_from_version_6.7.5.10.tif and the same command using version 6.8.9.7 ; along with the input image, are on the ftp ...

That command results in an image with value 65535 everywhere.