MIFF format not working correctly in IM 6.4.1-3 Q16 HDRI

[fmw42]

Hi,

I just downloaded and installed IM 6.4.1.-3 Q16 HDRI on Mac OSX Tiger.

I believe that MIFF format is not preserving negative values in HDRI.

I am finding that when I test Sean Burke's IMFFT to create a mag/phase pair in MIFF format, the results are not preserving the negative values; whereas in PFM format they are fine.

The usual test image:


The fft step:

Applications/imfft/trunk14/demo f square31.png square31_fft.miff

Generates:
Mag: http://www.fmwconcepts.com/misc_tests/F ... fft-0.miff
Phase: http://www.fmwconcepts.com/misc_tests/F ... fft-1.miff

convert square31_fft-1.miff -verbose info:

Type: Grayscale
Base type: Grayscale
Endianess: Undefined
Colorspace: Gray
Depth: 32/16-bit
Channel depth:
gray: 16-bit
Channel statistics:
gray:
min: 0 (0)
max: 3.12932 (4.77503e-05)
mean: 0.604002 (9.21648e-06)
standard deviation: 0.948808 (1.44779e-05)


Note the phase should have values that range from -pi to +pi, but here they are getting clipped at zero -- negative values are not preserved.



When I do the same with PFM format results:

Applications/imfft/trunk14/demo f square31.png square31_fft.pfm

Generates:
Mag: http://www.fmwconcepts.com/misc_tests/F ... _fft-0.pfm
Phase: http://www.fmwconcepts.com/misc_tests/F ... _fft-1.pfm

convert square31_fft-1.pfm -verbose info:

Type: Grayscale
Base type: Grayscale
Endianess: Undefined
Colorspace: Gray
Depth: 32/16-bit
Channel depth:
gray: 16-bit
Channel statistics:
gray:
min: -3.12932 (-4.77504e-05)
max: 3.12932 (4.77504e-05)
mean: 1.81636e-05 (2.77158e-10)
standard deviation: 1.59061 (2.42712e-05)


Here the min and max values are properly between -pi and +pi

Would you look into this again. Thanks.

Fred

[magick]

You must set the quantum:format option to floating-point to save values that exceed the normal range of pixel values:

• convert image.miff -fx "-u" -define quantum:format=floating-point hdri.miff

From the API, you can say

• (void) SetImageOption(image_info,"quantum:format","floating-point");

before you call WriteImage().

Previously ImageMagick automatically set the floating point option but we removed this feature because it was expensive (all pixels were scanned looking for out-of-range pixel values) and because it required the image depth to be set to 32 to support floating point values when this may not be what the user wants.

[fmw42]

1) Has this been noted anywhere as having been changed recently? It comes as rather a sudden surprise for our FFT development. I am sure that you know best what you have to do for IM, but it sort of defeats the concept of HDRI (as well as I understand it) if you have to do this, in my opinion.

2) Does this apply only to miff? PFM seems to work fine without -define quantum:format=floating-point

3) Does this apply only to -fx and miff or to all other operations that save as miff in an HDRI enviroment?

I will have to notify Sean Burke regarding his IMFFT as this at the moment causes special cases depending upon whether one outputs to MIFF or PFM. Any suggestions?


Thanks.

Fred

[magick]

Keep in mind that HDRI is still experimental and subject to change. You folks are the first to exercise it.

PFM does not require the quantum:format option because by definition its floating-point where MIFF and TIFF can be unsigned integer or floating point thus the need to specify. We can restore the previous behavior but the general philosophy of ImageMagick is not to make decisions for users, but instead make options available so the user can specify their intentions. However, if you & Anthony both think that floating point should be the default behavior we will restore it in the next point release.

[fmw42]

Thanks for the reply.

I would be curious to know what drove this recent change. However that is really not terribly important to the outcome.

I think there are two issues to be resolved here. The first may not necessarily be a driving requirement for the second.

First, what to do about the IMFFT development? For some applications it is necessary to use real/imaginary components of the FFT which must preserve negative values as well as fractional values. Thus we needed to use HDRI, as we expected that was its behavior not only for the output of IMFFT but also any intermediate script processing steps. However, we can require the use of PFM as the only format now that appears to do that naturally. Correct me if that is not the case. Another option, but I don't think it resolves much, would be for Sean to add the quantum:format option to his IMFFT, so that MIFF would be a valid output that would preserve negative values. But then any script step that uses MIFF and generates MIFF would need to add -define quantum:format=floating-point. Thus I would need to make two different scripts one using it and another without (unless adding it had no affect on PFM). Nevertheless, it makes little sense to do anything special if PFM works fine.

Second, what should the IM behavior be for HDRI and MIFF? As a question, is this really a HDRI issue or a MIFF/TIFF issue? I understand your concern to make HDRI efficient and let the user decide how to employ it in the MIFF/TIFF situation. I certainly don't want to tell you what your MIFF behavior should be as that is IM's proprietary format. I guess as a point of discussion and not a recommendation at this point, I would ask does it make any sense to have two HDRI formats or perhaps better an "enable" option that would set the quantum:format option at compile time. Does that make any sense as another possible way to handle it? Thus one could not set this option and have your current HDRI compile situation where MIFF behavior would need to be set on a command-by-command basis or alternately with this new compile setting enabled one could then have MIFF or PFM preserving negative values at the expense of some speed. At the moment there is no urgency to decide this, if we can successfully use PFM format for all HDRI FFT results and scripting functions. So I would be interested to hear what Anthony and Sean have to say.

Thanks

Fred

[magick]

