Other: Important LUTCalc Update

C

cameramanben

Well-known member
Hi All,

I've just uploaded a new version of LUTCalc (v1.9RC11). There is one big change under the hood which should barely be apparent to a user, and one of my annoying little (but important) bugs fixed.

Links:
LUTCalc main page (with web app version)

LUTCalc For Mac releases page on GitHub



First the good. I have overhauled the maths behind the colourspace (gamut) side of things, to be more robust and flexible. As a consequence, I have simplified the Fluorescent control.

Previously, it would include a colour temperature adjustment to compensate for a fluori's temperature, so could be magenta to green or yellow to cyan. I now realise that it is better to keep the colour temperature and the magenta / green adjustment totally separate. For normal use, I would suggest just using the slider in conjuntion with correcting for a fluori's nominal temperature with the colour temperature control.

I have left the bulb temperature settings under 'advanced' and added a camera white balance option to better calculate the hue of green or magenta, but the variation now is very subtle, so as I say, the slider alone is the best bet, as with most grading software.

The colour stuff is a fairly substantial change; I haven't yet seen any breakages, but they may well be there so please do keep me posted if you find anything behaving strangely. I have also left the previous release up on the GitHub LUTCalc For Mac page.


Now the bug. Changing to a non-log output gamma should change the output range to 'legal' for some formats (notably Davinci Resolve). The last version let in a bug which meant that this wasn't being checked for. Sony MLUT (which fixes to legal out for all gammas) and Speedgrade (which wants data in to data out) would be fine, but the result for a Resolve LUT (unless you manually changed output range to legal for non-log gammas) would be noticably higher blacks on the waveform. Personally I have been using it for MLUTs so managed to miss this until now.


If anyone has wondered about this, sorry!

** A bit more detail (if you want it! :-) ):

Previously, I have used a colourspace shortcut of manufacturer's published matrices between gamuts, and then calculated the passage to a consistent working colour space. Now, I have written up a system which calculates all these matrices (as the manufacturer has done) at startup from chromacities and white points. The funny thing is that all going well, the results should be identical to before.
The main reasons for doing this have been to tech me more about the mathematics of colour, and to make it easier to add gamuts. I have added DCI-P3 variants and Adobe RGB and Wide Gamut RGB. **


Ben
 
I'm having a hard time understanding all these different gamma curves and standards.

I assume that if I'm shooting S-Log 3, then I would "Recorded gamma" to that, and "output gamma" to what look I want, such as LC709A. With the earlier version of LUTCalc, I was getting some interesting results, but not quite right. With this new version, when I load the LUT, the image turns black, with some edges dimly glowing. Also noticed the 65 cube doesn't generate a file--not sure if that's by design or a bug. I used the 33 cube.

Life was so much simpler in the REC709 world! But if one can master the art of the LUT, it makes shooting one of the S-Log flavors more rewarding. Till now, I have been using luma curves to hand grade my S-Log footage, with varying degrees of success. I was hoping a grading LUT would eliminate the guesswork and give me what the camera saw, properly translated to the NLE workspace. Maybe I misunderstand the use and purpose of LUTs?
 
Hi basspig,

I'm very sorry to hear all that. You are right about 'Recorded gamma' - that should be the gamma you shot with and 'Output gamma' is the one you want to generate. I've just tried out the online version, and all three of the LUTCalc For Mac versions built for OSX and I can't seem to replicate what you describe. Setting 'S-Log3' and 'S-Gamut3.cine' in the 'recorded gamma' and 'recorded gamut' boxes and 'LC709A' in both the 'Output Gamma' and 'Output Gamut' boxes in the second window down on the left, then clicking the 'Generate LUT' button (next to the 'preview' button and when the preview is not being displayed) is for me generating LUTs identical to the original Sony LC709 Type A look LUT. I can also change to 17x17x17 or 65x65x65 in the box on the top left and still generate LUTs to the appropriate size.

Another thing I was wondering: when you say you 'load the LUT', do you mean into the LUTAnalyst tool (the box on the bottom left, which starts off showing 'Import New LUT' and 'Load Existing Analysed LA LUT')? If so, that will change to offer a bunch of options including 'Analysis Dimension' followed by 33x33x33 or 65x65x65. This is for reading in LUTs constructed elsewhere, not for generating them. I mention this because someone else wrote to me mixed up by that, and if so again I'll have to think about making it clearer.
If you are using it as an MLUT in the camera, make sure to click 'Camera LUT (MLUT)' in the box on the right, as this will make sure that values are clipped to a range that the camera accepts. LC709A shouldn't actually be an issue either way, but just in case.

