[Sorry, been away a few days because I thought this thread had died out.]
I am sure that most people here know that working color space/gamut is immaterial if the data is floating point, limitations only come in at lower bit depths.
Perhaps this shows my ignorance, but I cannot see how the quoted statement is correct. The issue of integer versus floating point should make no difference to whether the working space effectively clips off or crushes down certain colors. It seems to me that
the key issue for what I think you are getting at is whether the color values are 'unbounded'. In other words, does the system allow and retain representations greater and/or less than the maximums defined by the working color space? Normal 16-bit representations for red, green, and blue values go from 0 to 65536. What each RGB triplet set of values means is defined by the color space; what the RGB triplet of 57204, 3812, 25624 means differs (somewhat) depending on the color space--it may be a medium-bright red to somewhat purplish in all of them, but not the exact same color. But suppose the raw converter internally uses (to make the numbers not too large to write and read, only) 18 bits per channel, and represents and accounts for the range of -131072 to 131071. The extra range of those values would represent colors or in many cases quasi-'colors' outside the gamut of the working space (and maybe not visible). If you (1) retain enough data for image editing to well above the working color space's 'maximum' and well below its 'minimum' and (2) maintain enough mathematical precision (bit depth), until you export into some chosen color space,
then how the internal working space defines colors doesn't matter. And whether that sufficient precision comes from using integer representations with more bits or floating point representations with enough bits does not matter. Floating point precision, like integer precision, depends on how many bits are used to represent the number.
I have actually read claims that DxO in fact uses internally an 'unbounded' version of Adobe RGB. If that were true, and the degree to which it is effectively unbounded were sufficient, then exporting DxO raw conversions in (for example) ProPhoto RGB would preserve colors outside of Adobe RGB. But DxO's representative appears to have disclaimed this, within the last week or two.
if one works in floating point one can retain all data, clipped, negative or otherwise.
As far as I know, no floating point calculation
ever retains "all data". There are inevitable rounding and/or truncation errors. At some point they may be immaterial, and even well below the threshold of creating any difference in output even as, say, a 16-bit TIFF. But I bet that a 24-bit integer working space that allowed for negative values would probably be just fine, and an 8-bit floating point working space would often be inadequate.
If you want easy subjects with chromaticities outside of Adobe RGB try lemons or oranges in the shade.
Thanks, I really appreciate the suggestion. Indeed, my tests suggested that orange shadows were one of the places where Adobe RGB's gamut most quickly becomes insufficient. But my tests were pretty crude, and I am not confident in their value.
What's the point of working on an image whose colors one cannot see?
Putting aside the issue of one editing operation pushing a 'color' outside what we can see and then a subsequent editing operation pushing it back inside (making it visible), the point is that a working space capable of representing all of the colors that we can see (which ProPhoto RGB cannot) would be either much more mathematically complex than necessary or else would also be capable of representing 'colors' we can't see.
Also, just because the printer I have now cannot print a particular visible color doesn't mean that a decade from now I won't have a printer that can print that color. IMO there's no sense in throwing away information before we have to.
But hey, I could be wrong--by all means, please tell me what you think.