I think it's just confusing terminologies. My question was:
What does "float" mean in colorist terminology? Below 0.0 and above 1.0?
And it sounds like that is indeed what you're describing here:
The default Range of 0 to 1 is standard for all LUTs, and is the reason for clipping when it occurs. A LUT will only interpret values within that range (anything below 0 becomes 0 and anything above 1 becomes 1), but has no limit to the range of what it can output.
A more precise definition would be: A LUT contains values within a certain number range or domain. That domain
might be between 0.0 and 1.0, which is the default for many LUTs, or it might be between 0.2 and 0.8 or anything else. Most LUT interpolation implementations will "clip" values below the domain min and above the domain max because extrapolation beyond these points would be hard to get right and computationally quite expensive in real-time applications without a pre-processing step. (It's definitely possible to do this technically but it's not as trivial as a simple 3d texture lookup call in openGL which is how most implementations work.) A better reference than research papers here is to just look at code as source of truth. The OpenColorIO Github repo has
color lookup implementation functions for 2D and 3D textures for anyone to study but it honestly isn't all that wild.
That said,
none of this has anything to do with floating point or integer number formats.
Just to illustrate, an 8-bit integer LUT with points [0, 128, 255] is exactly as precise as its 32-bit floating point equivalent with points [0.0, 0.5, 1.0]...
And because it doesn’t break 32bit float like LUTs do
LUTs don't break 32bit float. Lookup functions clip their output image data to the domain min and max of the lookup table they apply to the input image data. What you're observing in the images you posted is a domain clipping issue but it has nothing to do with integer vs floating point number formats or the interpolation accuracy of LUTs.
LUTs are destructive, in two ways; First, their sample-based functionality means they can’t be perfectly reversed, because they weren’t perfectly applied.
That is true for many LUTs because of how the data points they contain were derived but definitely not an inherent technical shortcoming of lookup tables.
There are many aspects of color grading, mostly relating to I/O, that do need an inverse function for workflow reasons, but there are also many aspects that absolutely don't. What's the inverse of a lift gamma gain modifier with a subsequent printer lights adjustment? I'm not suggesting there isn't an inverse, it's all just math, but it simply doesn't matter. Whether lift gamma gain is functionally evaluated at runtime or whether the result of its function is stored in a lookup table with sufficient density to capture its transform characteristic does not matter with regards to the quality of the final image and I would challenge anyone to prove me different. The problem is something else and I will get to that at the bottom of this post.
Key sample points were analyzed and modified, and the blanks were filled in by mathematical estimation;
That is also true, but I think the point is futile and here's my reasoning: "Estimation" is really interpolation in this case. And pretty much all of applied color science is interpolation in one way or another. For example in the form of continuous spline interpolation. A segmented spline is nothing but a continuous evaluation of points along a curve, between points that define the beginning and end of the spline segment¹.
That is interpolation between two or more points, just like color lookup functions use interpolation to compute points in between given data points in three-dimensional space.
What I think the real argument is:
LUTs are just data containers and there are no standards or restrictions that define how the data points are collected, distributed or interpolated¹.
Many LUTs are created using interface tools, where the individual color space transformations that are baked into the LUT have no spatial awareness of each other. In other words, nothing is stopping you from baking a 100+ node tree that is comprised of anything from I/O CSTs, transforms in multiple color spaces, completely unorthodox color warper transformations (because a single shot needed that extra boost of dark, saturated yellows) and a trusty old 2383 print LUT to top things off, into a single LUT. And even that is perfectly fine if you're going to be using that LUT as a color transfer medium to a third party application or platform. Given the LUT has high enough density to capture the intricacies of the grade, and you can ensure you're not clipping shadows or highlights, there is not technical disadvantage that will be apparent in the final image. When it does and when it doesn't make sense to use LUTs workflow-wise is another question, of course.
What I think the solution is:
Don't use LUTs for I/O or when you don't know the exact input and output color space a LUT was designed for. Don't use LUTs if you need accurate inverse transformations. Don't use LUTs when you want to make changes to individual parameters later. Don't expect LUTs to magically retain color smoothness when its transform data points are the result of un-smooth functions (which can easily result from combining different tools in a grading software, even if the individual tools produce smooth transforms).
To bring this discussion at least somewhat back on topic,
all of this is a long winded explanation of why I'm creating Color.io.
It solves the I/O via ACES and helps designing re-usable looks that sit in between these color management layers. The color engine that is responsible for creating the look transforms retains much higher color smoothness than most tools I've used. It does this primarily by using custom color models that are much more appropriate for creative color grading than cone models and by using bidirectional parallelizations that make the individual tools "aware" of each other in the sense that, for example, the luminance modifier "knows" how much density was applied both in a previous adjustment and how much density is going to be applied in a subsequent adjustment in the processing chain. Most tools are actually "bidirectionally aware" in more than one color dimension, to retain an overal smooth 3D transform shape. This is also the reason Color.io can not be a plugin to an existing software because it requires its own processing architecture that I've written from the ground up to achieve real-time performance. That's all really just a more technical explanation for why
@Aaron Kessler probably finds it easier to get nice looking images with the tools in the app. You'd have to jump through so many hoops and be ultra careful every step of the way to get these things right with existing tools. Maybe that makes it a "weird tool that is super niche", but I may just be a bit of a weirdo for obsessing over these things so much. But it's keeping me busy.
¹ Depending on the spline algorithm there may be additional weights that determine the slope of the interpolated curve (think: bezier handle points)
² Tetrahedral interpolation has actually become somewhat of an interpolation standard for LUTs. Small anecdote: I had a back-and-forth with Blackmagic in 2014 and could finally convince them to implement tetrahedral interpolation for color lookups in Resolve.