Easy fix. Our previous decision was to inject quantum:format for all formats if the image was HDRI. We'll restrict this check to MIFF. PFM already supports negative values and with TIFF you will need to specify the quantum format. Seems like a good compromise.

[seanburke1979]

For what it is worth, I'll chime in. I'm concerned that the FFT routines may have to be standardized against the HDRI format in either case. Most of the recent work that Fred and I have done has been based on HDRI builds and our best results come out in HDRI.
Many previous revisions ago I had the SetOption routine defined if the build was HDRI - perhaps the solution is for me to put that back in? I don't want to step on any of the toes of upstream developers, so please advise the best course of action. Perhaps the best thing to do is to put it in anyway - this way my code will be a little more impervious to format changes.

Best,

Sean

[anthony]

However, if you & Anthony both think that floating point should be the default behavior we will restore it in the next point release.

I thought IM tried to preserve the image as much as possible, but allow the user options to override that behavior.

Their are so few formats that understand HDRI floating point, and if IM is HDRI compiled, I would assume IM would try to preserve that information, though provide the user with the option to override.

I myself don't mind either way as I am currently not a user of HDRI, though I should document in the HDRI section exactly what IM will do with regards to these three HDRI formats. I'll go with the flow.


However if FFT can use a large integer depth for a less exact filter handling, then I would prefer to see that possibility remain. This would allow users new to using FFT and its advantages in image filtering, to ease themselves into that area. I would of course give lots of reminders that for best use and highest quality a HDRI version of IM will be needed when using FFT, in as many places as possible.

Note I myself have not used FFT before, though I understand just how useful it can be in image filtering, sub-image searches, and other things I would be highly ignorant of. It would be a shame to limit its exposure by enforcing the need for HDRI.

[fmw42]

However if FFT can use a large integer depth for a less exact filter handling, then I would prefer to see that possibility remain. This would allow users new to using FFT and its advantages in image filtering, to ease themselves into that area. I would of course give lots of reminders that for best use and highest quality a HDRI version of IM will be needed when using FFT, in as many places as possible.

Note I myself have not used FFT before, though I understand just how useful it can be in image filtering, sub-image searches, and other things I would be highly ignorant of. It would be a shame to limit its exposure by enforcing the need for HDRI.

The FFT routines are flexible and can produce mag/phase output for non-hdri and either mag/phase or real/imaginary output for hdri. Your question really only addresses the post-FFT processing that can be done without HDRI. Right now everything that I demonstrated in my example page http://www.fmwconcepts.com/misc_tests/F ... index.html can (still) be done in a non-hdri environment using (scaled) mag/phase output from IMFFT. However, the results are not as precise as with using HDRI. Nevertheless, they are quite acceptable. The current problems have come about from the attempt to do blurring and deblurring of motion blur and lens defocus using HDRI as the scripts only seem to work using real/imaginary components which have negative values in each. I have been unsuccessful so far in translating those scripts to a non-hdri, mag/phase environment and do not know if that is possible. This arises from the fact that the fft of these blurs have negative values. The FFT of uniform line or rect function (motion blur) is a sinc and that of a uniform circle (lens defocus) is the jinc function, as opposed to say a gaussian blur which is always positive. I also have concerns whether normalized cross correlation can be done in non-hdri, mag/phase, but have yet to work on that.

The real issue here is that in certain types of processing it appears that they will need to either be written as IM functions or the scripts must be run in an HDRI environment. Thus the concern over what options we have for an image format that will preserve negative values in an HDRI environment and how MIFF/TIFF/PFM perform in such an enviroment. The other issue is anything that Sean will need to do to support the final situation that IM chooses to implement for HDRI and these image formats. Thus we need to hear back from Magick regarding Sean's question above. And I would like to understand better Magick's comments regarding:

Easy fix. Our previous decision was to inject quantum:format for all formats if the image was HDRI. We'll restrict this check to MIFF. PFM already supports negative values and with TIFF you will need to specify the quantum format. Seems like a good compromise.

What does this mean regarding these 3 formats. Please clarify, if you do not mind. What changes if any will be made?

[magick]

ImageMagick 6.4.1-4 Beta (available tomorrow) sets the floating point format if the image is HDRI (out of range values). Previously we set this for all images which caused problems. Now we moved this setting to the individual formats that require it (e.g. MIFF & TIFF). Currently HDRI with out of range values are only supported with these formats: PFM, MIFF, MPC, and TIFF.

[fmw42]

Thanks. That helps me. I presume this means that MIFF will then work the same as PFM in IM 6.4.1-4. Correct me if I am wrong? But I will have to defer to Sean if it answers his question regarding advise on the best course of action for his coding?

Just a quick questions for my own reference. Does IM's implementation support 32-bit float TIFF? That is if we output from FFT to TIFF will it preserve the negative values and the fractional components in an HDRI environment. I was not sure IM supported the full 32-bit float TIFF.

This questions is not a request if it does not. I just want to understand the situation. I know TIFF is not the best format to use. But if it does support 32-bit float as PFM, then it provides a format that can be potentially viewed directly outside of IM. MIFF is IM proprietary and I have not found any other PFM viewer that works or I can use on my computer. On the other hand, it is questionable what application might be able to view a 32-bit float Tiff. So this is just a matter of curiosity.

[seanburke1979]

That answers my question. I'll add the SetImage option in my next version in case a user chooses to use a format other than MIFF. This should accommodate more formats correctly.

Best,

Sean

[magick]

TIFF and MIFF support 32 float and 64-bit doubles which of course includes support for out of range pixel values including negatives.

[seanburke1979]

So does IPL, if I can take a moment for a shameless plug.