Ask Mike Most Anything

[danibam]

I find confusing that the ARRI RAW format (T-Link ARRI RAW) delivers LogC and RED RAW delivers "Linear Light" ...
I keep hearing about quite an amount of digital image processing before a camera delivers RAW data: noise reduction
is one, but with ARRI RAW delivering LogC, I've been wondering if some gamma correction or any other color grading
transformation is actually being done as well? I've heard that ALEXA performs some kind of dual processing of the
RAW capture in 16 bits? Does the ALEXA sensor capture 16 bits? When does it stop being RAW and begins being a
processed image?


Daniel Perez

[Evangelos Achillopoulos]

i should not stir up a can of worms but I can't help it. I have a huge problem with people who make numeric claims (as you have) and then, when those numbers are questioned, say "forget numbers, it's all about art." There is problematic logical inconsistency there. Plus, reference projector calibration is first and foremost a technical science. It's not some kind of voodoo. There is a raw and hard technical side to what we all do. It's at the service of art, for sure, but art alone cannot make a good motion picture.

When I'm referring to measurements I'm explicitly talk on what I can control... So in my reference theater, which follows the Color Ttiming critical viewing conditions spec of SMPTE 196M which are:

For laboratory use in color timing, projectors shall have a chromaticity match of x = ± 0.001 and y = ± 0.002. Typical chromaticity readings would be D5500: x = 0.332 and y = 0.347. Chromaticity measurement requires a precision chromaticity meter, not a color temperature meter. Review room screen luminance shall be 55 cd/m2 ± 7 cd/m2 (16 fL ± 2 fL) at the screen center. The luminance of the screen sides and corners, measured as described in 5.2, shall be at least 80% of the screen center reading.

And in these conditions I have the results that I'm stating... +/-1 printer light...

In real world projections though the spec is NOT so critical... to a point that is almost subjective the result... SMPTE 196 spec says...

For theater nominal 35- and 70-mm prints, the light reflected from the screen in theaters shall have a spectral distribution approximating that of a blackbody at a color temperature of 5400 K + 600 K -- 200 K, the use of short-arc xenon light sources being assumed. Theater screen luminance at the screen center shall be between 41 cd/m2 (12 fL) and 75 cd/m2 (22 fL). Luminance at the screen sides shall be 75% to 90% of the screen center luminance, but not less than 34cd/m2 (10 fL).

FYI, 800K error range is about 5-6 printer lights...

Also read what David and Mike say about the subject of relativity in end user viewing devices... in the same thread in page 3....

There's nothing you can do about people watching stuff on badly set-up displays. Nothing. But that doesn't excuse one from working towards a standard -- you don't want a to finish a project at a post house where it only looks correct at that post house, any more than you want to create a movie print that only looks correct at the lab that printed it. At least if there is a standard, there is the hope that display devices will move closer to that standard.

There have always been periods in display technology where it's the wild west, then standards emerge, and then later they are abandoned when a major change in technology happens, then new standards develop, etc. More and more people watch stuff on computer monitors and I think there is a movement towards more common display standards being driven by the content providers.

But ultimately you have to ignore the fact that some people are going to watch things improperly displayed or transmitted, you can't really take that into account unless there is a common and consistent form of misrepresentation. If that happens, then perhaps you can compensate for that -- for example, like in the 1960's when prints were adjusted for dim drive-in movie theater projection, and even lighting styles were affected by that trend.

You can only control what you can control. Nobody can go into everyone's home and calibrate their displays, and that's always been the case. In fact, I find that modern flat screens are far more consistent than CRT's ever were, even with the automatic corrections that so many consumers seem to just leave on all the time. There are standards, even today, and that's what one has to use as a reference, even if it's only used by those of us who have to create this stuff. For better or worse, material that is targeted to video type distribution is corrected and QC'd on monitoring that is set up to Rec709 accepted practices for HD images, a standard that is basically based on CRT's but has been carried over to modern displays with some consistency. That's what gets delivered. What happens after that is not controllable by any of us, and one just has to accept that.

Incidentally, this is much worse within the industry than it is in the consumer world. You've got colorists working on proper calibrated monitoring in proper environments, but you've got DP's and directors looking at dailies on everything from laptop computers in bright sunlight, to iPads, to video village monitors, to tiny CRT's in the camera truck, to home TV's that are set up to who-knows-what. And you've got studio execs looking at digital dailies that have been compressed beyond recognition and are playing in postage stamp sized windows on a computer screen and blown up to full screen size. The whole thing would be funny if it wasn't so ridiculous.

So please realize what you say and what I'm trying to say... "there is nothing absolute in life all are relative and art is the most relative of all..." if this is not good for you... I can't do anything more...

[Rob Ruffo]

