Welcome, Guest. Please Login or Register
Home Help Search Login Register
Pages: 1 2 
Send Topic Print
Photomatix 4 - OpenEXR bug on OSX (Read 24965 times)
Blochi
Administrator
*****
Offline



Posts: 1726
Hollywood
Photomatix 4 - OpenEXR bug on OSX
07/25/10 at 09:58:59
 
OK, this topic actually has a history.

Photomatix is my tool of choice for batch merging HDR images, especially for HDR stitching. And Photomatix 4 is awesome because it adds a significant speed increase. However, I had to roll back my OSX version to 3.2 because of a nasty saving bug with Open EXR.

I found it first during the beta test, reported it, and there was a lengthy email exchange with Geraldine about it. Provided she grants permission I can post that when people are interested...  As it turned out, the bug was considered too hard to fix, or rather, not worth fixing because of how stupid it is, and how much effort it would take. It was also considered a "special case" that nobody else could possibly run into. Turned out, other had the same issue. Mark Banas recently made it a topic on the Photomatix beta list, and my explanation was too lengthy to pass moderation. That's why I'm taking the discussion here.

What am I talking about?

Open EXR on OSX saves differently than on PC.
The default exposure seems inconsistent, when having Photomatix batch convert an entire folder of brackets for a panorama. A folder like this:

...

Batch converting these to openEXR with Photomatix 4 results in something like this: (different set)

...

As you can see, these images do not match in the default exposure. The data is all there, but it's very tedious and unprecise to manually adjust the exposure to match.

But on the PC version, as well as in Photomatix OSX 3.2.2. the EXR images match:

...

In both cases my Batch settings are like this:

...

...

So there was something wrong, for sure.

It happens on all Mac versions from 3.2.7. upwards, and is rooted in the fact that these versions use OSX's built-in OpenEXR format. OSX insists on clipping everything over 1.0 values (white), which you can easily observe when you pull down the Exposure in the Preview App. As countermeasure Photomatix normalizes each image when it's saved as OpenEXR, which results in the inconsistent normal exposure.

So that is a known bug, but apparently the fix is very hard. I rolled back to version 3.2.2. for all my HDR batch merging.

Here is Gerldine's comment:

Quote:
I have now investigated further and the problem comes from the fact
that Photomatix is now using Apple's functions to save files in
OpenEXR format, which was needed to build a 64-bit version of
Photomatix.  Those functions require that the HDR floating values to
be saved as OpenEXR are in the [0 -1] range, all values greater than 1
getting clipped.  This means that Photomatix needs to normalize the
HDR values to 1 before calling the fuctions for saving as OpenEXR.
This is done based on the maximum and minimum values of the HDR image,
and since these max and min vary depending on the scene, you then get
this issue when you need to stitch the images.

The solution to this would be to ensure that the output of the merge
to HDR is always inferior to 1 by scaling them by a an absolute
maximum. However, this means that the HDR image from Photomatix would
then look very dark in Photoshop.  But more importantly, doing this
implies to set a maximum to the values that an HDR image can take,
which would not be a correct and defeats the purpose of an HDR image.

So, when you need to avoid the normalization to 1, you will have to
either save in the Radiance format, or use the Windows version of
Photomatix Pro as this is still using the OpenEXR library which does
not require normalizing to 1.


OK, so we have a working workaround and it may sound like a small issue. But I do not see Apple putting enough focus on that particular area to fix this in a timely manner. Or ever. So we have a David VS Goliath situation, where I was trying to motivate the David to keep on fighting.

I'm not the only one with this issue, Mark Banas discovered the same thing during HDR panostitching, but it also breaks the photographic workflow. Let me throw this example together:

- Loading an EXR that has been saved will look even darker in Photomatix when reloading it.
- Let's say the photographer has tonemapped that image initially right after creation. Now he wants to revisit it, but change the tonemapping parameters just a little bit. For that he saved the parameters initially.
- Loading the EXR, and applying the tonemapping preset previously saved will look very different from what he got in the first run.

This normalizing also throws any timelapse HDR sequence off.

Mark Banas also prefers to use OpenEXR for good reasons:
Quote:
This is interesting, because Greg Ward is the one who suggested I use
OpenEXR instead of Radiance as a "working" file format, and only
output to Radiance if needed for input into another system.
http://www.radiance-online.org/pipermail/hdri/2006-June/000106.html

