It’s actually fine for such a thing.
The issue with combining live action footage has very little to do with a specific camera rendering transform. It has everything to do with how the footage is encoded.
If you have a deep enough encoding and know the transfer function, you can indeed invert back to scene values. The problem is that most consumer cameras don’t provide this sort of a transfer function to get back to scene reflectance.
Fuji’s X-T3, Panasonic’s G series, some of Sony’s A series (albeit at 8 bit), and now Nikons can all output a video encoding that is based on a scene referred log encoding. This is crucial to be able to go from the normalized camera referred encoding back to scene reflectance and emission. If you have a generic DSLR that plops out a “ready to view” video encoding, you won’t be going back to scene emission / reflectance easily, although it is theoretically possible to come up with a reasonable approximation.
Backwards! You want to take the camera footage into a set of reflectance / emission ratios in your CGI.
The IDTs in ACES do exactly what I suggested above.
The main showstopper for ACES is that there is no gamut mapping and as a result, the imagery it produces is rather nasty. Even basic FIlmic has a gamut mapping.
Not always from the vendor. The IDT however, is exactly how you take the camera data to your rendering working space. Note that you won’t find any consumer DSLRs in that list for the above reasons.
Except you don’t work in ACES AP0. You work in AP1, which is more or less BT.2020. It’s not magic.
All rendering working spaces must work in a radiometrically-like linear working space. Of course, RGB is inherently limited, but even Cycles works under an RGB radiometrically-like working rendering space.
All nonlinear encodings, when using values as-is, will result in nasty looking problems if you perform any sort of manipulations under them. This is why radiometrically linear is an absolute must for all manipulations. This is a UI problem, not an encoding problem. Sadly, folks carry on doing manipulations using the nonlinear encodings before decoding them back to radiometrically linear for manipulation.
Resolve still is totally broken for ACES use, as it uses ACEScc as the working reference space, which is nonlinear and problematic.
Hope this helps. It’s sure nice seeing these sorts of posts in the forum.