Why your own?
A copy for Filmulator so that it can know these sorts of things.
Maybe we can share it via librtprocess in future? Just a thought…
I’d rather have a library separate from librtprocess to hold camera-specific data.
librtdata for data, librtprocess for algorithms?
2 Likes
Sounds good to me 
For me, the key point is to avoid collecting this kind of data in different places. We should try to find one central place for this data which is accepted by all applications which use the data, even if getting the acceptence can be hard…
4 Likes
So in there we need the data itself and probably some basic methods for accessing it on a per-camera and per-image basis.
In my opinion, to get acceptence for RT and dt we need to make a superset of the features supported by RT and dt. For example RT supports white-level scaling based on aperture, while dt does not support that. On the other side, iirc dt supports some denoise parameters based on camera and ISO which is not supported by RT. A Database has to support all this values even if an application does not use all of them.
5 Likes
Yay!! Get Lensfun profiles in there and it’ll be dope!!
(Am I saying that right?..)
Actually yes. 
1 Like
Maybe also RT camera/lens/aperture dependent capture sharpening settings…
We’re going more and more off topic. Should we create a new issue or continue the discussion in this issue? I would prefer the latter.
Discussion here is fine. The general camera info is more important than just the white point.
2 Likes
I prefer knowing the right value. For example RT capture sharpening does not sharpen the pixels close to a clipped highlight, because the data used to apply the deconvolution is not linear if there is a clipped highlight close to a pixel. To do that, knowing the correct white level is important.
2 Likes
Oooh, learning… my thought with doing that was to just go to the top of the data in one operation, instead of setting the white point then applying exposure comp to scale the data to white. Does highlight reconstruction have a similar consideration?
I do have another mode to apply the metadata values, but I need to consider alternatively looking them up in camconst.json
Highlight reconstruction wants cleanly clipped pixels, no clipped data hanging out below the white point.
I haven’t tried looking in the camconst.json for the D800 to see if it has per-channel white clipping points…
I noticed similar weird behavior of multiple apparent ‘clipping points’ in the bmpcc original raw files, as I described and documented with tests here about a year ago.
I’m encountering this issue again, having made no progress since it last came up, and I think what we need is a) a database with a superset of the data the different editors want, and b) scripts that autogenerate the desired files for each existing editor.