It sounds like you're referring very specifically to behavior in RedcineX. That represents only one set of circumstances. Many other programs can be and are used to directly access R3D files, and many do not behave in the way you've described. In my view, increasing saturation in a post grading environment is usually not a good idea as it increases noise, particularly in red tones. Many, if not most, colorists would much rather decrease saturation than increase it for that reason. There is some debate on this issue, but in either case, you cannot use the characteristics of one program - particularly one that is working on the debayer parameters rather than post processing - as a basis for general assumptions about image processing, regardless of the camera.

Agreed, I guess I should have specified: I mean saturation settings in direct-raw adjustments made in direct-raw software - I have (I think I have) seen this phenomenon in Resolve, PPro, and Redcine X when looking at RedRaw directly.

[David Mullen ASC]

I find confusing that the ARRI RAW format (T-Link ARRI RAW) delivers LogC and RED RAW delivers "Linear Light" ...
I keep hearing about quite an amount of digital image processing before a camera delivers RAW data: noise reduction
is one, but with ARRI RAW delivering LogC, I've been wondering if some gamma correction or any other color grading
transformation is actually being done as well? I've heard that ALEXA performs some kind of dual processing of the
RAW capture in 16 bits? Does the ALEXA sensor capture 16 bits? When does it stop being RAW and begins being a
processed image?


Daniel Perez

I could be wrong but I believe the Alexa sensor has two 14-bit A/D processors per photosite at two different gain levels to create a wider dynamic range image that is merged into a single 16-bit file that is then converted to a 12-bit ARRIRAW file -- as for the Log-C business, I thought that RAW by definition didn't have gamma curves added, but some online info suggests that ARRIRAW does in fact store 12-bit data as Log-C, which holds the same dynamic range info as the 16-bit linear RGB file that was used to create the 12-bit Log-C ARRIRAW file.

[Rob Ruffo]

How often do you use sharpening on Red or 35mm footage? Do you think this is a frequent or advisable practice?

[Marc Wielage]

How often do you use sharpening on Red or 35mm footage? Do you think this is a frequent or advisable practice?

I have used scene-by-scene sharpening on about 20 35mm D.I. projects over the last six or seven years, but there isn't a "one-size-fits-all" approach that works for everything. In the case of one feature, the DP correctly said (after viewing tests), "sharpness is not our friend," and we used lots of defocus on many close-ups... the opposite of sharpening. Grain management was used on every single project just to make the grain consistent. All the 2K D.I.'s went through a 2K -> 4K uprezzing which was essentially a final line-doubling pass going back out to film, but it's not traditional enhancement or aperture correction per se.

I know of several major digital projects where careful sharpening kernels were used at various points in post, but I can't reveal them (some are currently in progress). One that got some publicity was Avatar. All 3D features need some image processing just to realign and correct for parallax error, interocular distance issues, and general alignment problems, but sometimes sharpening and defocus is necessary just to keep the eyes focused on specific foreground objects. Many, many times we've had to make adjustments to further reduce depth of field in problem shots.

I would be extremely careful about sharpening without lots and lots of workflow tests. Bear in mind that sharpening can encompass H-only, V-only, H&V, plus various combinations of bandwidth settings (highlights only, mids-only, etc.). Diagonal detail enhancement can result in aliasing issues, as can certain kinds of movement, so sharpening is a really, really tricky area that's fraught with problems. I've seen more than one project kicked back from home video QC because of over-enhancement -- sometimes done long before we got the pictures for color-correction, so nothing could be done to fix it.

I think if any enhancement is done, you should do it at the final stage, and decide how far to go based on what it looks like on a 100% reliable monitor or projector. In almost every case, the general rule of thumb is: less is more.

[danibam]

I could be wrong but I believe the Alexa sensor has two 14-bit A/D processors per photosite at two different gain levels to create a wider dynamic range image that is merged into a single 16-bit file that is then converted to a 12-bit ARRIRAW file -- as for the Log-C business, I thought that RAW by definition didn't have gamma curves added, but some online info suggests that ARRIRAW does in fact store 12-bit data as Log-C, which holds the same dynamic range info as the 16-bit linear RGB file that was used to create the 12-bit Log-C ARRIRAW file.

But ARRIRAW delivers a Bayer Pattern, right? ... I think I can understand how the output of two A/D processors per photosite could be later merged without first deBayering to RGB, but I am curious to find out if a LogC gamma adjustment can be properly achieved while still in Bayer Pattern ... if it requires any special treatment in order to achieve the same result of a post deBayer RGB gamma adjustment ... and in general if any other color matrix operations can be "safely" performed on a Bayer Pattern.


Daniel Perez

[David Mullen ASC]

