BSC Film and Digital Image Evaluation 2009

[Evangelos Achillopoulos]

DI software performs realtime conversion from linear high bit depth working space of the project to ICC profile of my monitor, which generally is far wider than just Rec709. Much what Sanjin posted with Arri. AfterFX does this natively, just turn color management on and be sure to understand, what to set where.

ICC is totally unappropriated for DI... For film we use the by far more accurate 3Dluts or Cubes... From that I understand how much involed you are with Film DI...

But scratch, baselight.. support r3d directly.

So in the Scratch converter you don't select Linear Light, REC709, RedLog etc...

Sanjin please, next time, put 38 points, bold and yellow flashing... because they didn't notice it... I'm getting tired...

 

[Gavin Greenwalt]

There were only two important points:

Lin Data route is strictly recommended if you want to finish with a "Video Look" in print to film or Digital Projection (DCI) either acquisition was on film or digital.

Log Data route is strictly recommended if you want to finish with a "Film Look" in print to film or Digital projection (DCI) either acquisition was on film or digital.

And they're both wrong.

What color definition you use for IO has NOTHING to do with the look of the output image.

It's as rediculous as saying "Only use Zip compression on your footage if you want it to look like video."

or that you need to grade in xyz color for a project you want to end up as a DCI.

 

[M Most]

It can't be stressed enough. The world is linear... The human eye is irrellevant....All digital or analog display hardware has a circuit which converts its "native" display type. Which is linear....Linear is the same across all displays. Anytime you SEE something you're looking at a linear display. Because reality is linear...

Gavin, you may be "that one guy," but it's clear from your comments that you haven't really spent much time in the real world of post production, digital intermediate, or real world deliverable formats. Or the world of color science. I respect what anyone has to say, but you really should stop trying to convince those of us who have spent years in this end of the business - and DO know about these things - that everything we know is wrong. I know you think "everything should be simple." Only it's not simple. If you want to believe that all of the complicated crap that goes on in your magic boxes - including the Red cameras - is simple, try building one. And if you want to believe that all of the steps we go through to maintain image integrity across completely different delivery mediums should be simple, you should try that too. The math and viewing requirements for compositing software has very little in common with the requirements of a digital to film interface, film recording, film color science, and multiple delivery systems. Instead of arguing with those who have spent many years understanding the concepts of modern color science, you might be better off learning more about it.

 

[Gavin Greenwalt]

I'm not saying the color science to do these conversions is simple. I'm saying the interface to these boxes should be just that. Effectively magic.

Are you disagreeing that a log image and a linear encoded image produce *different* results based on the file format? That's all I'm argueing against. File formats which generate confusion and unnecessary error. It doesn't take years in post production to understand that (x^2.2)^(1/2.2) = x. But that's not what everyone keeps saying. They insist that (x^2.2)^(1/2.2) = y. Which is demonstrably false.

I know nothing about the voltage requirements of the arrilaser and I should never in a million years need to know anything about it and yet just everyone knows about sRGB and indirectly about CRT voltages from 10years ago. All of which is now completely meaningless.

The user shouldn't need to understand any of it to deliver a consistent product. Just like even though I can write a 3D shader which takes global illumination and AO and reflectivity and BRDF illumination I shouldn't have to understand any of that. There is no reason the artist should have to be concerned with it. Data should be predictable.

 

[Sanjin Jukic]

There were only two important points:



And they're both wrong.

What color definition you use for IO has NOTHING to do with the look of the output image.

It's as rediculous as saying "Only use Zip compression on your footage if you want it to look like video."

or that you need to grade in xyz color for a project you want to end up as a DCI.

Gavin,

do you know better than ARRI engineers about Lin/Log use???

"In a linear workflow, when the original data came from a digital camera or a telecine, the postproduction will be done with linear data."*

Lin Data route is recommended if you want to finish with a "Video Look" in print to film or Digital Projection (DCI) either acquisition is done on film or digital.

"In a linear workflow, when the original data came from a digital camera or a telecine, the postproduction will be done with linear data."* From ARRICUBE for VIDEO Look>>find at above pictures>>>

Log Data route is recommended if you want to finish with a "Film Look" in print to film or Digital projection (DCI) either acquisition is done on film or digital.

