BSC Film and Digital Image Evaluation 2009

[M Hawkins]

Apologies if this has been discussed elsewhere.

Will any redusers be attending? Looks like it will be a really interesting event.

http://www.bscine.com/events/

Matthew.

 

[Evangelos Achillopoulos]

It was yesterday... has anyone see it...

 

[Shawn Nelson]

There's quite a fascinating thread on the CML list about this that I am quite surprised to have not seen Red weigh in on

 

[Tom Lowe]

:emote_couch:

From my brief reading of this, it sounds to me like there were serious post issues. Just like stills, DPs now need to learn and master RAW post. It's part of the "shoot" now. This means DPs need to be paid for their time at post houses. I believe it was John Toll who argued the same thing in AC recently. Producers need to end this cheapskate nonsense of not setting aside funds for DP post time. Why spend a million dollars on lights and crew, and nickel and dime the DP to death in post, when his input is extremely valuable? The game has changed with RAW.

Hopefully, for future tests done with Epic, post issues will be more squared away. I'm willing to bet that Epic FF35 will take all competitors to the woodshed. There is no doubt that the 6K RAW quality will destroy 1080p rivals -- utter decimation. Although it remains to be seen how much improvement we will see with DR and ISO/ASA performance. My guess is, a lot.

 

[M Most]

The game has changed with RAW.

The game changed with digital intermediate. RAW is another format with its own specific quirks, but when cameramen talk about being paid for post, they are talking about the fact that when timing on film, it only required a few days of their time, and not all day. With DI, it requires at least a week, on major pictures considerably longer, and pretty much all day every day. That's a lot of time to not be compensated for.

 

[Tom Lowe]

Sure, but RAW presents an even deeper dilemma for the DP than a basic DI.

Recently, I shot some RAW timelapse sequences for a big project. If I had shot JPEGs, I could have passed the data to the post team with little worry. The look is somewhat baked in. But since I was passing them RAW data on CF cards, it felt very strange to leave such an intricate process to people who probably have little experience in processing the type of 5.6K RAW sequences I shoot. This is why DPs like David feel so uneasy about the discrepencies in REDRAW processing. Give it to one post house, and your shots are golden. Give it to another, and they come out like garbage.

This presents an even stronger argument for inclusion of the DP in post.

 

[Neil W. Smith]

BSC and ASC camera tests ... some thoughts for the RAW revolution

BSC and ASC camera tests ... some thoughts for the RAW revolution

I attended the ASC/PGA review here in LA at the DGA a few weeks ago .... Ted was present along with David Mullen and many other ASC DPs .... I didn't see the BSC test results but had already voiced some concerns about the methodology of the ASC approach before the BSC tests were shown.

As a file-based, post house that's been working closely with RED since the very first prototype images were graded in our DI theater, we knew that way the RED images were shot and processed did not in any way show RED at its best (or a couple of the other digital cameras for that matter) .... anyway, there's been a heated discussion on CML over the objectives, goals and methodologies of both the ASC and BSC tests .... things are never black and white in these sorts of camera tests, so I don't want to engage in some religious debate on the rights and wrongs of the approaches taken, suffice it to say that if you want to shoot and post great looking RED footage (like we do all the time) you probably don't want to follow the approach taken in the ASC and BSC tests ;-)

However, the tests raise a more fundamental issue that we in the RED community are up against ... we're in the midst of a significant sea change in cinematography and movie making .... we're gradually leaving the old analog film world and transitioning to a digital file-based world ... things are definitely changing but not as rapidly as some people hope or some people people fear ... the old film acquisition/DPX based DI/film projection workflow has worked tremendously well for many years and will continue to be around for a few more years before RAW based workflows become the norm. In the meantime, boutique post-houses like us, continue to upgrade and tweak the RED workflow to optimize the final image quality at the same time as reducing costs ... unfortunately, this isn't true for all the organizations and post companies involved in processing RED footage.

We all know how good and cost effective RED footage can look if its shot and color corrected properly ... what ever you may hear about the ASC and BSC test results, know this, the RAW revolution has only just begun, the are many hurdles to overcome, but already RED delivers against its promise and delivers it with stunning imagery at an incredible price point.

