OK, here’s what I did do with the Rec709.exr file, with a nominal goal of preparing the image for display on the web:
-
I opened the Rec709.exr file. GIMP assigned the built-in linear sRGB color space, which is the same as linear Rec.709.
-
I color-picked around and located some of the out of gamut colors, which are mostly located in the yellow and red flower parts.
-
I used “Colors/Auto/Auto/Stretch Contrast”, making sure “keep colors” was checked. This was an OK thing to do because there aren’t any negative channel values (in images with negative channel values “Stretch Contrast” can turn the entire image to a pile of neutral gray). A safer edit would be to use “Colors/Exposure” to bring the >1.0f channel values back below 1.0f.
-
As expected, “Stretch Contrast” made the image considerably darker by lowering the intensity of all the pixels. So I applied this curve to raise the shadows and midtones and compress the highlights, and make the image more or less as colorful as the original image: rec709.curves.zip (1.9 KB)
I’d show the resulting image but I’m not sure what the copyright status of these images is. But the link to download the file has already been given above if anyone wants to experiment. I actually like the slight increase in petal detail in my tone-mapped version of the image better than the original image.
But of course I couldn’t actually see the original image because there isn’t an HDR viewer in GIMP that allows to view different portions of the dynamic range. Levels or Exposure can be pressed into service - just hit the Cancel button instead of applying any actual change - but this is a bit awkward. Nor is there a viewer that tone-maps to show the image in its entirety, though personally I don’t usually like such viewers as imho the tone-mapping of the viewer gets in the way of tone-mapping, so to speak.
Arguing whether it makes sense to speak of the >1.0f channel values as “non data” is basically just arguing over terminology. Regardless of what you call these channel values, the original image isn’t suited for display on the web or for printing until the >1.0 channel values are either clipped or corralled, to use @ggbutcher’s very apt term. And many other types of edits that one might want to make, don’t work very well with “out of display range” channel values.
But please note that this dictum to first corral the “non data” is not true of all types of edits one might want to make, starting of course with the edits one might make to corral the data in the first place.
Whether any given operation can be safely, sanely done on “non data” depends on the specific algorithm, the RGB encoding (if there is channel data outside the display range, the RGB values should be encoded linearly), the nature/source of the “non data” channel values, and the goal of the person making the edits.
Clipping good data - or “non data” that can be turned into “good data” - just makes no sense to me. So I used Stretch Contrast and Curves to corral the data and do something nice with it (well, I thought the final image looked OK, it’s an odd image to begin with).
The same considerations apply to interpolated raw files in which there happen to be channel values >1.0 either from the user applying too much positive exposure compensation or else from applying the white balance multipliers in a raw processor that doesn’t provide the equivalent of dcraw’s very useful “-H 1” switch. Here the “corralling” is simple: use negative exposure compensation. Again, clipping “non data” that can be turned into “good data” by the simplest possible edit, this seems like an odd thing to do.
Photivo, if it’s still around, has an equivalent to dcraw’s “H 1” switch. But I don’t know of any other free/libre raw processor besides Photivo and dcraw that have such an option. Though I’m guessing rawproc does have such an option 
.
IMHO @anon11264400 is absolutely right to suggest that raw processors should make it easy to get an interpolated raw file that doesn’t have channel values >1.0. Though I don’t think this should be mandatory because developers just can’t predict what users actually want or need to do with any given image.
My floating point version of dcraw (dcraw-float: floating point dcraw - completely out of date version of dcraw used in this code!) has this “normalization” built in, except that in addition, similar I think to @snibgo’s dcraw mods (dcraw and WB) there’s also an automatic stretching to the maximum dynamic range without clipping any of the highlights. Maybe it would be good to make such “option to Normalize the interpolated raw file” enhancement requests for various our free/libre raw processors
But given that it really is easy with our current free/libre raw processors to get channel values from an interpolated raw file that are >1.0, let’s say the image is sent to GIMP in this condition. Clipping these channels in GIMP as “non data” just doesn’t make sense.
Instead use “Colors/Exposure” or equivalent function to bring the channel values to below 1.0f, thereby turning “non data” into “good data” - if indeed that seems like the thing to do given whatever other goals the user might have in mind. Sometimes the most aesthetically pleasing thing to do with an image that’s otherwise ready to be output for display, is just to clip any channel values outside the range 0.0f-1.0f.