The algo maps the lower bound of the latitude to the black value, expecting the latitude to be higher than black. There is no handling of the case where latitude is lower than black because it does not make sense (it’s basically asking for a non-monotonous curve). I could sanitize values later, between GUI params and pixel ops params, and hide user mistakes, but I don’t want to : I can already hear the next youtuber saying “if I push the bias very far, it doesn’t seem to change anything, so it’s the same”. Silly settings should produce silly outputs that blow up in your face, otherwise users get wrong ideas.
If you only care about output, please use a tone curve. Remember, in a near futur, output will be SDR and HDR alike, so we need to be output-agnostic and filmic is designed around the idea that the output DR may change at export time while still having to preserve the mapping intent.
The mapping intent is defined by how the midtones should be mapped, provided that the extreme luminance values will need to adapt to whatever output. Midtones are where most of the details are and we know for sure that any display will be able to contain them. This is why middle-grey is central in the filmic approach.
Because \log(0) \rightarrow - \infty, and while 0 is a correct RGB code value, it means nothing physically. Display ICC profiles don’t contain the luminance of the medium black (highest density)*, so all we know about output is it’s encoded between 0-100%, which appears to be an infinite DR.
* even though ICC v2 had a metadata field for that medium black, that was removed in ICC v4 because nobody used it, and HDR profiles re-introduce a medium white metadata because that’s critical for tone-mapping in a fluid DR setting. So, right now, black point compensation uses an indirect methods through the TRC floor value estimation to get a sense of that medium black, which clearly shows ICC people have had the head shoved in their asses for too long to be trusted ever again.
What problem does that solve ?
The default latitude has moved between 25% and 33% of the scene DR in past years, depending on splines used. In the past 2 years, I have had to change it only for HDR inputs (that is, exposure-stacked HDR or synthetic renderings with more than 15 EV of DR).
There is this user bias that consists in thinking that, because there are n parameters available, users should manually change exactly n parameters. The reality is latitude rarely needs editing at all, it’s there as a safety fallback for difficult cases. And if you need to change it, you have a control monitor showing the curve with a fat orange warning that shows up when you create problems.
If anything, I would rather look into a different formulation of the bias that prevents moving outside of the range, but I don’t think inputing y_1 and y_2 manually will scale to any output DR.