I'd like to copy here the post I contributed to the CML discussion on the BSC test .... let me know if you have any further thoughts on the matter:
Thanks,
Neil

From CML - July 9th 2009:

So YES I'm sure the Red footage in the ASC and BSC test could have been handled better, but the fact that it's a bit of a struggle for the various post houses, all of whom are developing their own methods of dealing with it, some more successfully than others... well, that also tells you something too. (David Mullen)

I came away feeling that the very cameras that we wanted to see most in a comparative environment had been screwed in the post environment. (Geoff Boyle)

Thanks Geoff for your report on the BCS camera tests and David for his observations on the challenges of finding the optimal post workflow for working with Bayer-sensor cameras .... both the BCS and ASC tests seem to raise a common issue, namely, 35mm analog film has great latitude and a very well understood post pipeline that has been refined over many years to ensure that the negative exposed on set by a skilled cinematographer ends up being printed in a fairly predictable and pleasing way (not always, but more often than not) whereas the digital acquisition imaging pipeline still has several short-comings in terms of latitude response and the amount of work required in post to obtain an esthetically pleasing final image.

Historically, in the process of optimizing the film-based workflow, Eastman Kodak played a pivotal role in working with camera manufacturers, DPs, film labs and theater owners to ensure the integration and quality of the separate parts of the movie making process - Kodak 35mm film stock became the de-facto standard for image capture, post-production methodology and theatrical viewing quality.

However, in the digital, file-based movie making world, the optimization of the 'acquisition - workflow - output' equation is still in its infancy - this coupled with the fact that digital movie-making technology is improving exponentially in a manner similar to Moore's Law in the computer world, creates an environment wherein the goal-posts are continually moving and the sand is constantly shifting - if you'll pardon the mixed metaphors.

So, maybe the underlying issue exposed (excuse the pun) by the ASC and BCS camera tests is this - how do we find some "constants" we can trust in the rapidly changing filmmaking world we're all experiencing? Some best practices that can be applied to on-set acquisition, post-production and delivery that Producers, Directors and DPs can at least use as a bench-marks to gauge quality and cost performance?

In the digital, file-based filmmaking process we are not yet ready for any hard and fast de-facto standards (there is no digital equivalent of the wonderful Eastman Kodak company) but we all want to find cost-effective and optimal ways of delivering digital movies to the highest quality possible .... maybe the ASC and BCS should combine their tremendous expertise and talents to come up with a discussion forum where digital filmmaking best-practices can be raised, discussed and qualified in a pragmatic and rigorous fashion ... its no longer just about the camera or just about the workflow of just about the delivery output but the optimization of all three against the harsh realities of budget constraints.

Having worked with several ASC DPs over the last few months on RED based projects we know how good (and cost-effective) RAW, file-based filmmaking can be ... I'm sure the chaps in question would be happy to share their experiences and insights if other CMLers are interested ... in the meantime, who is going to take up the gauntlet of defining some industry-wide best practices that address the continually changing digital 'acquisition - workflow - output' versus budget equation?

 

[David Mullen ASC]

Sure, but RAW presents an even deeper dilemma for the DP than a basic DI.

I'm not sure how much a DP can have any control over RAW to RGB conversions though -- when we get into a D.I. suite, we are already looking at color images, which we then color-correct. So if the conversion process and whatever viewing LUT's are being used aren't done properly, then you won't get optimal results, but it's very hard for a DP to get under the hood and figure out what is going wrong, especially since every post house has engineers who know ten times what any DP knows.

But on the other hand, the same danger exists for things like film scans -- it's not like the DP supervises the scanning process or the specs for scanning other than pixel resolution. Or Log conversions for that matter. The only difference is that film scanning, telecine, and working with Log tends to be fairly standardized these days, unlike working with R3D files.

