Welcome to our community

Be a part of something great, join today!

Log in
  • Hey all, just changed over the backend after 15 years I figured time to give it a bit of an update, its probably gonna be a bit weird for most of you and i am sure there is a few bugs to work out but it should kinda work the same as before... hopefully :)

Dragon Skin...

I'm 99% certain the issues people have with grain in this footage is their monitor. This was the bane of the hvx200 days... HD cameras viewing on computer monitors.

When I view MX on a trimester OLED or even a Panasonic, or Flanders I don't see the midtone noise.... Especially in this stuff.

Paris, what are you viewing on?
 
Paris Remillard said:
I hope i can make this comment/observation without ruffling feathers, but I still see green in the mid tone/transition areas in skin on both this test and the Collister test. It's something that I've always seen with my MX Epic, and when I bring it up everyone quickly dismisses it as a make-up issue, even when it's on male subjects with no make-up... I also find that if I shoot under less than ideal fluorescents or LEDs, with my stills camera the green is easily corrected, but with my Epic on exactly the same set-up, I can't get rid of the little bit of green in those transition areas no matter how hard I try. Anyone else have this issue?
Click to expand...

I'm on a calibrated monitor and didn't notice any green tint in the mids. Is your monitor calibrated?
 
Sanjin Jukic said:
just because that is the main issue of any digital camera, especially so called cine digital cameras.

Experts should finally write an appropriate workflow for cine digital RAW colour correction!!!
Click to expand...

Evin Grant said:
Sanjin, Resolve does work off the R3D (although not Dragon yet) so I don't see your point.
Click to expand...

Not just Resolve either. Nearly every professional grading suite has native R3D support. There was a time when this wasn't true, however, it's 2013 and there's many ways to manipulate REDCODE's color.

Each unique program has it's own particular workflows that come with it. Most use some sort of variation of importing an EDL/XML if you have an a timeline to be concerned about. Heck, Resolve 10 actually has a much better built in timeline/edit mode.

We're going to see more of that on the horizon. Adobe already supports Speedgrade's .look and of course you can import LUTS to most NLEs these days too.

Personally I use and enjoy Redcine-X Pro, Resolve, Speedgrade, and Baselight. Sometimes I'll do a quicky CC with Looks, Premiere Pro, or even After Effects for certain things. There's very little creative restriction on what you can accomplish these days via a color workflow.
 
Timur Civan said:
I'm 99% certain the issues people have with grain in this footage is their monitor. This was the bane of the hvx200 days... HD cameras viewing on computer monitors.

When I view MX on a trimester OLED or even a Panasonic, or Flanders I don't see the midtone noise.... Especially in this stuff.

Paris, what are you viewing on?
Click to expand...

It's a myth that there is any longer such a thing as a "video monitor" different from a computer monitor.

Either can be calibrated or not. SRGB color space is the same as Rec 709 color space, same gamut/primaries. Some say the Rec 709 should have a steeper gamma curve, but there is no "official" gamma curve for Rec 709, so this is debatable.

Some devices can only output YUV (many Blu-Ray players) vs a Computer's RGB space - but the conversion from YUV to RBG is 100% lossless and simple, and anyway this is just two different mathematical notations of the same exact colors. Then there is video-limited vs full luma range - again easy math conversion with no specific monitors required, just use of the right setting at both ends.

