View Full Version : Detail in FL lost unless hardcopy saved with gain down
Stephen Armour February 25th, 2011, 12:04 PM Any suggestions as to if we're doing something wrong here?
We often have 80-100 clips open in FL and grade them before doing our post and VFX work. One thing we've noticed, is that unless we first pull the gain down to recover lost data in blown out areas, then render a copy in AE, we'll lose that data if applying the LUTs in FL first for colorgrading.
We are working with Cineformed (NEO 4K) EX1R files and I am attaching 4 png's to show what's happening:
"No Look- Not Blown Out.png" is just using the primary color correction and white balance controls, no LUTs used.
"Look Generated then Applied- Blown Out.png" - a LUT file is created from those settings, then applied to the reset image, with no color correction or white balance applied. It's all blown out and the data is non-recoverable.
"Gain and Contrast Reduced- Still Blown out.png" is to just show that you can't recover that data from the above scenerio.
"Look Applied to Rendered Footage (gain reduced)- Not Blown Out.png" shows the difference between first rendering the image with the gain reduced, then applying the LUT in FL. What a difference!
How can we avoid this "having to render video" step with FL and with LUTs? Is there any way, without having to adjust each and every clip and without having to "copy/paste" from some other clip?
The LUTs seem to kill any gain settings we save!
Stephen Armour February 25th, 2011, 12:32 PM removed to re-post separately
David Newman February 25th, 2011, 12:33 PM I'm not experiencing that. My LUT export matches my Primaries/WB precisely.
Why are are using LUTs in this way?
If you WB and correct first (as you should), why can't these controls remain as primary settings?
Stephen Armour February 25th, 2011, 12:47 PM I'm not experiencing that. My LUT export matches my Primaries/WB precisely.
Why are are using LUTs in this way?
If you WB and correct first (as you should), why can't these controls remain as primary settings?
Apparently we are misunderstanding your workflow, then. We do set the WB and gain first, but if a LUT is then applied to match color with previous footage, the white areas are then blown out by the applied LUT. It does not seem to matter what the gain setting were when that LUT was exported. Even one exported with a lower gain setting does not keep the data from being lost in the highs.
The reason we included the same footage in various ways, was to show you clearly the issues. We are not making a LUT for each clip, if that is what you mean. Please look at the highs in clip #2 and #4 for examples.
David Newman February 25th, 2011, 01:04 PM It is not doing that here. The LUT export matches the primaries correction, can you get that?
Stephen Armour February 25th, 2011, 01:25 PM It is not doing that here. The LUT export matches the primaries correction, can you get that?
No, that's why we sent you the screenshots. You should be able to see that clearly from the settings. Reference the last image. We applied a LUT (exported with the gain down, see 1st image and gain settings) to the original image. But when applied (see last image), the image is blown out and the detail in the highs is gone, gone, gone. The whole process is very clear in the 4 images, which show their settings
David Newman February 25th, 2011, 02:34 PM Yes, I repeat your workflow and all is working fine. I expect your LUT is simply bad. I have noticed that export doesn't always output (no LUT produced), so if you are reusing a older LUT name you may simply have stale data. Also remember to double click on the exported LUT to register it with FirstLight. It stilll don't fully understand why you are using the LUT export for something the primares do very well, but the above is working.
Stephen Armour February 26th, 2011, 08:19 AM Yes, I repeat your workflow and all is working fine. I expect your LUT is simply bad. I have noticed that export doesn't always output (no LUT produced), so if you are reusing a older LUT name you may simply have stale data. Also remember to double click on the exported LUT to register it with FirstLight. It stilll don't fully understand why you are using the LUT export for something the primares do very well, but the above is working.
The LUT is not bad, it exported correctly and we did double click on it to register it with FL. We are quite confused about your last statement. Just what are you saying? Let me lay out our workflow and see if what we are doing is somehow looking at things incorrectly, or if we are not communicating correctly:
1. Convert all EX1R clips to CF
2. Import those 80-100 CF clips into FL
3. Correct one clip using WB and primaries (determine the color scheme for the clips)
4. Export a .look file
5. Double click on the outputted .look file to register
6. Apply the saved .look to other clips, making individual adjustments to each clip
7. Edit those clips in Premiere or AE (fine tuning clips in FL if needed)
8. Output the final comp or timeline
So what are you trying to say when you say: "...I still don't fully understand why you are using the LUT export for something the primares do very well, but the above is working."
Please explain. Why would we NOT want to "use the LUTs"? Should we be using "Snapshots" for that instead, and if so, why? Obviously we're not understanding something about LUTs/Snapshots here, so please enlighten us. We understand LUTs are much more complicated, but apparently are not understanding something about the difference between them and Snapshots.
Stephen Armour February 26th, 2011, 08:51 AM Guess our colorizer needs to actually read the FL manual...
Gary Brun February 26th, 2011, 09:28 AM Did he read it Stephen?
What was the solution to this problem?
¨g
David Newman February 26th, 2011, 11:22 AM You workflow is little strange, while it can work fine, you are having a problem which might be related to what you don't understand but LUTs. LUTs can model colour correction, but they are only an approximation. While all the sliders control parameters in algorithms, LUTs only store the results of those algorithms. Now for the complex part, our LUTs are very flexible and support floating point outputs for preserving supers (most LUT formats do not.) However, LUTs are a table (as in Look Up Table) and they always have limited inputs. A LUT can only describe 0 to 1 with a finite number of steps (64x64x64 in our case -- pretty awesome LUT size.) If you inputs exceed 1, they have to be clipped by the LUT. So you can take a clip that has value above 1.0, you can't expect a LUT to restore it. Sources from a camera sensor are always limited to 0 to 1 (not talking supers in YUV here) so there is no issue if you are only applying a LUT with no other corrections, a LUT is a good model in this case. In you are decreasing inputs, you are also fine. If you are increasing you data range before going into a LUT, any values exceeding 1.0 will be clipped by the LUT. There are solutions to this, by using a workspace curve which doesn't have black at 0 and white at 1, a Cineon 685 has black at 0.09 and white at 0.67, with a heavy log curve. This is a correct uses for LUT, moving an image from the workspace curve to your output/preview curve.
But why use a LUT? The colour correction algorithms do not have a input limitation, negative black to whites many stops over clipping are fully preserved. Just cut and paste settings from one clip to hundreds of clips, or use snapshot (it is a cut and paste to a file on disk), but they store parameters that drive the algorithms not tables of results.
Stephen Armour February 26th, 2011, 02:50 PM Did he read it Stephen?
What was the solution to this problem?
¨g
Getting ready for an overnite shoot in the mountains, so our color man is packing equipment to leave at 3am. We'll keep our testing going on Monday and see if we can figure things out more carefully.
Thanks David, for the additional info, The strange thing is that we only pulled DOWN gain, never up, which makes it hard to understand what's actually happening with the clipping.
We'll mess with the workspace curves and Snapshots and see if we can keep from needing that extra render step. It really negates time gains from using FL, so we've got to find a solution.
|
|