I'm going to keep trying to see what you are seeing, and in that mind could you tell me what software you are using for grading, and if possible send me a framegrab of LUTCalc as it is set up when you click the 'Generate LUT' button. Thanks and, again, sorry,

Ben
 
Thank you for following up. I think I was doing something wrong initially. For some reason, only the 33x dimension was working when I pressed Generate LUT. But later on, I found I was able to get a 65x LUT to generate, using the Lumetri LUT selection. I think this works like Convulution Kernals, in that one wrong number inverts all the luma values. So probably the 33x sized LUT was invalid for the NLE. After much playing around with the calculator, I finally got some LUTs that produced close to neutral looking pictures.

One thing I've been trying to figure out is how to deal with wide gamut color from the non-Cine S-Log 3 setting on my FS7. Greens are shifted to cyan and pinks are shifted to fuscia. For now, I'm avoiding the issue by shooting S-Log 2.

I wasn't using the LUT analyzing feature, as I didn't have a LUT to begin with. Just want to create LUTs that will enable me to have a proper starting point with footage I import from the FS7. I will try making some MLUTs for use in my Atomos Shogun too, as I am having a discrepency between the FS7 VF and the Shogun's display of the images. Using some 3rd party MLUTs now, but they aren't 'on the money' with correct gamma and color.

In closing, I don't think there was anything wrong with the software; rather, it was probably operator error, or perhaps browser corruption. One of the things I did was re-launch the LUTCalc app, so it's possible that it wasn't properly loaded the first time I tried the new version.
 
Ben,
I reported this on the Sony Community forum but haven't seen any response. For me importing the Maverick's version of your latest LUTCalc for Mac just didn't work the entire "advanced section on the left just doesn't come up at all and the boxes for recorded and output gamut don't work at all.
I tried downloading it twice . Am I the only person having this problem? Previous build of LUTCalc works fine. Now I didn't trash the older version if that might have anything to do with it.
 
Hi Lenny,

I've just been away on a shoot, so sorry for the slow reply. I haven't managed to repeat your issue, but being based on Javascript, it sounds like something is not ready when asked for, crashing everything after it. Further to the Art Adams article you mentioned on the Sony forum, I've actually been emailling him and he had an issue of the preview sometimes freezing. I haven't yet repeated that either, but could see a possible way the issues could be linked. Previously, I had preview default images loaded as needed, but I have now changed things so that they are all loaded at startup and that the splash screen won't disappear until they are all loaded. Makes startup a little longer for the online web app version, but should make things generally smoother and fingers crossed help with your issue.

Links:
LUTCalc web page
LUTCalc For Mac GitHub Releases Page

If it isn't fixed, could you let me know you version of Safari and maybe go to the online version? The other most likely culprit is that I've added some bit of Javascript which older versions of Safari don't understand. Whilst my Mac is Yosemite, I've deliberately tried to keep things compatible back to Mountain Lion, and at the moment I can't find anything that should trouble Mavericks.

One bug I did find is that with the simplified choice between 'grading LUT' and 'MLUT' in the output box, the Sony MLUT option wasn't setting the correct clipping levels. What that means is that the LUT could feed values outside of 0-1023 to the camera. They appear to be ignored, but I have fixed this and I'd suggest rebuilding any MLUTs which might exceed extended range.

Lastly, a very small good thing that I've added is a toggle at the top of the Preview window to switch between displaying the legal range (default) and scaling the preview to show the whole of data range. This was a suggestion from Art Adams, so that even if you are going to end up hard clipping legal you can still get an idea of what the whole range looks like,

basspig - I still can't repeat your issue either; are you on Mavericks too? What browser / version are you running? Something that may be causeing the issue with your Shogun is that some applications / hardware expect LUTs to be fed data range (full swing / extended range) and to spit out legal range - eg DaVinci Resolve, the camera's own MLUTs, whereas others expect data in to data out. Lumetri seems to be one of the latter, so that could cause a discrepancy between how things appear in Premiere / Speedgrade and in the Shogun fed from the camera. LUTCalc should feed the right levels, but if it is not working for you anyway...

When you say 'non-Cine S-Log3' do you mean S-Gamut3 against S-Gamut3.cine or shooting S-Log3 in custom mode rather than CineEI?

Ben
 
Hi Ben,

I PM'd you but thought I'd post here as well incase it helps anyone else.

With your LUT calc is it possible to remove a LUT that was accidentally baked in onto slog3/sgamut3.cine? So for example I have a few clips where the b-cam op enabled the MLUT for int. during S&Q using the 709(800) LUT so the client could visualize the color, etc.. but of course that ended up baking it into the internal recording.

I'm not expecting it to technically "reverse" or "undo" it like it never happened of course, but if I can get these clips back to what they would have looked like without the LUT baked in then I can apply some of the grades/looks currently in development to these clips and get a better approximation of what they "should" look like and what to work towards.