In the old days CRTs were different as they could display an interlaced signal. Almost no modern display can natively display an interlaced signal, they must de-interlace first, which is why wise people always master on a progressive timeline, and only convert to interlace as a last pass for 1080i broadcast (you don't want those field to represent different moments in time, as they will be displayed as just ugly combing if you do).

So... A computer monitor, a "video" monitor, they are exactly the same. There are only accurate monitors and uncalibrated ones.

I don't see how a monitor could add noise - although consumer monitors have noise-reduction which one should never use for mastering and pro work. It's there or it's not, and if a monitor has crushed blacks you won't see it as much, but you would anyway if you did any grading that brought up the blacks.
 
Robert Ruffo New said:
...SRGB color space is the same as Rec 709 color space, same gamut/primaries. Some say the Rec 709 should have a steeper gamma curve, but there is no "official" gamma curve for Rec 709.... So... A computer monitor, a "video" monitor, they are exactly the same. There are only accurate monitors and uncalibrated ones.

I don't see how a monitor could add noise - although consumer monitors have noise-reduction which one should never use for mastering and pro work. It's there or it's not, and if a monitor has crushed blacks you won't see it as much, but you would anyway if you did any grading that brought up the blacks.
Click to expand...


Robert is right in that the sRGB and Rec.709 share the same coordinates of primaries colors, and even in most places both are defined with the same gamma (2.2). The only difference is, more like a recommendation, to have the HDTV at 150 cd/m2, and the sRGB is at 120 cd/m2. And the difference is mainly due to an obvious issue of potential locations of the HDTVs (most of the times without lighting intensity control).

In my experience, in professional monitors I think that due to the precision of their signal circuit, they do a better job at decoding information, hence no extra noise of what really is part of the original footage is added.

Again, that is my experience. Hope this helps...
 
The image metrics of computer monitors vs televisions includes several synergistic qualities and typically reflects different design considerations based on intended use/price point. One can certainly get pleasing skin tones and legible text on the same display, but can you do it at a rational price point for market conditions? Beyond that, how many people will put a 50" display on their desk or a 24" display in a good sized living room or den?

In 2013 it could be argued that much of this discussion is moot anyway as many people now watch "TV" on their cell phones, so what do I know...

Cheers - #19
 
Luis Otero said:
Robert is right in that the sRGB and Rec.709 share the same coordinates of primaries colors, and even in most places both are defined with the same gamma (2.2). The only difference is, more like a recommendation, to have the HDTV at 150 cd/m2, and the sRGB is at 120 cd/m2. And the difference is mainly due to an obvious issue of potential locations of the HDTVs (most of the times without lighting intensity control).

In my experience, in professional monitors I think that due to the precision of their signal circuit, they do a better job at decoding information, hence no extra noise of what really is part of the original footage is added.

Again, that is my experience. Hope this helps...
Click to expand...

A cheap plasma will add noise in the blacks, but an LCD simply does not have that capability - they would have to add noise-generating circuits, and why would they do that? Some monitors remove noise (consumer TVs) and you should turn that off to work.
 
RObert Ruffo New said:
Some say the Rec 709 should have a steeper gamma curve, but there is no "official" gamma curve for Rec 709, so this is debatable.
Click to expand...

BT.1886 is now the "official" display gamma curve that goes with BT.709. Its a bit late, but it is official now. Its slowly making its rounds.
 
Thanks Stacey.

I am more than a little bit perplexed that basic definitions for the reference gamma curve have not been properly defined for so long. I do grasp why it didn't have a material impact in a CRT world, but other types of display technology have been prominent for over a decade. :huh:

Cheers - #19
 
Blair S. Paulsen said:
I am more than a little bit perplexed that basic definitions for the reference gamma curve have not been properly defined for so long. I do grasp why it didn't have a material impact in a CRT world, but other types of display technology have been prominent for over a decade.
Click to expand...

Perplexing, I agree! :) My understanding is that because BVMs ruled the world, that they defined the gamma curve and BT.709 did not need to do so. Things became messy when they died off and plasma's, and other display technologies became the norm. Another interesting issue with the BVM is that they had SMPTE C color primaries, and not BT.709. BT.1886 is based off of the gamma curve that the BVMs exhibited. I believe BT.2020 follows the same display gamma curve as BT.1886. sRGB defined both the display and source gamma from the get go.

The problem we face today, on the playback side, is that as a viewer we don't know which gamma curve to use when watching a given show. I know that HBO shows are graded on displays calibrated with a 2.2 gamma curve instead of BT.1886s 2.4.

One thing has not changed as we moved from SD to HD to UHD and that is displays still do not meet system standards. Resolution goes up, but the same technical issues remain. Most of them are on purpose too. :)

Since this is a skintone thread, I should get on topic. :) One must be careful when evaluating skintones on compressed content. Blu-ray is OK given the high bitrate. Vimeo, YouTube, Apple TV, Netflix, etc... is another matter. To give an example. In the show Covert Affairs, I am always bothered by the blotchy skintones. I have only seen on cable and Apple TV. In both cases the extreme compression is introducing some of it. What happens is the chroma channels for a given block round one way (e.g up) and in the next block round the other (down) in value. This introduces a magenta like blotchiness. I have never seen the source, so I don't know how much is in the source vs. introduced by the compression. We saw this a lot when building one of the HD DVD / Blu-ray encoders. If often requires a lot of bits to fix.
 
Stacey Spears said:
Perplexing, I agree! :) My understanding is that because BVMs ruled the world, that they defined the gamma curve and BT.709 did not need to do so. Things became messy when they died off and plasma's, and other display technologies became the norm. Another interesting issue with the BVM is that they had SMPTE C color primaries, and not BT.709. BT.1886 is based off of the gamma curve that the BVMs exhibited. I believe BT.2020 follows the same display gamma curve as BT.1886. sRGB defined both the display and source gamma from the get go.