But as a DP, I should not have to be the one to tell a post house how to process files properly just so I can get into the color-correction suite knowing I'm working with properly prepared data. It's just like how when I shoot film, I assume that the lab knows how to process ECN2 negative, I'm not going to have to learn chemical processing and check their baths myself before they run the negative through it.

Sure, I have to know this stuff to a degree in order to troubleshoot and control my own work, but how can I know film stock as well as the emulsion designers, processing as well as the lab supervisors, or electronic processing as well as an engineer with a degree and decades of experience?

This is a real problem, proper file conversions, but it makes no sense that cinematographers are going to go into post houses and tell their engineers and colorists how to do their job better -- any more than they can tell a DP how to light a scene better.

We have layers of technical experts in this industry. I fully expect and hope people at Red like Graeme Nattress know more than me about building a digital camera, so I'd hope that an engineer building a D.I. facility knows more about signal processing, digital projection, etc. than me or any other cinematographer.

Because, honestly, I have enough to learn just to be a better DP.

RAW conversions for color-correction should not become part of the creative process, it should be a technical process that then gives you all the information you need to become creative in the color-correction suite, just like processing color negative film is a technical process. So I don't particularly think that RAW somehow places more demands on the cinematographer to control the process IF the darn conversions to RGB are done correctly in the first place.

The reason DP's need to be paid for their post time is that they spend so much time doing post these days, far exceeding the time they used to volunteer for free.

 

[Gavin Greenwalt]

It would be nice if everyone went to a format like OpenEXR. EXR supports colors from -infinity to +infinity. There is no such thing as "clipping". That's the way all RGB formats should be.

When you convert from RAW to RGB there is no reason you should ever lose data in the raw image due to clipping. If you crush the blacks. They should still be there just as a negative color value. If you blow out the whites then they should still be there as float values > 1

Conversion from RAW to RGB should result in all the data remaining in tact but just presented in a 'recommended' fashion.

Also RAW conversion to RGB should stay linear. There is no ambiguity between "sRGB" "REC709" "REDLog" "PannaLog" "Log" etc etc... it's linear. It is what it is. If you want to view it differently then apply a LUT. At no point should RGB be gamma corrected. At no point should RGB clip. We have giant, super fast raids standing at the ready. It's "video thinking" that results in lost data. The idea that bits are a precious commodity results in the Fear Uncertainty and Doubt that is associated with these new technologies..

This is a case where Brute Force is the answer. Save everything.

 

[Neil W. Smith]

Observations on the RAW revolution ...

Observations on the RAW revolution ...

It would be nice if everyone went to a format like OpenEXR. EXR supports colors from -infinity to +infinity. There is no such thing as "clipping". That's the way all RGB formats should be.

This is a case where Brute Force is the answer. Save everything.

The use of OpenEXR will certainly address some of the issues raised by the ASC and BSC camera tests .... ILM and Weta for example, have already implemented OpenEXR as their standard file format in their VFX imaging pipelines.

However, your recommendation also highlight the challenges facing DPs and post-houses in the current situation .... OpenEXR supports "16-bits-per-channel floating point values (half precision), with a sign bit, five bits of exponent, and a ten-bit mantissa. This allows a dynamic range of over thirty stops of exposure" .... whereas most movies are currently finished in a 10bit log or lin pipeline using the DPX or Quicktime file format and usually at 2k resolution.

The point being that in this period of transition from the old analog film world to a RAW, file-based world, Producers, Directors, DPs and Post Supervisors are looking for a predictable and cost-effective way to deliver a high-quality final image that they can trust. At the moment, that pipeline is typically a 2k 10bit log DPX pipeline.

RED RAW is a 4k 12 bit Lin image which somehow has to be "squeezed" into a 2k RGB QT or DPX pipeline and this is where the problem arises ... there are several ways of doing this and not all ways produce the same quality of output.

For example, we recently worked with Rodney Charters, ASC, who shot a TV pilot on RED for a national network channel and showed him the difference between transcoding to 2k DPX early on in the imaging pipeline versus staying in .r3d RAW until the end of the color correction process ... the differences were noticeably better in favor of staying in 12 bit RAW Lin for as long as possible before outputting to 10 bit DPXs or QTs.