"In case of the logarithmic workflow the incoming data will be logarithmic. The acquisition is done on film and the data are scanned with the ARRISCAN."** From ARRICUBE Preview LUTs>>Find at above pictures.

I just took out the word "strictly" that was maybe a bit heavy and added two ARRICUBE brochure quotes that directly talk about use of Lin and Log to make all now much cleaner.

 

[Gavin Greenwalt]

I'm not disagreeing with Arri. I think they're being misapplied in this situation or something to mistranslated somewhere.

My only assertion through all of this is that Lin and Log files are interchangeable but Lin is more consistent and therefore is the better option.

If Arri is saying that you'll get a "video look" from grading from lin source files and a "film look" from log source files then I would definitely give that pamphlet the benefit of the doubt and say it's poorly worded.

I'm not saying that dealing with gammut issues and saturation and all of the headache that goes along with multiple display types is an easy problem to solve. That's why we have Arricube, Filmlight etc etc to save us headaches. I'm not saying using logrithmic tools in your grading software isn't easier to think about. ALL I'M argueing against is that a DPX log file will produce *DIFFERENT* results from a lin file format.

Are you contending I am wrong on that point? If I'm wrong on something else it was entirely accidental because I was trying to make no other assertions.

EDIT: And just to be quadruple - septuply clear. When I say "linear" I mean linear not 'video gamma'.

 

[Sanjin Jukic]

Gavin,

I would agree with you in that point.

Also I was already prepared for that to show here one "evaluation" that done in Shake using the following:

One REDLog and one Linear Light output DPX files from RA B20, then imported in Shake and then "applied" to build in plug-in LUT TrueLight from FilmLight software.

Here we go and about all parameters "involved" there you can read from the pictures below:

This picture shows how "look" REDLog imported in Shake.

This picture shows after 'applied" TrueLight plug in LUT with no any other intervention at the file.

TrueLight LUT
profile: Kodak Vision Premier
display: digital Projector
colour space: Log

This picture shows how "look" Linear Light imported in Shake.

This picture shows after 'applied" TrueLight plug in LUT with many interventions at the file in Shake.

TrueLight LUT
profile: Kodak Vision Premier
display: digital Projector
colour space: Lin

Lin and Log they both "look" a bit different.

The picture is shot on RED1, handheld with EasyRig 3 with Leica Summilux-R 50mm f/1.4 @ 2.8 during a walk through foggy forest in Bödele, Bregenzerwald, Vorarlberg, Austria (end of June 2009)..

 

[Gavin Greenwalt]

Didn't you just prove my point? A convoluted log workflow results in different outcomes because of subtly different interpretations of "log" is?

Here is what happens when you have confidence in exactly what is happening at every step:

short line is the dividing line between two for all intents and purposes identical images.

To be really specific. The margin of error is .00001 (in lin space) which is so small that if you tried to save out a difference matte in it wouldn't even fit into 16 bit color space.

 

[Evangelos Achillopoulos]

An image speaks a thousand words...

Sanjin, in a difficult image with high contrast in edges, is using a real film print 3DLUT and gets that beautiful image in the log process almost immediately... The linear is not the same even if he tries to fix it...

Gavin, in a not so difficult image, from unknown source, I suppose its RED... never the less, is using a typical 1D log to Lin transform... it gets the same... why? because is not a 3D Lut derived directly from a film stock, as Sanjin did in first place...

That alone is one big difference... simply Gavin has never seen the difference that Sanjin is suggesting...

Moreover I have a strong feeling that the image was originally linear, he converted to log with Lin to log 1D Lut with the same transform, as he did the Log to Lin... so you could expect... two inverts are equal to no change...

 

[Gavin Greenwalt]

Fine. I can do truelight too.

Again. The Same Image. Average error ~.000015.

Raise your hand if you can see the split.

 

[Evangelos Achillopoulos]

Gavin you didn't answer about the source...

 

[Gavin Greenwalt]

Uncompressed Linear RAW (Canon) -> sRGB 16bit Zip Tiff (2.2) -> converted to 32bit Lin (gamma 1/2.2) -> saved off to a 16 lin float EXR (no conversion) and a log DPX.

