FS7: New Version Of LUTCalc - White Balance Improvements

C

cameramanben

Well-known member
Hi All,

I've just uploaded a new version of LUTCalc. I've been working the code of the colour temperature shift and fluori adjustments and have significantly overhauled things. I've also changed the preview window so that the LUT output options and 'Generate LUT' button stay visible - I've had a couple of people incorrectly try to save LUTs from the LUTAnalyst tool.

Links:
LUTCalc Main Page (includes LUTCalc For Mac zip files)
LUTCalc For Mac GitHub Page

In terms of use, I've combined the two adjustments under 'white balance'. The hue of the green / magenta shift by default is determined by the shifted colour temperature, but there is a button marked 'Unlock Lightsource From New White' which allows you to set the lamp's colour temperature separately, eg if you are building a look for mixed lighting but want to tweak a green-spike light. The green / magenta adjustment now properly changes with lamp nominal temperature.

I noticed that from early development I had been setting CTO / CTB adjustments according to some actual lighting gel values which I had curve fitted to. I've now changed it over to proper, simpler, more accurate mired shifting, scaled to keep the sliders as familiar CTO / CTB. On the back end, I've improved and corrected how these values are then applied.

Finally, I've added a 10-bit RGB code value display to the preview window. It's just above and gives the values after processing of the point under the cursor crosshairs. This is probably most useful with the LUTCalc For Mac version which can load images at 16-bit.

I have a couple more things I want to add once they work properly, and I haven't yet updated the instructions with these new bits.

As ever, let me know what you think, in particular whether I've made things more straightforward or confusing. Thanks,

Ben
 
Last edited:
That's so great that you keep updating the software. I really need to find the time to learn how to use it - it sounds like it's extremely useful.
 
Ben! Just wanted to say thank you for providing us with this incredible tool. It's breathing new life into my base 'looks' for my F3. Testing continues! Cheers!
 
I noticed that whenever I use one of the LUTs I created in LUTcalc, adjustments to the color, exposure and other settings in Premiere are delayed a couple of seconds. When I use the LUTs that are included in Premiere, adjustments are realtime.
I did a little investigation and found that the LUTs in Premiere are between 26K and 385K bytes, and the LUTs created in LUTCalc are over 7,242 kbytes.
Perhaps I'm using incorrect settings in LUTcalc?
The tool is very useful otherwise.


BTW, the R16 version has a bug> the native ISO is stuck at 1250 for all cameras.
 
basspig said:
I noticed that whenever I use one of the LUTs I created in LUTcalc, adjustments to the color, exposure and other settings in Premiere are delayed a couple of seconds. When I use the LUTs that are included in Premiere, adjustments are realtime.
I did a little investigation and found that the LUTs in Premiere are between 26K and 385K bytes, and the LUTs created in LUTCalc are over 7,242 kbytes.
Perhaps I'm using incorrect settings in LUTcalc?
The tool is very useful otherwise.


BTW, the R16 version has a bug> the native ISO is stuck at 1250 for all cameras.
Click to expand...


I believe you were using 64x64x64 LUT size from LUTCalc? it takes longer to interpolate, usually premiere has 33x33x33 LUTs built in.
 
Many, MANY thanks Ben! This is truly AMAZING tool!


If I would be a dreamer I would dream of those things in LUTCalc ;)

Realistic ones:
- some sort of saving current state functionality (or profiles!) so whenever I open this essential tool everything stays as the last time I was using it. Or default settings so I could setup FS7 as default camera.

Slightly unrealistic ones ;)
- plugin, live version of LUTCalc for PP, so I would not even need to get out of it to adjust LUT ;)
 
marvinhello said:
I believe you were using 64x64x64 LUT size from LUTCalc? it takes longer to interpolate, usually premiere has 33x33x33 LUTs built in.
Click to expand...


I studied the size of the files and it occured to me that perhaps I needed to use a Camera LUT rather than a Grading LUT. That reduced the size to about 900K (still 3X larger than the biggest of the Premiere-included LUTs), but response time is much better. Not as fast as the native LUTs, but workable now.

There are still many mysteries to uncover with LUTcalc. I was able to recover some highlight detail in a piece of footage that I could not 'fix' with any of the tools in Premiere. It was a matter of manipulating the curves in LUTcalc and using the resulting camera LUT.

Now I'm trying to figure out how to make a LUT that will have high saturation at highlight levels, for fireworks and laser light shows.
 
Hi All,

many thanks for the kind words. I've been away for a short holiday and promised my wife not to do anything with the computer, so only been back online a couple of days, but sorry for the slow reply.

I've actually just uploaded yet another version - v1.9RC17. A bit more tidying of the white balance code plus code which calculates the correlated colour temperature (CCT or nominal temperature). This has gone into an extra feature I'm testing out which when you have the preview window up is a button marked 'Preview Click For White'. When you click this you can take the cursor over the preview window, click on an area and LUTCalc will attempt to set the white balance to it, adjusting the CTO/CTB / Colour temperature and Plus / Minus Green controls.

I've also added an extra preview image - this is the full XYZ colour gamut expressed as CIE 1931 xy and CIE 1960 uv chromacity charts, with the Plack Locus (colour temperature line) also shown. I thought these might be handy for getting an idea of how much of the overall visible gamut an output look covers before colours become clipped, saturated blocks. I'm trying to figure out the best way (possible ways?) to overlay the output gamut triangles.

Lastly, I've shifted the preview images over from clicking one to the next to just selecting from a list. There are getting to be too many of them! This also means that you can now jump back and forth between one of the defaults and any image you want to load in.

alohype - I do intend to do the 'realistic' one - I quite agree it would be very useful and I have been gradually making the code more amenable to adding it, just not quite yet ;-)