But ARRIRAW delivers a Bayer Pattern, right? ... I think I can understand how the output of two A/D processors per photosite could be later merged without first deBayering to RGB, but I am curious to find out if a LogC gamma adjustment can be properly achieved while still in Bayer Pattern ... if it requires any special treatment in order to achieve the same result of a post deBayer RGB gamma adjustment ... and in general if any other color matrix operations can be "safely" performed on a Bayer Pattern.


Daniel Perez

I found out today from ARRI that 12-bit ARRIRAW is not Log-C, it is still RAW (Bayer mosaic).

[M Most]

But ARRIRAW delivers a Bayer Pattern, right? ... I think I can understand how the output of two A/D processors per photosite could be later merged without first deBayering to RGB, but I am curious to find out if a LogC gamma adjustment can be properly achieved while still in Bayer Pattern ... if it requires any special treatment in order to achieve the same result of a post deBayer RGB gamma adjustment ... and in general if any other color matrix operations can be "safely" performed on a Bayer Pattern.

I think it might be instructive to go through the differences between RAW and debayered images, and also the nature of what "log C" is. RAW data is just that - it is the record of the values of each photosite on the sensor. Now, how that's handled through a compression process, a reconstruction process, and a recording process are different depending on the manufacturer. Until the RAW information is reconstructed as a full RGB image, it exists only as pure data. But data compression has efficiency limitations unless you optimize the data for that particular compression. So in the case of Red, for instance, some transformations are likely made to the RAW data in order to enable more efficient wavelet compression. There are a lot of things you can do in this regard, and techniques include applying a mathematical log curve, computing color channel differences to reduce the amount of pure data needed, and other transforms designed to allow a compression engine to work more effectively. It is still the basic RAW data, but it isn't necessarily the exact values that came off the sensor in their original form. There's nothing wrong with such an approach, it is an effective use of the tools involved. In the case of Arri, similar transforms might be used for Arri RAW, but that doesn't mean they have anything to do with what you would call LogC, or final image processing in any way. What is being done is no different than what has been done using "pre-emphasis" in video cameras for years. That was done primarily by taking higher frequencies - which would often "get lost" in normal processing - and raising their value using a specific known transform so that when the signal is passed through normal processing the values are retained and thus the signal to noise ratio is increased. In modern digital cameras, the problem is not really signal to noise, but storage and compression efficiency, so techniques are used to make that a smoother, more effective path.

Now, when image reconstruction is done, the considerations are different. At that point, what's needed is the most accurate interpretation of the original image that was captured. And further, a way to pass the information as completely as possible to image processing pipelines. In that world, real time processing is often needed and thus the data rate must be limited to a practical size. Traditionally, 10 bit image containers have been used, but with the increase in processing power developed over the last few years, it is probably practical to increase that today, hence the talk about 12 bit and 16 bit containers, as well as the half float container proposed by the current IIF/ACES specification. But in any of these formats, to efficiently fit a large amount of image data into a limited sized container, log coding is very effective, because it is similar to the human response system, and therefore allows for "pre emphasis" of important image detail regions and less precision to describe extremes that the eye is not as sensitive to. Log C is in effect another incarnation of the Cineon log curve first developed by Kodak for digitizing film negative. It is a 10 bit log coded container that effectively can store 14 bits of linear image information. RedlogFilm essentially uses an identical curve, which is one reason you can use the same LUT for either one and get good results. However, because Red has opted to perform the image reconstruction outside of the camera, the image supplied when using RedlogFilm already has a color matrix applied, which is done during the image reconstruction. In Arri's case, when video output is used - as it is for either direct video recording or on board ProRes recording - the reconstruction processing is done inside the camera, so what is provided is a fully reconstructed RGB image. If LogC encoding is used on that image, it does not have a color matrix applied unless specifically chosen, which is why the LUTs you create using their Web based LUT builder can either incorporate a matrix or not. But if you're recording Arri RAW, you're creating much the same situation as with Red, except for the compression part. So at that point, you don't have an RGB image, but you have information that might - and probably does - differ from the exact values coming off the sensor because of transforms used to increase storage efficiency, NOT actual image processing.

Hope that makes sense. I got a bit long winded there, but I've been known to do that......

[M Most]

Agreed, I guess I should have specified: I mean saturation settings in direct-raw adjustments made in direct-raw software - I have (I think I have) seen this phenomenon in Resolve, PPro, and Redcine X when looking at RedRaw directly.

That's very likely, because all of those programs incorporate Red's SDK, which performs those functions identically to Redcine X prior to handing off the resulting RGB image to their own color processing engines. Red has done that by design, so that any software you use will yield the same results and use the same reconstruction algorithms, which in turn produces consistency across software platforms, as well as a simple color management system.