Unfortunately, in the ASC camera test the decision was made to go to a 10bit DPX format as early as possible in the post pipeline and in the BSC test, according to Geoff Boyle, BSC, .... "RED, hmm, Redcine used to extract but it also says R3D files imported directly in to EQ ????"

Ted and I discussed the ASC methodology after the presentation at the DGA and both agreed that the RED images could have been made to look a ton better if a different post process had been used. The work we've done with ASC DPs over the last few months prove that RED if correctly exposed and finished in an optimized post workflow can produce very 'filmic' and high-quality images at a great price point.

So, if you hear anything negative coming out of the ASC and BSC tests about the quality of the RED images, you might want to take it with a pinch of salt ... you really have to understand the objectives of the tests and the processes employed before you make an informed decision on the real quality of a RAW based workflow.

As David Mullen eloquently puts it in his post above:

"RAW conversions for color-correction should not become part of the creative process, it should be a technical process that then gives you all the information you need to become creative in the color-correction suite, just like processing color negative film is a technical process. So I don't particularly think that RAW somehow places more demands on the cinematographer to control the process IF the darn conversions to RGB are done correctly in the first place."

And that's the big IF .... post-houses have to know when and how to convert RAW files to RGB to get the best looking RED images ... this shouldn't be something that DPs have to struggle with.

So, as we make the transition from film/DPX based workflows to RAW, file-based workflows, make sure your post-house knows how to extract the maximum amount of color and latitude information from a 12 bit Lin image ... it'll make all the difference to your final RED images.

16 bit OpenEXR may be the solution to many of the problems facing DPs now but unfortunately for most filmmakers it's not a viable option just yet ... we're going to be living in a 10 and 12 bit world for a few more years to come.

If you want to see how great RED images can look, give us a call ... we'll be more than happy to show you a very high-quality and cost-effective RED imaging pipeline.

Neil

 

[Evangelos Achillopoulos]

I'm reading again and again the above posts...

I have lost it...

The bottom line of what happened in the BSC tests is...

Because of the lack, of a predictable way, to convert RAW efficiently to something that todays DI understands, Cineon Log that is, the results were at least problematic... plus that the whole procedure was based in DCI grading, (which is linear, since DCI uses electronic projectors that are linear) which gives an extra advantage to film, because of its logarithmic nature... it has smooth roll off of highlights against hard cut offs that linear sensors have...

If the BSC test was done with a film out target and a film projection the results would be largely different because then the whole process would be forced to follow the Log route...

Now...

what David says is a very logical thing... that the RAW conversion has to be done in a clean and predictable way... a Cineon Log conversion is the most common thing in our DI suites... yes we don't have that option with RED's software... OK we have to ask RED, to just do it...

Where the open EXR gets into the picture since we can't even have a simple Cineon Log decoding of the RAW... I don't understand...

RAW is great... but have you, all noticed, in the RAW conversion settings in ALL the grading software's, that we have to select a decoding colorspace? like REC709, REDspace, REDlog etc...

So is the same thing if we first export the DPX's (or Tiff's if its linear export) and then grade them.... Or use the same settings in the RAW tab and start grading... because we have the same thing under the hood... a conversion happens on the fly... the very same conversion that we did in the DPX's... the problem is, not when the conversion take place, but how the conversion is being done.

All of us we keep the RAW until color grade or VFX has to be added... there are same exceptions, that they use Quicktime or Prores, but for a reason...

So how Neil would keep RAW more than all the rest of us... its something that I have to understand...

I totally agree with David saying "This is a real problem, proper file conversions" and that the process of conversion, IS a totally technical process like ECN2, that DoP has nothing to do with...

The only thing that DoP has to do, is to make sure, that the post process is going to be a Cineon Log with film targets... to get the best image possible...

Let me elaborate a bit about the process... and the secret sauces...

There are three ways to do the job... (apart from the Quicktime / Prores, that all are more inferior than the followings)

