EPIC MX Highlight Rolloff thread....

[António Fagundes]

I have followed this thread with great interest. Sometimes I felt like my head was spinning but it has been educational. I just thought I would help lighten things up a bit and hope Antonio gets that this is just a joke, meant to add levity to the conversation, not to be offensive in any manner...

Antonio, which camera was used for your avatar? ;-)

I previously responded to you question thinking that I had read: 'Antonio, which camera was used for Avatar?'... and I responded Sony's!

Then, I read your question more clearly and realized you asked about MY avatar...

It was on iPhone. Instagram I think.

 

[David Battistella]

No one is trying to make you sound like a fraud Antonio.

david

 

[Luis Otero]

After so many constructive comments, you come with this dud post :-(What's up with all the closed threads, deleted comments and banned members lately? I say this with all due respect...

Well, it seems that during my 4 1/2 hours of sleep, after suggesting to close the tread, things here have taken other turn for the best, and other important players and perspectives have been added, so that the discussion is worth to be continued.

My only respectful request is that we stick to this interesting topic, and stop trying to use the thread to convince someone that obviously made his mind to use Alexa. This even after a plethora of well founded postings by people that know what they are talking about has been posted to address his main concern voiced in the first place. That was the main reason for me to suggest closing the thread. In summary: let's talk about highlight rolloff and the ancillary effects and artifacts, and stop aiming the postings to a specific person(s).

Does this make sense?

Respectfully,

 

[David Battistella]

OK.

here is a lens test video to illustrate how much of an effect something like lens coatings have on highlights and flaring. The test was shot on ARRI ALEXA, but that is not why I am introducing it, it's more to show how uncoated vs coated lenses behave with strong highlights. It's to compressed to jusdge anything else.

The flares are cool though.

David


https://vimeo.com/61903188

 

[David Battistella]

Well, it seems that during my 4 1/2 hours of sleep,

you need to get more sleep

david

 

[Scott Crawley]

In other words, assuming the brightest luma value the sensor is capable of producing is captured before the overload begins, are you really getting any more luma info at that point or is it fixed? I guess the same question applies even if the brightest value the camera records is the already overloaded (clipped) value.

The sensor does not create luma. It is not a display device. What it does is translate the levels of light that it can sense into values that a display system can use. It is an analog to digital converter. So it takes the absolute brightest value it can sense and assigns it a numerical value at the top of an established scale that a display device can then use to rebuild the image digitally. As far as the sensor is concerned that is the brightest thing there is, and that is all the display needs. The display can not recreate the brightness of the sun, so it does NOT need to know the actual intensity that was present as an absolute value. It is relative. There is no eleven.

Dragon can sense a broader range of values...It can identify higher intensities, but it (or we) still translate them into the same relative scale. That broader range of values is why Dragon can make use of a higher bit rate to relay it's data. It allows the system to translate that broader range of values into the same relative scale with more granularity.
Edit: Actually I think I mis-stated that. At a higher bit depth, the scale itself is more granular. I think. Either way the end result is more precise, even if your display device is incapable of reading that 16-bit scale.


Does that make any sense? It may not be 100% accurate, but this is the rudimentary way in which I understand it.

 

[Luis Otero]

you need to get more sleep

david

David,

Yes, I wish. But my brain is the boss, and if it commands me to awake after short period of time, there is nothing I can do...

Thanks for posting this video. I think this support my previous statements. The "uncoated" lenses proved that when uncontrolled clipping/overloaded is forced by having the light directly hit the sensor, the magenta artifact is clearly there, regardless of the camera (Alexa, in this case). Specially since the Color Space conversion is done, in this case by Vimeo's "video optimization" (from probably Rec.709 to sRGB, since Vimeo targets computer monitors).

It seems that the coating served here as the mean of controlling the clipping/overload. Very, very interesting. It would be nice to watch this video without passing it through the Vimeo's optimization in order to identify the amount of effect and artifacts present before color space conversion.

Does anybody know if the original video can be seen somewhere else, as shot and without color space manipulation?


Thanks again, sir!

 

[Luis Otero]

The sensor does not create luma. It is not a display device. What it does is translate the levels of light that it can sense into values that a display system can use. It is an analog to digital converter. So it takes the absolute brightest value it can sense and assigns it a numerical value at the top of an established scale that a display device can then use to rebuild the image digitally. As far as the sensor is concerned that is the brightest thing there is, and that is all the display needs. The display can not recreate the brightness of the sun, so it does NOT need to know the actual intensity that was present as an absolute value. It is relative. There is no eleven.

Dragon can sense a broader range of values...It can identify higher intensities, but it (or we) still translate them into the same relative scale. That broader range of values is why Dragon can make use of a higher bit rate to relay it's data. It allows the system to translate that broader range of values into the same relative scale with more granularity.
Edit: Actually I think I mis-stated that. At a higher bit depth, the scale itself is more granular. I think. Either way the end result is more precise, even if your display device is incapable of reading that 16-bit scale.


Does that make any sense? It may not be 100% accurate, but this is the rudimentary way in which I understand it.

Scott,

I like the way you presented and analyzed this topic., specially emphasizing the fact that the sensor IS NOT a display devise, so it cannot create luma, just records it to the best of its ability based on the design.

I think your edited comment is very appropriate, and holds very well the truth. The sensor, being 16 bit, has a broader range, hence the scale is bigger. The only situation that precludes us to see all recorded values is, as you mentioned, the display devise capability, or lack of. That is the scale/range bottleneck.

That is why we must be sure that we are evaluating the footage with a devise that can process at least 10 bits, if not 12 bits based on the fact that the new image acquisition technology has gone up so rapidly.

 

[Gunleik Groven]

Luis, you can download the original from vimeo...

 

[Luis Otero]

Luis, you can download the original from vimeo...

The one on there is not the original since it has been color space converted by Vimeo to sRGB. I was referring to some other place (ftp, etc) that does not "optimize" the footage. I suspect that it was rendered for Rec.709, but as I mentioned before, Vimeo converts it to sRGB since the 90+% of its audience will view if on a basic computer monitor, which is set for the sRGB color space.

Now, if the original was captured and rendered for such color space, it will have same artifact.

 

[Scott Crawley]

So at the point of capture (the unmodified sensor data) Exists on a scale with more subdivisions. That scale is handed off to where it is encoded at the compression setting we chose, but remains 16-bit. Redcode does not presumably use this aspect of the signal to compress the data.

It is reduced in bit rate at some other point in the chain on it's way to the display (and ultimate file format), hopefully but not necessarily after we perform our operations on it. That is dependent upon our image editing software, graphics cards and other display hardware.

Is that right?

Scott,

I like the way you presented and analyzed this topic., specially emphasizing the fact that the sensor IS NOT a display devise, so it cannot create luma, just records it to the best of its ability based on the design.

I think your edited comment is very appropriate, and holds very well the truth. The sensor, being 16 bit, has a broader range, hence the scale is bigger. The only situation that precludes us to see all recorded values is, as you mentioned, the display devise capability, or lack of. That is the scale/range bottleneck.

That is why we must be sure that we are evaluating the footage with a devise that can process at least 10 bits, if not 12 bits based on the fact that the new image acquisition technology has gone up so rapidly.

 

[Luis Otero]

So at the point of capture (the unmodified sensor data) Exists on a scale with more subdivisions. That scale is handed off to where it is encoded at the compression setting we chose, but remains 16-bit. Redcode does not presumably use this aspect of the signal to compress the data.

It is reduced in bit rate at some other point in the chain on it's way to the display, hopefully but not necessarily before we perform our operations on it. That is dependent upon our image editing software, graphics cards and other display hardware.

Is that right?

Scott,

In Resolve you have the ability to set the Red footage at 16 bit. It will allow you to monitor it at 10 or 8 bit, but the final product, would you select to render at 16 bit, will contain all the scale of the original footage.

BTW, Resolve, to the best of my knowledge, operates in a 32 floating point, but by selecting 16 bit at the Red RAW decoding settings, it will preserve all the scale. It is up to you to get the final footage as 8, 10, 12?, and 16 bit. Now Resolve offers TIFF 16 bit rendering, which is great if you will process a DCP. DCI specs require to have the footage at 16 bit.

 

[M Most]

DCI specs require to have the footage at 16 bit.

Unless it's been changed on the latest revision, a DCP is specified to be 12 bits, not 16. Since there is no common 12 bit TIFF container, most vendors write the DCDM (the "original" data for the DCP, prior to J2K compression) in a 16 bit container. But the DCP itself is 12 bits wide.

 

[Scott Crawley]

OK, excellent. that is a stop on the way to my ultimate point, for those who care.

If you take a 16-bit image and cram it into an 8-bit jpeg container such as this

[

a chunky transition is what you get.

Imagine that you have three sticks of equal length. One you break into 16 pieces, the second into 12 pieces and the third into 8 pieces. Then you put each stick back together using a piece of string, and bend each of them into the same curve. The 16 segment curve will give you the softest bend, and the 8 segment curve will be the most angular and the roll off will look like shit.

This is one reason why the transition in the picture above is not smooth. The transition from light to dark is made in fewer increments and the roll off's shoulder (the portion of the curve with the sharpest change in angle) is that area where the transition appears most abrupt. If the source image is from a Red camera, this is not what the sensor produced. This is the compression that a previous poster was pointing out. (Sorry, I will credit you by name in an edit.) I am looking but not finding, sorry. Please hold up your hand for us.

The author of this image may have a 12-bit or higher image on their system that looks just as poorly. In that case my next question would be "What math was used to apply this manipulation? Was it done in 12 or 16 bit?"

Scott,

In Resolve you have the ability to set the Red footage at 16 bit. It will allow you to monitor it at 10 or 8 bit, but the final product, would you select to render at 16 bit, will contain all the scale of the original footage.

BTW, Resolve, to the best of my knowledge, operates in a 32 floating point, but by selecting 16 bit at the Red RAW decoding settings, it will preserve all the scale. It is up to you to get the final footage as 8, 10, 12?, and 16 bit. Now Resolve offers TIFF 16 bit rendering, which is great if you will process a DCP. DCI specs require to have the footage at 16 bit.

 

[Eric Z]

OK.

here is a lens test video to illustrate how much of an effect something like lens coatings have on highlights and flaring...

Thank you for that.
It seems lens coatings play a significant role in keeping lens flares in check.

 

[Daniel Stilling]

I think that one thing that just got touched on slightly a few pages back, but plays a major role on how highlights (and the rest of the picture for that matter) behave are lenses. Lens choice is of fundamental importance in this, as is filtration (and I'm not talking low-con, I'm talking good versus crappy ND's for example), aperture. So many variables, but I believe if you know how to use all these tools, and you use decent ones, your highlights will be just fine.
Honestly, if Deakins doesn't like RED because he has to get exposure right, he's gotten too comfortable in being sloppy, but somehow I don't think that is the case as he wouldn't have gotten where he is by being a sloppy DP...

 

[Luis Otero]

Unless it's been changed on the latest revision, a DCP is specified to be 12 bits, not 16. Since there is no common 12 bit TIFF container, most vendors write the DCDM (the "original" data for the DCP, prior to J2K compression) in a 16 bit container. But the DCP itself is 12 bits wide.

Mike,

Agree. However, somewhere that I cannot recall right now (I will post it when I find it), there was a very technical explanation as to why starting with a 16 bit image (being TIFF or DPX), is necessary for DCP authoring. It explains that during the encoding process, some bits are discarded. So, by having a 16 bit image as a starting point, it will assure to end up with a robust 12 bit JPEG 2000 image sequence that can be wrapped in the MFX file.

I have tried a "non-intelligent" DCP encoder, starting with a 10 bit DPX sequence, and the resulting DCP saturation and brightness is out of whack, nothing close to the original DPX sequence.

Now, there are "intelligent" DCP authoring softwares that have an algorithm which analyzes the source footage, even if it is not 16-12 bit, and performs adjustment so that the final product is equivalent to the original footage's Chroma and Luma characteristics. For example, the new version of QuVIS Compressor plug-in does such analysis. Previous version did not do it.

 

[Luis Otero]

OK, excellent. that is a stop on the way to my ultimate point, for those who care. If you take a 16-bit image and cram it into an 8-bit jpeg container such as this, a chunky transition is what you get.

[



Imagine that you have three sticks of equal length. One you break into 16 pieces, the second into 12 pieces and the third into 8 pieces. Then you put each stick back together using a piece of string, and bend each of them into the same curve. The 16 segment curve will give you the softest bend, and the 8 segment curve will be the most angular and the roll off will look like shit.

This is one reason why the transition in the picture above is not smooth. The transition from light to dark is made in fewer increments and the roll off's shoulder (the portion of the curve with the sharpest change in angle) is that area where the transition appears most abrupt. If the source image is from a Red camera, this is not what the sensor produced. This is the compression that a previous poster was pointing out. (Sorry, I will credit you by name in an edit.) I am looking but not finding, sorry. Please hold up your hand for us.

The author of this image may have a 12-bit or higher image on their system that looks just as poorly. In that case my next question would be "What math was used to apply this manipulation? Was it done in 12 or 16 bit?"

Scott,


Exactly! Trying to present an original 16-10 bit image as an 8 bit one, banding is going to be present no matter what, specially in both extremes of the Luma (bright or dark).

Most TV that are out there (and computer monitors) still contain processors and panels that are capable to only present 8 bit images. Or even if you have newer TV/Monitors with 10-12 bit processors, if an 8 bit image like that is transmitted, it can easily be misinterpreted as a harsh roll-off. As an experiment, try it at your home, or in your high-end monitor.

Due to band-width and compression limitation for broadcasting, many programs that you see, if you pay detail attention you will see some level of banding. I see it all the time, and I cannot stand it. And I observe it with HD cable TV, with a 12 bit processor/panel HDTV.

To answer your question about math manipulation used to obtain the 8 bit image, it is inheriting of any 8 bit image to show banding, because bits have been discarded, and strong gradation stops are seen.

Hope this helps,

 

[Scott Crawley]

Thanks Luis,

If all of this is true and the author has their original R3d, the good news is that the footage can be re-graded, and an easier transition is likely possible. This footage can yet be improved by a knowledgable Colorist if the desire exists.

Scott,


Exactly! Trying to present an original 16-10 bit image as an 8 bit one, banding is going to be present no matter what, specially in both extremes of the Luma (bright or dark).

Most TV that are out there (and computer monitors) still contain processors and panels that are capable to only present 8 bit images. Or even if you have newer TV/Monitors with 10-12 bit processors, if an 8 bit image like that is transmitted, it can easily be misinterpreted as a harsh roll-off. As an experiment, try it at your home, or in your high-end monitor.

Due to band-width and compression limitation for broadcasting, many programs that you see, if you pay detail attention you will see some level of banding. I see it all the time, and I cannot stand it. And I observe it with HD cable TV, with a 12 bit processor/panel HDTV.

To answer your question about math manipulation used to obtain the 8 bit image, it is inheriting of any 8 bit image to show banding, because bits have been discarded, and strong gradation stops are seen.

Hope this helps,

 

[Luis Otero]

I think that one thing that just got touched on slightly a few pages back, but plays a major role on how highlights (and the rest of the picture for that matter) behave are lenses. Lens choice is of fundamental importance in this, as is filtration (and I'm not talking low-con, I'm talking good versus crappy ND's for example), aperture. So many variables, but I believe if you know how to use all these tools, and you use decent ones, your highlights will be just fine...

Bold statement, but you got it 100% right, my friend. That is one of the most important differences that separate decent from excellent DPs.

Tell me about it... I see any kind of footage brought to me for grading, and everyone, even if the footage is 8 bit , wants it to look like film. I mean, there is so much that can be done to emulate a style, but we are not magicians.

BTW, ProRes HQ footage is 8 bit. Even some .mov uncompressed files are 8 bit, depending on what software was used to generate them (FCP 7 and Compressor generates 8 bit, but Resolve generates it at 10 bit). However, ProRes 4444 is 10 bit.