In the Gauntlet De Proof what do you want next? It won't make any difference. That's effecitvely the same workflow that Sanjin used with the exception of not using the correct LOG conversion in Shake.

R3d? Film originated DPX? What precisely are you expecting to go wrong? Data is Data.

 

[Sanjin Jukic]

Sorry guys but i forgot that we are on the internet and using computer monitors that all have rec709 color space (mostly)!!!

ARIICUBE use this: "The Hubble is manufactured by X-RITE and is a cost effective off-the-shelf solution for monitor and projector measurement."

Ten my set up is now like this:

TrueLight LUT
profile: Kodak Vision Premier
display: rec709
colour space: Log & Lin

And all looks much better now.

I would say Log and Lin are both very close now and as Evangelos said before Log & Lin can be even better with a right chosen and custom made 3D LUT.

So as you like it: LOG or LIN !!!???

Have a look at below images (this is just an evaluation and simulation of the real DI process):

TrueLight LUT
profile: Kodak Vision Premier
display: rec709
colour space: Log

TrueLight LUT
profile: Kodak Vision Premier
display: rec709
colour space: Log

Truelight workflow in Shake.

More about Truelight in Shake>>>

 

[Gavin Greenwalt]

There should be no difference between those images. If there is a difference then I would bet there is user error at some stage in your workflow. I've already demonstrated that lin and log source files look exactly the same. Twice. I just did it again here on my home computer with some kodak negative I scanned myself. Looked exactly the same.

A Lin file out of Redcine and a log file out of REDCine shouldn't contain any different data.

Rec709. sRGB. Monitor calibration. It all means nothing. I'm reading the actual RGB values. And they're the same. What LUT you use to preview the data is irellevant. The same is the same. I can make them too dark... and the same. I can make them too red... and the same.

Tell me the procedure you want me to follow which will result in a dissimilar pair of images.

 

[Sanjin Jukic]

TRUELIGHT in Shake APPENDIX>> Colour Space conversions:

 

[Gavin Greenwalt]

And are you using REDLog? Did you use the correct conversion in Shake to compensate for RED's non-standard log?

REDLog != Log

 

[Gavin Greenwalt]

By the way just found this gem of a post:
http://reduser.net/forum/showpost.php?p=168079&postcount=18

RedLog would need to be converted into PDlog for filmout. Some facilities have been converting to linear from redlog and then to their own pdlog formula tuned for their recorders.
PDlog685 is pretty much the cineon spec for log to linear conversion in reverse (linear to log).
It's not exactly what you'd get in a film scan (regarding peak whites going well above 985) but it lets one reverse the log conversion using standard log2lin tools that are in programs like shake.

 

[Gavin Greenwalt]

Here ya go. Also linked to in the same thread.

Sanjin. Take your REDLog file. Apply this conversion http://prolost.com/blog/2008/3/15/red-log.html

Then input it into truelight as a lin file. They should now look (and when sampled be) exactly the same.

I might not know much about film printing and make no claim to. But I know basic math and that's all that's necessary in this case. Years of color science experience are irellevant. A TI-85 is more qualified than any of us.

 

[Sanjin Jukic]

There should be no difference between those images. If there is a difference then I would bet there is user error at some stage in your workflow. I've already demonstrated that lin and log source files look exactly the same. Twice. I just did it again here on my home computer with some kodak negative I scanned myself. Looked exactly the same.

A Lin file out of Redcine and a log file out of REDCine shouldn't contain any different data.

Rec709. sRGB. Monitor calibration. It all means nothing. I'm reading the actual RGB values. And they're the same. What LUT you use to preview the data is irellevant. The same is the same. I can make them too dark... and the same. I can make them too red... and the same.

Tell me the procedure you want me to follow which will result in a dissimilar pair of images.

EDIT:

Working it with REDCINE>>>

Result report is coming soon>>>

 

[Sanjin Jukic]

There is a slight difference between Log and Li in my tests.

Maybe there should be like this always by default but I'm "investigating" that...

I do not discuss this here any more just because I'm very busy like always.

Regards

Sanjin

DPX PDLog685 to TrueLight Log in Shake.

DPX Linear Light to TrueLight Lin in Shake.