His point, I believe, is that while Radiance can *potentially* hold a
(much) greater tonal range than EXR at 1/10 the relative precision,
there is very little possibility in my workflows (capturing 12-24ev of
dynamic range) that I'll exceed the range limits of EXR. And truly, I
haven't seen it exceeded in the years since his suggestion, even when
using dedicated capture systems like SpheroCamHDR or Civetta.

That said, most of my needs are not that "color precision-critical"
either, so it's possible that using Radiance would make little
difference for my needs. I'm currently testing this out (using
Radiance as the "intermediate" file format in my workflows), so I'll
let you know how it goes!


and later he adds:
Quote:
I prefer to use OpenEXR as the output, since the files are better compressed and have higher precision than the Radiance ones.



Now, this was commented by Geraldine:

Quote:
OpenEXR files have a higher color precision than Radiance files, but it is usually the other way around for tonal precision when the image file is an HDR image.  This is because the dynamic range OpenEXR format is able to encode is often not sufficient for scenes that have a particularly high dynamic range, and thus saving as OpenEXR in such case may result in substantial loss of tonal precision, which will show as banding artifacts.


While a high color precision is nice, I am not sure it has practical advantages when using 32-bit HDR images.  However, tonal precision is essential for a "real" HDR image, i.e. an image that represents a high dynamic range scene.  I would thus recommend saving HDR image files as Radiance rather than OpenEXR for precision considerations.


And when Robert Fisher mentioned that OpenEXR's advantage of allowing negative values is of questionable importance for a photographic workflow anyway, I could not hold back a lengthy rave about how awesome and important OpenEXR is.

Still with me?

Here we go, now comes the answer that did not pass through moderator approval:
Back to top
 
WWW  
IP Logged
 
Blochi
Administrator
*****
Offline



Posts: 1726
Hollywood
Some thoughts on EXR vs. HDR:
Reply #1 - 07/25/10 at 10:25:03
 
Some thoughts on EXR vs. HDR:

The importance of negative pixels is indeed unclear. Artificial sources, like in painting or rendering very frequently rely on negative values (for example, when we talk about normal maps or displacement maps), however, for photographic sources it's questionable. Yes, you will only ever shoot in the positive space. Color-correction, however, can push pixels into the negative space and it's at that point it's very easy to loos these values in any program.
There is one case that I was always suspecting negative values may be handy, and that is the color gamut. If only ONE channel is allowed to go negative, that would essentially allow colors to break free of the RGB triangle of the primaries.
Let me explain: Normally, the primaries define the hard limit of representable colors. For example, in the diagram below the white dot is marking a pixel that has no blue, and it is allowed to wander from 0 red (leaving only green), until full red. That means, the inner surface of the triangle are the accessible coordinates for that pixel.

...

Now, if negative values are allowed, we could give the Red channel a negative value. And that would place the dot over here:

...

Essentially, negative Red values open up the entire left side of the diagram as accessible colors. Same goes for the other color channels, and that is the reason why I believe the placement of the color primaries is irrelevant now in terms of preservation. Of course, it should be know, so we can uniquely identify the color coordinates - but we might just as well stick to sRGB primaries at all times - no need to move them around and make the inner triangle cover more colors.

Now, it does take some more convincing arguments to prove me wrong than "our code do not foresee that case" or "this is not how our color math works". It should be entirely possible and if a program doesn't handle negative colors I can only consider this a bug. And in fact, I have seen rendered Radiance HDR files where some pixels on a super-blue sky flip into purple near the bright sun, whereas EXR was in fact fine.


Another consideration, taken straight from page 49 of my book: The DR from the surface of the sun to the faintest starlight is about 44 stops. I really did the math there, can't remember the sources though. Indeed, Radiance HDR can handle 253 stops, and EXR is limited to 32 stops. However, as long as we stay on the surface of this planet, 20 - maybe 22 stops is the highest you will ever get in front of your lens. And that already includes shooting straight into the sun out of the bottom of a dark cave. So the dynamic range EXR can handle is really sufficient, especially when you consider the low end limited by camera noise.

Next consideration, on the original topic of EXR for panorama stitching:
To assist PTGui with the blending, the ideal workflow is to mask out unwanted parts of the image in Photoshop before stitching. Especially, on the nadir shot that is absolutely necessary:

...

Here OpenEXR's ability to carry an Alpha Channel is absolutely required.

I do not dare to stitch mixed sources (flat images in Radiance HDR and pre-masked images in EXR), so this Photomatix bug is asking me to convert all HDR files to EXR and thus adds another unnecessary workflow step. It's much easier to roll back to a Photomatix version where I can generate proper EXR files that are non-normalized.