As for the other one - LUTCalc is all Javascript and as cross-browser compatible as possible so limited in how quick it can be and in what hardware tricks it can hook into. The algorithms could be useful, but it would need a complete recode into a faster, lower level language and I'm afraid that's a bit more than I (or my wife's patience) would be up for. :-)

Basspig - I've tried out RC16 on my Mac with Safari, Chrome and Firefox, plus the Mac app version and then on Windows 8.1 under Parallels using Chrome and Firefox and I'm afraid I can't replicate the frozen ISO you've had. From the code I also can't find a reason it might happen. One thing that comes to mind might possibly be an earlier version scribbled up in the browser cache (its a fairly big set of files for a web page). Could you try clearing your cache, reloading LUTCalc and then see if that clears things up?

As for the LUT sizes - once a LUT has loaded into memory, the actual size of the mesh shouldn't have much consequence to post software. For a 1D LUT a single interpolation calculation is a matter of taking 2-4 values from an array (depending whether linear or cubic) and for a 3D LUT it's 8-64 values (trilinear through to tricubic). Those numbers are the same regardless of the overall mesh size of the LUT.

The amount of time to find those values shouldn't be significantly different for a 17x17x17 LUT or a 65x65x65 one. I have changed the Speedgrade option over to 16x16x16, 32x32x32 and 64x64x64 in RC17 as I get the suggestion from the Adobe cube spec that it might be tuned to even-dimensioned LUTs.

LUTs tend to be either text files or binary, and the text form (the more common and which .cube files are) may expect integers (eg .3dl) or floating point values (eg .cube). Integer-based text LUTs may end up a bit smaller, but tend to be less fine-grained, and floating point ones can be significantly effected in size by the number of decimal points included. Binary formats can be much more compact, but then tend to be much less open and portable.

a 26KB LUT will almost certainly be a 1D LUT, with 385KB almost certainly a 3D one. If you look at Sony's Look Profile LUTs, they are 33x33x33 with values to six decimal places and come in around 1MB. 65x65x65 may be overkill for simple adjustments, but for a post LUT will maintain much more of the detail in subtle adjustments, at the expense of being around 7 1/2 times the size of a 33x33x33 LUT. As I say though, once it is loaded into post software, there shouldn't really be a slowdown in interpolation for different 3D LUT sizes.

With respect to Premiere, are you talking about built in LUTs or built in looks? Lumetri looks are not necessarily just straight LUTs. If so, I wonder if things are correctly set for handing off LUT processing to the graphics card? I know that on the mercury side, it is possible for it to slip over to software rendering without noticing (at least I managed it once :-) ) which dumps everything onto the CPU. I'm not on a Windows PC, but I haven't had trouble using LUTs through the Lumetri plugin in Premiere CC on my MacBook - at least with HD.

Ben
 
Last edited:
cameramanben said:
This has gone into an extra feature I'm testing out which when you have the preview window up is a button marked 'Preview Click For White'. When you click this you can take the cursor over the preview window, click on an area and LUTCalc will attempt to set the white balance to it, adjusting the CTO/CTB / Colour temperature and Plus / Minus Green controls.
Ben
Click to expand...
Ben , Is this something that one could use to create a LUT to deal with fluorescents? Would the process be :
- shoot a brief test with your camera in Log
-. download the file ,
- make a freeze frame
-plug freeze frame into LUTCalc & perform a white balance.
- Make a LUT based on the CTO and green magenta indicated by the white balance.
- Enter that LUT into camera?

Lenny
 
Ben, the new version works properly as far as the ISO changes go. It did take about 3-1/2 minutes for the logo/splash screen to disappear and for the program to become operational though.

As for the LUTs in Premiere, I'm talking about the input LUTs under Basic correction. The included LUTs there, when loaded, don't have a slowdown effect (that I can detect) when making any adjustments to the exposure, white balance, highlight levels, etc. But when I load in a LUT that I created in LUTcalc, there is a noticeable delay when any parameter like the afore-mentioned is adjusted. The longer the adjustment layer (and the more clips underneath it) the longer this delay. For an 8 minute timeline with about 20 clips, this delay can be more than 30 seconds before the screen updates with the change in color/luminance. Applied to a single clip, this delay is not long enough to be bothersome, but on the adjustment layer, applied to multiple clips, it's lengthy. Probably more of an Adobe problem than a LUT problem, but presented for informational purposes.

Thank you for explaining how the LUTs are constructed and how they interact with the application. And thank you for making this powerful tool available.
 
basspig said:
Ben, the new version works properly as far as the ISO changes go. It did take about 3-1/2 minutes for the logo/splash screen to disappear and for the program to become operational though.

As for the LUTs in Premiere, I'm talking about the input LUTs under Basic correction. The included LUTs there, when loaded, don't have a slowdown effect (that I can detect) when making any adjustments to the exposure, white balance, highlight levels, etc. But when I load in a LUT that I created in LUTcalc, there is a noticeable delay when any parameter like the afore-mentioned is adjusted. The longer the adjustment layer (and the more clips underneath it) the longer this delay. For an 8 minute timeline with about 20 clips, this delay can be more than 30 seconds before the screen updates with the change in color/luminance. Applied to a single clip, this delay is not long enough to be bothersome, but on the adjustment layer, applied to multiple clips, it's lengthy. Probably more of an Adobe problem than a LUT problem, but presented for informational purposes.

Thank you for explaining how the LUTs are constructed and how they interact with the application. And thank you for making this powerful tool available.
Click to expand...

Didn't your machine have general problems with performance, especially in Premiere?
 
Different machine. I'm using LUTcalc on an internet connected machine, not my income earning machine which can't access this software due to not having any browser or an internet connection.
 
You must log in or register to reply here.
Back
Top