1. Poor man DI method
   Grade from RAW or Tiff's or (worst way) linear DPX's in a broadcast monitor or to whatever monitor in REC709, REDSpace or linear light, linear process all the way, and deliver...
   
   Good video images
   
   
2. Poor mans DI method plus...
   Grade from RAW or Tiff's or (worst way) linear DPX's in a broadcast monitor or to whatever monitor in REC709, REDSpace or linear light, linear process all the way as above, but put a "home made by the eye" S curve to try to get the filmic look and then deliver...
   
   Better, less video looking images...
   
   
3. Proper Cineon Log DI workflow
   Grade from RAW or Cineon Log DPX's in a broadcast monitor or a calibrated film grading monitor and use Log process all the way, with real film LUT's and have the exact look of film... then make the various conversions to deliver REC709, DCI or whatever...
   
   Outstanding WOW Film images...
   
   

In the BSC tests, they did the first one, but instead using REC709 they use a DCI which is linear also...

How you going to do the last one, without a proper Cineon Log is the question, that RED has to answer... same post houses have found an empirical conversion that is better than others... RED's job is to give us a standard optimal way to do it...

If in the future we will need an Open EXR or an HDR or a GSFDHSSH... is meaningless to discuss it today, that we don't have the basics...

If all I say looks to you like Chinese... I do, get paid for consulting...

 

[Jonas Rejman]

@Evangelos

What I do not understand, is why a linear workflow should be "poorer" than a log/cineon workflow?

If you stay in linear throughout the whole process, and in my opinion you can use 16bitlinearTIFF as fileformat that every application understands, if needed (instead of openEXR) and you grade with your destination filmLUT in a calibrated environment, before you export to DPX for the laser, isn't that technically preserving all data to the very end, and ergo better?

You say "mimic filmic look" - can't I do that on linear files as well, through grading? If my setup is calibrated I approx. "get what I see" on the digital projector also on the film projector...

 

[Evangelos Achillopoulos]

@Evangelos

What I do not understand, is why a linear workflow should be "poorer" than a log/cineon workflow?

If you stay in linear throughout the whole process, and in my opinion you can use 16bitlinearTIFF as fileformat that every application understands, if needed (instead of openEXR) and you grade with your destination filmLUT in a calibrated environment, before you export to DPX for the laser, isn't that technically preserving all data to the very end, and ergo better?

You say "mimic filmic look" - can't I do that on linear files as well, through grading? If my setup is calibrated I approx. "get what I see" on the digital projector also on the film projector...

It would be handy Jonas, but unfortunately with linear source (tiff that is) the image doesn't "modulate" or behave as a film scan... whatever the LUT is... that results to a less appealing image...

Log in - Log out will always be better... our eyes understand Log and because, we won't going to be genetically upgraded to new pairs of eyes with linear response, any time soon as humans, I thing the fact that log is better, will not change for the following millennium... unless, because image sensors are linear, someone start an R&D project to change our eyes also... just to facilitate CMOS sensors and DCI projectors... for decades film was working as a log capture device and film projected as log, based on the fact that human vision is log... lets change that... who is going to start the new revolution? I have myopia, I suppose with the new set of eyes I won't have anymore, WOW!!! lets go for it...!!!???

 

[Gavin Greenwalt]

But unfortunately with linear source (tiff that is) the image doesn't "modulate" or behave as a film scan... whatever the LUT is... that results to a less appealing image...

Log in - Log out will always be better... our eyes understand Log and because, we won't going to be genetically upgraded to new pairs of eyes with linear response, any time soon as humans.

"Lies, Damn Lies..."

The world is Lin. Therefore our sensors should be Lin.

The math should be in Lin. The grade should be in Lin. Our monitors project light in Lin. Film screens are reflecting Lin light.

Introducing gamma into the workflow is precisely the sort of confusing intermediary step which serves no aesthetic advantage. Its sole purpose was to save data. It also made sense back in the day when all you ever dealt with was film.

All files should be in Lin and assumed Lin in all applications. If they like the way a color multiplication looks in Log space then the application should do that conversion. It shouldn't be in the file.

