we’ve done a number of projects recently, where we have used the ADX transforms as the basis of our conversion to ACES/ACEScg.
We’ve never had a properly scanned ADX calibrated starting point, so have had to adjust the incoming densities usually by utilising the Status-M->ADX matrices.
On the topic of the channel gains - just don’t use 95 across when you scan base - use a stock specific R,G,B triple and you don’t need a LAD patch to balance against.
Essentially compute the base values assuming you did have a correctly exposed LAD - now of course you might need a very good estimate for how much above base LAD will be on each stock, but that process was the approach Cinesite London used for most of the time I was there.
As to issues with using ADX, I think the main issues have been with conversion to and from ACEScg.
One example is with the assumed encoding primaries for the in the ADX matrices not quite fitting (neither is a sub-set of the other). As such we’ve employed a modified set of assumed primaries that gives us less of a gamut miss-match.
A very minor modification could be made for instance in the green and blue to eliminate some of the miss-match, though I haven’t yet worked out the colourimetric error caused by doing so, visually I’m assuming it is way under the random lab/stock/lighting variations typically found in a film pieline. It does reduce the chance of generating out of ACEScg gamut values when originating on film.
I’ve also experimented with more extreme adjustments:
When needed to bring in extra colours when originating CG in ACEScg to avoid loss of texture caused by clamping/negative handling of yellowish fur. Obviously a more involved gamut remap could be used but by doing this redefinition of the colour space, it fit more nicely in the OCIO/VFX lighting and compositing pipeline, where it is not uncommon to transform back and forth.
Going back to the balance/base issue the toe portion of the linearisation is important to get right too as grain variation can be lost again due to clamping, this is not a new issue and is why I’d never recommend anybody use a hard limit at ‘95’ in any of the LUTs or Log<->Lin conversions.