The answer focused on the software you mentionned.
Lab has a notion of diffuse white, hence why effort to design an HDR-CIELab model was conducted by Dr. Mark Fairchild. Again though, nonlinear encodings are sub-optimal for image manipulation / compositing.
Think the following is quite interesting for this discussion: ACES2056-1 found on ACES docs
If you look in Apendix A section 4.2.2 the colorspace is actually defined for negative values
Also reading that document is seems to be advised to set R=G=B=0.18 to be the value of a neutral gray card (see for example section 5.3.1)
Going all the way to ANEX B provided everything was captured with the reference image capture device (RICD) under a D60 illuminant values for diffuse white are also defined.
I mentioned darktable since that is currently the only software I know that uses floating point CIE L*A*B* so was intended more to be an example and as can be seen above even ACES as a notion of diffuse white 
That is AP0, the archival encoding primaries. Noise floor issues etc. Not for manipulation. AP1 is designed for that.
Ideal, perfect diffuse white that is really hard to find in reality has a reflectance of 100% and you align your exposure using a 18% reflectance card as middle gray. Itâs an exposure reference, not something akin to the values captured by your camera or created in your imaging software.
Youâre capturing light ratios, they come from diffuse reflection, specular reflections or direct emissions.
In the case of the latter, what do you think 1.0 means?
Seems to be also true for AP1 (ACEScg[1]) see section 4.3 of S-2014-004 found at the same page:
I know but @anon11264400 statements seem to imply that a scene referred workflow doesnât have any preferred meaning of 1.0,1.0,1.0 which is seemingly contradicted by the ACES standard (where that is roughly defuse white under D60)
[1] Which uses the same primaries as ACEScc but since that is a log encoded space I think we can safely ignore that in this discussion
Is it?
Did you read my footnote above?
Yes I did but that things get weird if a non-reference whit point is used is also true for display referred data and ACES AP0 seems to be specifically build around a RICD for which the illuminant is defined to be D60 and in that case 0.18 and 1.0 do have specific meanings (I would like to add that R=G=B=1.0 in AP0 is also R=G=B=1.0 in AP1). It is true that the ACES spec does allow people to deviate from this in which case this meaning is lost but since generally speaking in the cinema industry there is full control of the lightning my guess would be that most aim to follow the advice in the spec (since it makes working with CGI a bit easier).
Ergo according to your footnote it is unusual for there to be an albedo value, to my reading of the specs this is actual the expected way of working so there is usual an albedo value.
Donât conflate an intensity of a pixel emission value with some meaning.
A perfectly diffuse reflector would reflect a scene referred value of 1.0 if we apply a 0.18 convention for a scene referred middle grey. However, we cannot take a capture and deduce that all values of 1.0 indicate that within the scene the object is a perfectly diffuse 100% reflectance object.
Further still, we shouldnât be conflating encoding values with working scene referred image manipulation models. This leads down that familiar path of madness.
I would add that when someone says âwhite pointâ as a term, it typically references an achromatic chromaticity coordinate. Here however, we are speaking of intensity, which can be a confusion of terminology.
Thatâs actually a very interesting point⊠@anon11264400: could you explain how you get WYSIWYG in any processing workflow involving scene-referred pixel values or arbitrarily high intensity?
To my understanding, whatever you see is limited by the dynamic range and color gamut of the output device you are using. For example, there is no way to see the brightness of the sunlight with a standard monitor, even an high-end one, right?
So, according to my understanding, the view compresses the real dynamic range of the captured scene into the dynamic range of the display device. There are various methods to accomplish this, but they all modify the scene-referred values. For me this is not really WYSIWYGâŠ
This seems to be corroborated by what @gez mentioned earlier in this thread:
This other point is also very relevant to the discussion being carried on in this thread:
I think this discussion clearly indicates that there is some interest and effort in the FOSS community to go beyond sRGB in the most appropriate and technically correct way. Personally I am putting quite some effort in the attempt of developing a non-destructive editing software that can correctly work with arbitrary linear RGB colorspaces, without any limits imposed to the pixel values.
I am learning quite many things here, and hopefully what I am learning will end up in better tools for the usersâŠ
Not talking about the intensity of emission of a pixel here since that is trivial to change (at least in an OCIO workflow) I am more talking about that in a scene referred workflow the encoded data can and often does have certain meanings. Sure those meanings are dependent on agreement instead of âhard codedâ (as in display referred data) but I still think that is interesting to note. Mostly due to the following quote of yours:
Since as far as I can tell (from âthe Reproduction of Colorâ by R.W.G. Hunt) there is nothing in the definition of LAB that has anything to do with diffuse white (there is that L* needs to be derived from a reference Y often called Yn sure that is often chosen in such a way that 100 is diffuse white but it doesnât have to be)
Anyway this is all a bit of a sidetrack and do agree that in a scene referred model it would be bad to assume that that anything has any particular meaning, even tough in a specific implementation it might.
I was talking about chromaticities there but rereading your footnote I think I got it wrong what you where talking about but if that is just intensity then the properly exposed part of the image should have a 1.0 for a perfectly diffuse white object (under a D60 illuminant)
Thanks for the video, need to do some follow up reading to fully understand what is going on.
This I perfectly understand, however at a certain point one has to send the pixel values to an output device, and thatâs where the 1.0 upper limit becomes relevant, right?
Having watched the video and did some reading a think I understand the problem with CIELAB in HDR, to summaries LAB is/was designed to be perceptual uniform and up to at least diffuse white this seems to be true, but L* will always increase with rising Y even tough it is know that our eyes have a certain upper limit (e.g. making things brighter wonât make it look brighter)[1]. Of course this is a bit of a problem if you want to preserve the perceptual uniformity of the color space so research is ongoing to make an HDR-LAB that uses a sigmoid[2] instead of a power function.
Now this HDR-LAB is useful for color difference functions and certain topics of research but not very useful for processing HDR images[3]
Going to finish this tangent since I also do agree that a scene referred model does require a linear color space since the algorithms deal with energy instead of perceptual modifications. Note that this does mean that negative values sometimes might make sense since energy (like almost everything in physics) is relative so there might be cases where it makes sense to have a positive illumination at R=G=B=0 (this should probably be pretty rare)
[1] Funnily enough it seems our eyes can be seen as âdisplay referredâ (of course this doesnât really make sense since biology gets involved and it gets a bit messy there)
[2] sigmoids are a function of the form f(x)=a^x(/a^x+1) which maps <-inf,inf> to [0,1]
[3] Also it seems from the conclusion of this http://rit-mcsl.org/fairchild/PDFs/PRES19.pdf as well as this http://scholarworks.rit.edu/cgi/viewcontent.cgi?article=1230&context=theses that the original power function is surprisingly accurate to at least L*~200
Here is a screenshot of PhotoFlow showing your test EXR file, with a âfilmicâ tone-mapping layer inserted before the internal ICC conversion to the display profile:
As a reference, here is your original blender screenshot:
My impression is that the two âviewsâ are very close, if not identical. Notice that PhotoFlow uses a workflow which is purely ICC, but offers the possibility to insert non-destructive tone-mapping curves at any point in the pipelineâŠ
Of course the process of bringing 12 stops of information down to fit within the range 0-1 floating point requires linearly compressing the data, assuming oneâs raw processor does allow output with channel values proportionate to the scene as captured by the sensor and saved as the raw file. This isnât news. I figured this out with a spreadsheet a very long time ago, and I bet a lot of other people on this forum also figured this out.
With todayâs raw processors allowing to output floating point images, the image does no longer need to be compressed, fwiw. Unless you are saying that because our free/libre raw processors use ICC profile color management, they must either compress or clip.
So Iâll just ask my question again:
In your view of how the world of image editing ought to work, is it required that an ICC profile color-managed raw processor either clip or compress a floating point image from an interpolated raw file before saving the image to disk in a file format that supports floating point values?
Turning to what you refer to as WYSIWYG, you seem to be proposing that the user should not be allowed to see the linear data as output by the raw processor. Instead the data should be sent to the screen already tone-mapped in a way that more or less realistically depicts the actual scene the photographer saw when the picture was taken.
Is this what you are saying? The user must only and always be shown a tone-mapped version of the image?
I was preparing a similar file with PhotoFlow 
, but using a scene thatâs a little more representative of something a photographer might actually point their camera at. So Iâll just go ahead and post my screenshots:
Raw processed using 0 exposure compensation - a bit of the metal is above 1.0, but itâs not clipped:
Adding four stops of exposure compensation brings most of the image up to more or less match what I saw when I took the photograph, but of course the highlights are blown out. However because PhotoFlow operates on unbounded/unclamped/unclipped channel values (choose your own preferred terminology), the channel data is still available for further processing:
My contention is that any photographer can get a good idea of what they might want to do with an image with a similar dynamic range, by examining both the âcompressedâ and the +4 ev versions of the image as shown above. But moving along to do some nice tone mapping, hereâs the result of using PhotoFlowâs filmic tone mapping:
The ony problem left to resolve in terms of making a final image is that part of the brass fixture on the lamp is still blown out, which a Levels adjustment can handle:
Personally Iâd put a mask on that last Levels adjustment to confine it (as much as possible without introducing any odd transitions) to the brass fixture.
If someone handed me an image editor that only allowed to see my image as already processed by some tone-mapping, Iâd say âthanks, but no thanksâ.
This is a pretty critical point, and one that many folks overlook when thinking about things.
The combined output of any camera is a series of software and hardware. In terms of aesthetics, the transfer function and more importantly, the colour science behind desaturation, potential gamut mapping, and such, form a critical role in the WYSIWYG of the image.
Just as you noticed, at no point in a display referred pipeline attempting to use scene referred concepts are the colours correct; you are only seeing a sliver of the dynamic range if you manage to hack around it. Even if the colour fits within that extremely limited dynamic range, it is in the incorrect final code value position, as well as very likely lacking a correct desaturation. The only option is to apply nonlinear compression, which while it works and has worked fine historically, will break the expectations around contemporary compositing / manipulation. The nonlinear compression approach will also bundle the entire aesthetic view transform into the scene data, which can result in issues for some manipulations / compositing.
Ultimately those form the more important aspects of the view transform; a reliable, constant, and stable series of transforms that convert the scene referred data into the display referred, forming the final image[1].
View based approaches allow for a varying number of views based on the display colorimetry chosen. This might include proper linear views, a full virtual camera reconstruction, a heat map, technical transforms for alternative contexts, etc.
In terms of imaging, a proper view wouldnât merely be a transfer function, but rather a series of various transforms embodied in the view. For an example of the series of complex transforms, one can look into the official ACES configuration.
In typical imaging, yes you want to always make your creative judgements based on how the image will look when rendered through the virtual camera. This may or may not include custom looks tacked onto the chain.
This isnât exactly a revelation; most contemporary applications have been able to do this all along, and in fact every compositing application provides a discrete clamp node for surgical clamping, where the default is to leave values as-is.
No. I will lean on terminology that far more experienced minds have used and continue to use.
[1] The HDR10/+, Dolby Vision standard forms an additional series of nuances that need to be accounted for. However, these are also based on scene referred data, so starting with the correct approach makes the transition much more accurate and streamlined.
From what you say it seems that your camera viewer and the software you use only show a raw dump of the linear data captured without any base curve or dynamic range compression and you prefer to edit your data by numbers, and tonemap âartisticallyâ as a finishing touch.
To my knowledge, thatâs not what most people want. It might work for you, but artists and photographers usually prefer to use their eyes to guide them in the process of preparing an image for an output.
We like to see something close to what our eyes saw in the original scene. Thatâs why a view transform is mandatory when you work with scene referred data.
You donât want an orange shade turn yellow because of channel clipping. You donât want your skies turn cyan because of channel clipping, you donât want magenta violets in your picture because of channel clipping.
And thatâs exactly what you get when you work blind without a view that resembles the response of a filmic camera or your eyes, as my example with the colour swatches clearly shows.
You never see an orange turn yellow because of intensity, not in reality, not in photos (at least not in photos taken with a decent camera and certainly never with film).
And citing your example above: you never see a night scene from a lamp turn flat yellow. So no, thatâs not what an artist expects. Your âno, thanksâ for âsome tonemappingâ sounds like something nobody says in reality.
I donât mean to be aggressive with this comment, but you really sound like youâre denying the very basics of image and photo editing just for the sake of justifying a model that has troubles to deal with the display of scene-referred images.
My apologies, but what you say seems like a straw man argument set up for the sake of knocking it down again.
Anyone who has spent any time at all editing photographs already knows that colors âlook wrongâ when the information thatâs sent to the screen has clipped colors. And surely everyone on this forum also knows that adding +4 ev to the starting image results in clipped colors being sent to the screen.
Also, if you object to the PhotoFlow stack that I showed above, on the grounds that at the first âLevelsâ node results in clipped colors being shown on the screen - even though the immediately following filmic curves node brought the colors back into viewable range - then use Curves, though your requirement of not sending >1.0 channel values to the screen seems arbitrary and limiting:
Iâm not doing anything âjust for the sake of justifyingâ using GIMPâs or PhotoFlowâs or darktableâs or Kritaâs (which also uses ICC profile color management in addition to providing OCIO support) high bit depth floating point processing. I use these applications every day - have used them for years now - because they are really nice for editing.
If you want to show this forum another nice way to edit, using OCIO, thatâs great! But why the insistence on attacking existing free/libre software on the grounds that you donât like the idea that an ICC profile color-managed editing application might be used with floating point RGB data?
To be fair, your attacks on limitations of ICC profile color management are âon pointâ for V2 ICC profile color management. But in the last 15+ years, a whole lot has changed and improved in ICC profile color management (despite my occasional sniping at a few of the changes regarding white point tags and such).
We are not still using V2 color management with its integer-encoding limitations. We are using V4 color management which supports floating point processing and parametric curves, which by the way allow for conversions that donât quantize and clip in the way that OCIO LUTS can easily quantize and clip.
Straw man is flipping software trying to find a shred of a legacy workflow that tries to create the appearance of mitigating the problemsâŠ
For the rest of the people that can see the glaringly obvious issues though, I am without words.
Carry on Elle. It all works. It is all terriifc. Everyone that uses more contemporary software is clearly in the dark and Libre will lead the way.
Enjoy yourself.
You utterly, tragically, and entirely missed the point.