And it's COMPLETE NONSENSE that Log files provide a superior image to a lin file. A 10 bit log file and a 16bit lin file can contain the exact same data just stored differently. The lin file will use more space for a perceptually identical image but it has a host of other advantages. First and foremost being that it's considerably less confusing. It's in lin and lin is exactly the same in every app. NO CONFUSION. Lin is Lin is Lin. Log is not Panalog is not cineon is not redlog. Nonlinear color space is fraught with space for people to screw up the footage.

The only gamma correction that should be occuring is at the application and viewing LUT level.
In this respect I have to say that "Nuke is the Way The Truth and the Light".

Also. Not on log but on non-linear color and color in general and very well written article by Martin Breidt (with a couple of comments from myself) http://www.breidt.net/scripts/gamma_correct_v12.pdf

 

[Evangelos Achillopoulos]

So Gavin... we can agree that we disagree...

I didn't call you a lier... but if this suite you, its fine... I suppose that you also have a Linear set of eyes...

Look, I will do what I thing is good for my clients, and you do what you thing is good for yours... the history will tell which was right...

Since you suggest exactly what was done in the ASC - BSC tests and your above description follows their methodology... the tests were perfect for you... let mine be a bit different... more spicy...

You see Gavin, you CANT work with linear files and Log LUT's... but ts fine for me if you say so... the less they understand, the more money I make...

I rest my case...

 

[Gavin Greenwalt]

So Gavin... we can agree that we disagree...

I didn't call you a lier... but if this suite you, its fine... I suppose that you also have a Linear set of eyes...

My apologies for any offense it wasn't intended as an attack on you personally. It's just a common rhetorical english quote.

"Lies, Damn Lies and Statistics." http://en.wikipedia.org/wiki/Lies,_damned_lies,_and_statistics

Twain popularised the saying in "Chapters from My Autobiography", published in the North American Review, No. DCXVIII., July 5, 1907. "Figures often beguile me," he wrote, "particularly when I have the arranging of them myself; in which case the remark attributed to Disraeli would often apply with justice and force: 'There are three kinds of lies: lies, damned lies, and statistics.'"

Still my largest pet peeve is that so many people are confused by color space. And they're confused largely because it actually is completely unnecessarily confusing. So confusing that *ahem* we need consultants to help us wade through the well intentioned muck that's been collecting over the years for something which should be incredibly bone headedly simple for everyone to understand.

Math is math. Numbers are numbers. How those numbers are stored is largely meaningless and should be completely transparent to the user. Introducing Log where it has absolutely no place in the process what so ever is nothing more than confusion.

Viewing an image correctly on an srgb calibrated monitor is simple. ^2.2 Done.

When you have a linear image the conversion is a single step. You just choose your output format. It's simple from a software standpoint. It's simple from a conceptual standpoint. It's just simple. And what the digital workflow needs more than anything is is more simple.

 

[Michel Hafner]

It would be handy Jonas, but unfortunately with linear source (tiff that is) the image doesn't "modulate" or behave as a film scan... whatever the LUT is... that results to a less appealing image...

Not when the data is linear to begin with and all what we have. There is nothing to be gained from converting 12 bit linear to some x bit log format, as long as any computations with the 12 bit data are carried out without accumulating rounding errors. The film reference is not relevant here. Different scenario. If you think of negative having information adequately covered with linear 16 bit samples (for example) and then you want to know how to store this best with 12 bit, then the 12 bit log may make more sense than 12 bit linear because you shape the information loss so it's least visible to the human eye. With a 12 bit linear source this scenario does not apply. All information we have are the 12 bits linear and converting to log is not creating any new information. At best it can hold on to what we have as far as seeing information loss is concerned, at worst we lose information we don't want to lose. Keeping the 12 bit as is loses no information at all as long as further processing adds no rounding errors to the least significant bits or is in itself not destroying information by its nature (low pass filters etc.). Independent of this is what to do with the final processed image once it must be shaped to look best on some output destination.
Michel Hafner

 

[Sanjin Jukic]

Digital image LOOK with "RAW digital cameras" are mostly defined by five main parameters:

