Hi, I work in film post and I’m interested to try out vkdt for some personal projects in order to get more raw development flexibility compared to Davinci Resolve. And being a Nuke user, I like the look of the node view!
A question and a few notes:
Is installation on CentOS 7.9 possible via the Fedora rpm packages on the OpenSuse build system page?
I assume “cinema” DNG is not a problem, since basically it’s just a DNG image sequence.
After developing and processing, it looks like I would want to output 32-bit pfm files and then convert to either openexr or log dpx with oiiotool to get into Nuke or Resolve.
I have spectral sensitivity data for a camera I own that records Cinema DNG. After some reformatting of the data to 380…780nm in 5nm intervals, I tested it out with rawtoaces and it seemed to work. Given that rawtoaces is kind of dead right now - but is namechecked in the vkdt docs - I’m interested to try this out.
sounds like a good use case! could probably use some speedup and the power of custom code in a comp/post pipeline. let me try to answer a few things:
sorry no idea about centos, fedora, or rpm can assist setting up build from source. vkdt doesn’t have a ton of complicated dependencies, so i’m guessing the rpm should transfer over fine.
if you have an example DNG sequence i can look into streamlining workflows here. for timelapses, you’d have %04d kinda sequences in the file name (e.g. IMG_0001.DNG…IMG_0301.DNG). since it’s a security issue to use printf style filenames from users directly maybe i should implement rv style filenames with @ in them too (also searching for 00000 and more digits).
right. for an external workflow 32-bit pfm is safe because it certainly doesn’t lose information (they have no metadata but will be linear rec2020). i know this can be quite a harddisk burden though. you can export to h264 directly via the o-ffmpeg module (select during export or on cli commandline), but if you have reasonable specific needs it’s not a lot of work to write specialised output modules (let me know).
yay spectral input! the starting point for the vkdt mkclut docs is here, let me know how this goes! if you already have the rawtoaces style data in a text file, it should be straight forward to generate input device transforms for vkdt. also note that vkdt will create a dual illuminant, full spectral locus lut, not a simple matrix derived from spectral data. this should perform much better for extreme chroma.
Thanks for your reply! Building/installing would probably be my biggest pain point because I’m not a developer, but I can probably figure it out with some hand-holding. I have used “make” before
If building from source, is it a stretch to get it running on OS X?
Re: sequence numbering, yes exactly - a %04d type of thing is what I work with all the time. I can provide an image sequence if you want, but it sounds like you already have that functionality. The rv approach with @@@@ would work too.
Re: output format. I think that the ability to export Rec2020 linear floating point .pfm is a great start. I would only use h264 for proxies but would probably defer that to a later step if needed. The reason to use floating point export would be that I would add an exposure adjustment to set middle grey to 0.18 and that would push the max highlight value up to something like +6 or more stops over depending on the sensor, so I would say at minimum I would be storing highlight values of 11.52 (0.18*(2^6)) on a sunny day, before any highlight reconstruction. From there I would use OpenImageIO to convert to linear exr or log dpx.
If you were to consider adding output modules, have you looked into OpenColorIO/OpenImageIO? This would allow integrating ACES and popular log encoding, as well as film colour management (ACES, etc). But effectively, I think the only difference between a floating point .pfm and an ACES OpenEXR output by rawtoaces is that the .pfm gamut would be Rec2020 and the ACES would be AP0.
Just a note that I would be bypassing the .icc colour management.
Re: spectral input. Sounds great! After getting the software installed, this would be my base test. Import via the predefined text file and export to .pfm to see what I get! The formatting is meant to match those exact example rawtoaces idt’s that you mention.
Just wanted to add that I imagine the workflow with vkdt beyond using the spectral response for the idt and the .pfm export is like this demo of rawproc that I found on youtube. Except being able to do that in a node graph is right up my alley!
centos 7.9 is too old for any of the fedora packages. I am not even sure you could build vkdt on such an old distro. the raw library used by vkdt requires a pretty new C++ compiler. IIRC the vfx reference platform is in the progress of moving towards some RHEL 9 clone. ( I saw some video from the ASWF about this ). so that might give you a higher chance.
Thanks. Yes, I will move to Rocky Linux in the next year or so. I should get a machine up and running with Rocky on it, so I could install vkdt on that if it’s any easier. I can see things are beginning to finally shift now that Resolve 18.5 officially works with Rocky.
Just updating, I hope to get vkdt up and running via rpm on a spare machine with a new Rocky installation. I’ll check back in here to confirm, or if I need to go the compiling route and I run into any issues.
I’m glad to hear it works with Rocky officially. Can you point me to the link that says so? The current version I have (18.3??) hasn’t worked with Fedora since the upgrade to Fedora 28, due to a pango difference.
Actually I have no idea if it works with Rocky, but @darix pointed out that it’s unlikely that it would work with CentOS 7.9 which is my current production distro. I had hoped that I could install using rpm because the Rocky docs mention that. https://docs.rockylinux.org/books/admin_guide/13-softwares/
I’m sure you know all this, but it’s the same as with banks using old software. It’s stable and it runs in critical production situations. With the reference platform as a target then everyone ends up getting on board with it and it’s very slow to move forward. 7.9 came out in 2020 though so it’s not that old, but I assume you’re referring to older libraries within that release.
also the production environments i’ve seen are super heterogeneous… you’d load half a distro worth of specific libraries on a per-shot basis, to make sure the abi is right even for older versions of esoteric/custom/binary 3rd party software that happens to run a set of assets/has the temporarily added dirty fix to push out a trailer. at least that gives you a chance to revive stuff from 5 years ago. some companies are more conservative and fix software versions per show… which usually means you’ll work with old software for an even longer time.
i keep forgetting about rawspeed and dependencies. vkdt itself doesn’t really need much (you can compile without rawspeed, but then it’s not useful for raw development-- unless you have custom nodes to put raw into nuke and can repurpose that code for a vkdt input module). i suppose it’s possible to install a lot of new stuff even on an old base system (but why would you go through the pain for private use).
let me know if you dive into this. this dependency/c++ compiler version thing is ridiculous. i’d be happy to prepare a version that compiles on older systems. since you’d be using custom ssf profiles anyways i could hack a terrible system("dcraw -E [..]") kinda frankenstein to short-circuit some things. of course that only makes sense if you can use relatively recent graphics drivers. i currently depend on vulkan 1.2 (i think a version from 2020… 1.2.162 should be safe). if you can’t have that it’ll be a bit more work (would need to remove/compile guard the ray tracing part).
What fits my narrative is to try Rocky, so I’ll try that first. I don’t need to put vkdt on my production machine. Do you think that’s workable? I am using very recent graphics drivers regardless. That’s something Nuke and Resolve want.
I was able to get 18.1.3 working again by the following procedure (try this if you get a symbol not found error in libpango):
cd /opt/resolve/libs
cp /usr/lib64/libglib-2* .
Then I upgraded to 18.1.4, and had to repeat the same procedure to get that to work. Rocky may not be so near the bleeding edge as Fedora, so you may not need to do this.
can assist setting up build from source. vkdt doesn’t have a ton of complicated dependencies, so i’m guessing the rpm should transfer over fine.