Thankfully only a few clips got baked before I noticed it!
 
Last edited:
A little flurry of bugfixes today, and suddenly I'm up to RC14! Mind you, things hopefully are settling down now (the one that has possibly been causing the most trouble is with the 'highlight gamut' option, which was just obscure enough for me to miss until someone suffering freezes mentioned playing with it.

Anyway, all versions updated now. It might be worth clearing your download webcache if you still have odd things happening.

Links as ever:
LUTCalc web page
LUTCalc For Mac GitHub releases page

As for starcentral's problem, I caught the discussion over on the Sony forum. Here were the (1D) LUTs to try:
Rec709(800%) to S-Log2 or S-Log3 (data in to data out)

Anyway, as ever feedback gratefully received!

Ben
 
In bringing the 709 backdown to log , it wouldn't be the same as having shot log in the first place would it ?
Wouldn't you lose some of your ability to color correct?

Lutcalc opens Up interesting possibilities for matching dissimilar cameras . I shot with FS7 and aC300 and was able turn SLog3 into C-log . Never saw the match unfortunately .
 
cameramanben said:
basspig - I still can't repeat your issue either; are you on Mavericks too? What browser / version are you running? Something that may be causeing the issue with your Shogun is that some applications / hardware expect LUTs to be fed data range (full swing / extended range) and to spit out legal range - eg DaVinci Resolve, the camera's own MLUTs, whereas others expect data in to data out. Lumetri seems to be one of the latter, so that could cause a discrepancy between how things appear in Premiere / Speedgrade and in the Shogun fed from the camera. LUTCalc should feed the right levels, but if it is not working for you anyway...

When you say 'non-Cine S-Log3' do you mean S-Gamut3 against S-Gamut3.cine or shooting S-Log3 in custom mode rather than CineEI?

Ben
Click to expand...


No, I'm on Windows 7 64-bit. Chrome browser.
I've gotten it to work fairly well, but there are instances where I get results that are a bit off from the expected. For instance, FS7 S-Log 2 to LC709A, stop correction set -1 or -2 to compensate for a 'hot' image doesn't recover the highlights, but causes the black level to rise and become a murky brown/grey over the LUT without stop correction.

Yes, I was referring to S-gamut3, as opposed to S-gamut3.cine. The first one produces some very peculiar color shifts, like "XV color" did on a consumer Sony camcorder a couple years back when I tried it. The second one keeps the color fidelity pretty well.

I'm thinking about experimenting with 1D LUTs, as they're supposed to just deal with luma gamma. But the S-gamut3 is a mystery as to how to translate that to REC709 space. Possible uses for laser light shows and fireworks, but for now, I relegated it to back burner until I can do more research on how to properly use it.

The real questions are why is it that I can't recover highlights with the LUTs, but I can with manual grading using luma curve and ProcAmp? I often can achieve a cleaner grade without using LUTs at all. I thought that the idea of a LUT was to make S-Log ready for edit and color grading, being the end of the closed loop system of dynamic compansion. Perhaps I'm missing something here, as it's new to me in a visual perspective, though an old concept in the audio world (dbx/Dolby).
 
basspig said:
The real questions are why is it that I can't recover highlights with the LUTs, but I can with manual grading using luma curve and ProcAmp? I often can achieve a cleaner grade without using LUTs at all. I thought that the idea of a LUT was to make S-Log ready for edit and color grading, being the end of the closed loop system of dynamic compansion. Perhaps I'm missing something here, as it's new to me in a visual perspective, though an old concept in the audio world (dbx/Dolby).
Click to expand...

I'm not nearly as accomplished as Ben, but, I'm gonna take a stab at the answer. In some metaphorical sense, the 2-D nature of audio data(amplitude and frequency) is easily visualized, both in my understanding of it and in the algorithms used to process it. Video data is an order of magnitude more complex, in a 3-D space of color, saturation, and brightness. In essence, the detail distilled out of the highs during the debayer process is greatly dependent on the slope of the gamma conversion in 3-D space. In slog space the slope of the gamma curve is so shallow as to make subtle changes in luma and color very difficult to see on an 8-bit monitor. So, the first factor is what monitor are you viewing things on? If it's only 8-bit, it won't reveal a lot of what's happening with 10-bit files. So, the other thought of mine is that a great deal of the highlight detail is brought out by the slope of the gamma curve. One man's knee is another man's poison. And just exactly how is the data being handled, internally, pre, or post transform. It IS about the process, and not the final result.

Guess my answer may be more esoteric than a good technical explanation from Ben, but, I htought I'd reply. Hope it helps, some.
 
Last edited:
You must log in or register to reply here.
Back
Top