1. Light intensity or lighting.

2. Lens (glass type, specific type of coating, color rendition, etc,...).

These two above (1 & 2) are the most important before you get your image in the camera.

3. Sensor (type, size, noise, reset method, dynamic range, speed, color, pixel architecture, etc,...).

Also there are many opportunities that you can keep or even tweak your "in camera look" to the end as a final look of DI process

or to achieve WYSIWYG effect if you want but mostly for a final Video Look.

These two below (4 & 5) are the most important when your data are out of the camera recorded on CF, HDD Raid, etc,...

4. RAW developer software (that can use a different de-bayering algorithms, etc,...)

5. Once the conformed edit has been checked, it is ready for grading in grading suite application at DI process.

RED Digital Cinema Company is mostly oriented to development of its own Lenses (2), Sensors (3) and (4) RAW-developer software.

For the tread topic here and now point (5) is the most important.

Here we go:

There are two types of data in a final DI processing, Lin Data and Log Data.

Which you want to choose?

It depends which LOOK you want to choose and on format you want to finish: Film or DCI (Digital projection) for a theatrical release (here the broadcast formats were not discussed).

It's not a "rocket science" at all>>>

"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 was 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."*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 was 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."**ARRICUBR Preview LUTs>>Find at above pictures.



To get more illustrative and in detail picture what it is about have a look at ARRICUBE workflow brochure:

ARRICUBE Creator for calibration of displays and output formats.

Lin Data workflow for ARRICUBE Video Look.

Log Data workflow for ARRICUBE print to film.

READ MORE>>>

 

[Stepan Kment]

exr...

exr...

I totally agree EXR is THE way ahead.

Few notes: gamma corrected environment is really needed for low bit depth imagery. Simply, when it is not gamma corrected 8bit, it would result in horrible visual problems, too many bits in hili, but almost no bits in shadows. Gamma fixes it.

However, when we are in float, all this is gone, even 16bit float is said to store more than human eye can ever see. It is not exact, it is float, so some rounding error appears, but it is considered as fully acceptable. And then, my working space is 32bit float to avoid accumulation of error, i/o is 16bit float, color management EXR embedded primaries and Im happy and done.

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.

That DPX nonsense.. 10bit cineon can NEVER store full data from R1's raw - it is simple, 12 bits can't be transformed lossless into 10bit, no matter to log, lin, to any. Simply there are losses, only either losses less visible or more.. keep raw as long as possible, then store exr and you are sure you loose almost nothing. Only use DPX as an export of color graded and above all exposure adjusted data for a film output, then it is no longer an issue. If you can. Not sure if e.g. Lustre can import exr, r3d certainly can't. But scratch, baselight.. support r3d directly.

 

[Gavin Greenwalt]

It can't be stressed enough. The world is linear.

Eventually EVERY format becomes linear light. The human eye is irrellevant. All that you are ever doing is packaging the information to be transmitted to the human eye.

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. All output is eventually lin and all input was at some point lin. It requires no extra explanation along with the file. It requires no communication with the post house in theory. If your setup is calibrated to accurate lin workflow you simply choose the output hardware's LUT. It's almost completely foolproof. And everybody in the world who is calibrated to their preferred LUT would be guaranteed to be color accurate (within the limitations of their display gamut). Because there is no "reversal" to be performed. If I had you a file which is gamma corrected to a gamma of 2.185 (or god forbid a 3D LUT). The only way you will ever see that image correctly is through a lot of extra calibration or to know that I gamma corrected the image by 2.185. In contrast if you give me a linear image and my HP Dreamcolor wants an sRGB input to convert to linear output then I simply calibrate to sRGB and I need to know nothing about your workflow.

That workflow would be identical regardless of source. That workflow would be identical regardless of destination. I think that's the most important thing when we're now working with mixtures of Video, RAW and Film being outputted to Film, DCI, DVD and YouTube. It's a single way to handle your inputs. It's a single way to handle your outputs. And you remove hundreds of potential pitfalls and points of failure simultaneously. It's a win win!