And yes I understand that it is the fault of OSX's implementation, and I agree that this is a crime. But I don't see Apple changing this in the near future, and I think a dedicated HDR program should be considered superior than let's say Preview, and demonstrate a better understanding by handling OpenEXR properly. ProEXR for Photoshop does, and I cannot do more than point you to the source code and get you in direct contact with developers that actually manage to do it. Brendan Bolles from ProEXR is a great guy and provides his After Effects libraries here as open source, there's also a possible solution mentioned in the OpenEXR Dev list.

Long explanation, but hopefully it made it clear that this is not a minor issue for me. Or anyone stitching HDR panos.

If you made your own EXR saver instead of using the system's default, you could also benefit in the long run by supporting more of it's features. I would love to see a multilayered EXRs coming out of Photomatix, where one layer has De-ghosting applied and the other one doesn't. Then I can easily blend the best of the two in Photoshop. I would also love to draw a crude Alpha mask like this in Photomatix directly, the interface is already there with the new semi-manual de-ghosting.

My 2 cents,
Christian Bloch


BTW, it was Geraldine asking me to take this discussion to an this forum, and I'm really happy that she welcomes an open discussion. If this post sounds like I'm bashing on Photomatix, that couldn't be further from the truth. I love it, that's why I care, and that's why I take the time to do everything to get this nasty bug fixed.
Back to top
 
WWW  
IP Logged
 
BobF
Junior Member
**
Offline



Posts: 8
Re: Photomatix 4 - OpenEXR bug on OSX
Reply #2 - 07/25/10 at 12:56:33
 
Hi Christian.  Couple questions for you.

In the gamut graphs, from what you've written the large gamut is the visible colour range, correct?  And the innner triangle is sRGB, correct?  What is the cross-hatched section of the larger gamut?

I understand your point about using negative values and being able to expand beyond sRGB without using something other than sRGB but why not use a broader space like AdobeRGB or ProPhoto?  Also, even though the 32 bit EXR file may be able to handle negative values, once that file is tonemapped and brought back into an 8 or 16 bit space, do we not need the larger colour spaces like Adobe and ProPhoto?  Otherwise those negative values which may be available in the 32 bit environment are lost if the LDR file is tagged with a small gamut space like sRGB.
Back to top
 
WWW  
IP Logged
 
Blochi
Administrator
*****
Offline



Posts: 1726
Hollywood
Re: Photomatix 4 - OpenEXR bug on OSX
Reply #3 - 07/25/10 at 19:22:48
 
The crosshatched section just indicates the range of accessible colors. Usually only the inside of that triangle - accessing a larger space requires a larger triangle. On the second graph it indicates the gamut expansion accessible with just a negative red value. Thought this makes it more understandable, of course this happens to all sides when you consider Blue and Green to be allowed to go negative as well....

Very good point about the conversion to 8 or 16 bit. There is much more happening in tonemapping anyway, much more would get clipped off when not taking good care. Indeed, out-of color values would clip unless you do the conversion to Adobe RGB at this point. But for this to work correctly, you will need to know the original position of the primaries while it is still in 32-bit mode. And that may actually become harder when you allow the 32-bit values to be in AdobeRGB or ProPhoto.

Yes, OpenEXR does have a dedicated place to save the position of the color primaries. You couldn't really call it AdobeRGB, though, even if it has the colors placed in the same place. Because standard color profiles always define the Gamma at 2.2 or 1.8 or something like that. But in HDR, the Gamma is always 1. So we would be talking about "Linear ProPhoto" or "Linear AdobeRGB" and the like. Anyway, no software seems to read or write these embedded color primaries. So we are safer to assume sRGB primaries would be present here, adhering to the de-facto standard. At least then we can correctly translate them during tonemapping to ProPhoto and the like.

Back to top
 
WWW  
IP Logged
 
davidb
Ex Member


Re: Photomatix 4 - OpenEXR bug on OSX
Reply #4 - 07/26/10 at 08:05:14
 
Do the apple file functions allow editing the exr header? 

Scaling values to the 0-1 range then modifying the whiteLuminance field would get you a long way there, although it still wouldn't manage very bright scenes. 

If apple don't let you do that then editing the header post save might be possible, although I can see exactly why they wouldn't want to do it.

Back to top
 
 
IP Logged
 