The problem we face today, on the playback side, is that as a viewer we don't know which gamma curve to use when watching a given show. I know that HBO shows are graded on displays calibrated with a 2.2 gamma curve instead of BT.1886s 2.4.

One thing has not changed as we moved from SD to HD to UHD and that is displays still do not meet system standards. Resolution goes up, but the same technical issues remain. Most of them are on purpose too. :)

Since this is a skintone thread, I should get on topic. :) One must be careful when evaluating skintones on compressed content. Blu-ray is OK given the high bitrate. Vimeo, YouTube, Apple TV, Netflix, etc... is another matter. To give an example. In the show Covert Affairs, I am always bothered by the blotchy skintones. I have only seen on cable and Apple TV. In both cases the extreme compression is introducing some of it. What happens is the chroma channels for a given block round one way (e.g up) and in the next block round the other (down) in value. This introduces a magenta like blotchiness. I have never seen the source, so I don't know how much is in the source vs. introduced by the compression. We saw this a lot when building one of the HD DVD / Blu-ray encoders. If often requires a lot of bits to fix.
Click to expand...

The color grade on Covert Affairs (and the cinematography) frequently leaves a lot to be desired, and I have seen the show on PS3 download, which uses very reasonable amounts of compression. It's just an ugly show, that often looks cheap and visually dated. That's not Red's fault mind-you.
 
Gabriele Turchi said:
i thought the EPiC was advertised also 16 bit ...

g
Click to expand...

I've always been a bit confused on this point. And I think, unless I missed some information somewhere. Red has never been very clear on what the color depth of the Epic is. From my understanding they use 16bit processing, but it has 12 bit color depth. That would explain why on the Epic MX spec sheet it still shows 12 and 16bit RAW. Even though we never had the choice between the two. Always good to hear that there will be better color precision :)
 
Which in retrospect is kind of bogus/hype-inducing-fud -- RED should have just said it's 12bit.... Saying "yeah but it's essentially 16bit" - which is what they've been saying since Epic has been out - is like saying that DSLR 8-bit 420 footage rendered out to Prores or DNxHD is 'essentially 10/12bit 422' because that's the container it's been rendered to for finishing.... Very annoying now that the cards are on the table, especially when people explicitly asked a bunch of times.

But I digress... I do think that, for the most part, what we've seen of Dragon is very much like MX, just with 3+ more stops (try a static HDRx shot and compare please Tom/Peter/Mark/Whomever-else-has-Dragon-access)... Those extra stops of info would account for quite a bit of difference in the mid-tones (as well as anything else in the image.) I'm kind of excited to see what RG4/RC4 is going to do with Dragon footage... HOPEFULLY some of those improvements actually trickle down to MX, but something tells me trying to retrofit an MX image to behave more like a Dragon image will *not* be that easy... It'll basically take a colourists entire bag of tricks to get them to somewhat match (assuming you're trying to get the MX to look like Dragon and not downgrading the Dragon to look like MX.)
 
Last edited:
Michael Lindsay said:
epic X has a 16bit AD but the pictures are carried in a 12bit container R3D...(never know if this was linear or ?..)

I believe Dragon will allow 16bit all the way...
Click to expand...

To me, this sounds like the most likely description of things. Which I in no way find "bogus"

The Digibeta used (I think) a 14 bit AD downsampled to an 8 bit 4.2.2, but thus had a lot of good things in its images that I think many HD TV-cams still struggle to replicate.

We will want more bits in the AD, than we eventually will want for delivery, because the bits have different functions in the different stages of the process, and actually I think noone wants to replicate the DR of nature (say sun vs alley= in an image... at least not without giving us sunglasses to view the images...

Even if the Dragon is 16-bit half float, and not 16 bit linear (now I am talking about the files), I see no reason to call that bogus...
And neither have any others called such a solution for deliverables bogus...

There is also some point where oversampling in precission in aquisition vs delivery borders on "enough"... without trying to specify that.
 
Don't get me wrong -- 12bit or 16 bit, I don't think the images REDs create are bogus... but I do think it's kinda weak that every time someone said 'the math says it's actually creating 12bit images', RED almost always chimed in with, 'it's actually, essentially, 16bit -- RED1 was 12bit, though' when that just isn't the case... Again, I point to the DLSR-to-Prores example; no one would say that transcoded DSLR footage is actually 12 or 14bit even though the DSLR's sensor and A/Ds are 14bit and the codec the footy is likely transcoded to is 10-to-12bit... Again, it's a little fuddly, is all I'm saying. Not something to sweat about.
 
Last edited:
You must log in or register to reply here.
Back
Top