Blochi
Administrator
*****
Offline



Posts: 1726
Hollywood
Re: Photomatix 4 - OpenEXR bug on OSX
Reply #5 - 07/26/10 at 09:07:37
 
If that white luminance field would be detected by PTGui, it would be a pretty invisible workaround.

My guess is that CoreImage itself doesn't handle anything brighter than white. So the EXR support in OSX is a complete fluke, sort of like "sure, that Ferrari engine fits in this Ford - we'll just have to throttle so the chassis isn't torn apart."
Sadly, it was working fine before Snow Leopard - you could even open EXR files in Preview and play with the Exposure. It was dog slow, but it worked...

Not sure where you file bugs with Apple, maybe it needs a petition or some lawsuit or media riot. Wink
Back to top
 
WWW  
IP Logged
 
davidb
Ex Member


Re: Photomatix 4 - OpenEXR bug on OSX
Reply #6 - 07/26/10 at 10:15:13
 
I don't have ptgui installed, but if you like I can generate some exr images with different values for you to try.
Back to top
 
 
IP Logged
 
Blochi
Administrator
*****
Offline



Posts: 1726
Hollywood
Re: Photomatix 4 - OpenEXR bug on OSX
Reply #7 - 07/26/10 at 10:32:27
 
err ... sure. Let's see. just Zip and attach.
Back to top
 
WWW  
IP Logged
 
davidb
Ex Member


Re: Photomatix 4 - OpenEXR bug on OSX
Reply #8 - 07/26/10 at 11:06:26
 
OK.  The attached file contains 2 exrs.

sng.exr is just a crop of a picture I took last year.
sng_bright.exr should have exactly the same numeric values for each pixel, but the whiteLuminance field in the header is scaled by a factor of 100.

Not all software respects the luminance multiplier field, which is unfortunate as it the only way to handle very bright images with the half precision exr.
Back to top
 

exr_test.zip (Attachment deleted)
 
IP Logged
 
Blochi
Administrator
*****
Offline



Posts: 1726
Hollywood
Re: Photomatix 4 - OpenEXR bug on OSX
Reply #9 - 07/26/10 at 15:42:36
 
hmm.... both images come out as fully transparent. Not even Photoshop shows any RGB data...
Back to top
 

empty.jpg (Attachment deleted)
WWW  
IP Logged
 
davidb
Ex Member


Re: Photomatix 4 - OpenEXR bug on OSX
Reply #10 - 07/26/10 at 16:04:21
 
Someone mentioned that before, but I never tracked it down.  Let me have another look...


Aha!

I just found a bug in my EXR writer - everything was being written with alpha = 0.  An easy fix fortunately Smiley

Try these images instead:
Back to top
 

exr_test2.zip (Attachment deleted)
 
IP Logged
 
Blochi
Administrator
*****
Offline



Posts: 1726
Hollywood
Re: Photomatix 4 - OpenEXR bug on OSX
Reply #11 - 07/26/10 at 18:07:34
 
Nope, they both show up as superbright, and at -10 EV they both show up as the same brightness:

Good attempt, though - wish it would have worked.
Back to top
 

minus10.jpg (Attachment deleted)
WWW  
IP Logged
 
tischbein3
Ex Member


Re: Photomatix 4 - OpenEXR bug on OSX
Reply #12 - 07/26/10 at 18:12:37
 
Quote:
If apple don't let you do that then editing the header post save might be possible, although I can see exactly why they wouldn't want to do it.

Well and thats exactly those kind of consequences wich are the real evil behind this:

Welcome to the beginnings of watering down and uselessly diversify a well-thought, cross-platform supported file format.

And if I would be on a mac I would actually fill in a bug report, describing the consequences if you had to use multible applications, never knowing if they actually stick to their own loader/saver routines or use those provided by apple.
Back to top
 
 
IP Logged
 
kirkt
Ex Member


Re: Photomatix 4 - OpenEXR bug on OSX
Reply #13 - 07/26/10 at 18:29:20
 
THis thread explains a lot of the frustration I have with EXR in Snow Leopard.  Thank you for making it understandable.

[sigh]

Kirk
Back to top
 
 
IP Logged
 
Martin Clark
Ex Member


Re: Photomatix 4 - OpenEXR bug on OSX
Reply #14 - 07/26/10 at 18:39:57
 
macs are expensive.

torrents + windows 7 was my idea. Smiley
Back to top
 
 
IP Logged
 
Pages: 1 2 
Send Topic Print