Welcome to our community

Be a part of something great, join today!

Register 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 aliasing color shift

The green channel does have twice as many pixels, which could be twice as "accurate/sensitive" compared to the r and b channels, which (when compared to green) would have "aliasing" perceived as additional sharpness.

Blue could be softer than red merely because of how much tighter/inaccurate/harder-to-read the wavelength is, which are inherently weaker on CMOS as a result. And since red has slow and fat wavelengths, they get read nice and thick.

...That said, all CMOS have this, so it'd be interesting to know how Arri are compensating (assuming that is what's happening). Conversely, it'd be rad to be able to squash this with software as it'd make perceptively sharper images...

Too bad they didn't have MX to compare as well.

NOTE: Take everything I've written with a large helping of salt. Nothing but the best Backyard Science/Hypothesis in this post.
 
REDCode doesn't encode Red, Green and Blue. It appears to compress in something similar to HSV or YUV. So the fact that one channel is affected is somewhat arbitrary. Whichever channel has the most luma detail will be the sharpest. Whichever channel is most dependent on hue or saturation will be most compressed.

Also note that the image I posted is from an MX not dragon.
 
AFAIK, RedCode is a JP2K (jpeg2000/also used for DCPs) variant that uses a wavelet scheme known as an entropy encoder. What that means in visual terms, is that as the compression starts breaking down, it gets softer in the highest frequency detail vs the macro-block artifacts common in MPEG-2 and in some DCT implementations.

Sidebar: Entropy encoding schemes are brilliant in some respects, but traditionally disdained in high end post (up until DCP authoring) where less mathematical rounding is preferred over a codec biased toward being visually lossless (sic). AFAIK, RED is encoding the sensor voltages after A/D conversion directly into RedCode. When that data set is interpreted by the decoding algorithm the result is an RGB image constructed per the product of complex calculations that can be assigned lots of discrete code values. To actually take that precision into the post pipeline you just need to dedicate the storage space required to use a robust mezzanine format like 10 bit log DPX, 16bit TIFF (ouch), OpenEXR (more TBs of storage eaten alive) or maybe ProRes444XQ? Of course creative editorial can be done via proxies with a finish from hero media as desired to accommodate user hardware capacities.

Cheers - #19
 
Anyone have a high contrast image shot without the OLPF we could look at?
 
The way I understand it, the algorithm is "tuned" to a certain amount of focus inversion per the metrics of the OLPF. If there is no OLPF, then you would not only get some aliasing at the sensor mask, but the algorithm might actually make it worse during image construction.

Cheers - #19
 
Blair S. Paulsen said:
The way I understand it, the algorithm is "tuned" to a certain amount of focus inversion per the metrics of the OLPF. If there is no OLPF, then you would not only get some aliasing at the sensor mask, but the algorithm might actually make it worse during image construction.

Cheers - #19
Click to expand...

Well, the movie Les Dittert posted without the OLPF was hella sharp. I also remembered someone posting a picture of a street sign shot without the OLPF, but I couldn't find that.
 
Blair S. Paulsen said:
AFAIK, RedCode is a JP2K (jpeg2000/also used for DCPs) variant that uses a wavelet scheme known as an entropy encoder. What that means in visual terms, is that as the compression starts breaking down, it gets softer in the highest frequency detail vs the macro-block artifacts common in MPEG-2 and in some DCT implementations.

Cheers - #19
Click to expand...


Right but like all compression is has to throw away data from somewhere. In my testing REDCode maintains the luma channel at nearly all costs while discarding high frequency detail in the chroma channel first. Which is smart since the human eye is terrible at seeing chroma detail. But it does have side effects like I believe this one where the hue/saturation is being softened but not the luma. So like 4:2:2 you get chroma 'bleed'. I think what also happens is that in areas without saturation or extreme saturation when the bayer image is reconstructed from the HSV REDCode pre-magic there can be 'flip' zones going from 0 hue to 1.0 hue since they are technically adjacent on a rotation wheel but trying to spatially compress a value that loops I imagine is a chore.

Mark Wilkinson said:
Well, the movie Les Dittert posted without the OLPF was hella sharp. I also remembered someone posting a picture of a street sign shot without the OLPF, but I couldn't find that.
Click to expand...

Pretty sure he stated in that same thread that he was using "magic sauce" in his OLPF free tests. There is a critical assumption you're making that might not be true.
 
True enough.

Hopefully, it can be improved in any case.
 
Ok, I know it's taken me a while but I think I've finally been able to get to the bottom of this.

First step was to duplicate the issue here. I used my Dragon, LLO OLPF, Canon mount (because I have more Canon lenses than any other type, and some Canon cameras too for comparison), my trusty sine zone plate, and a RED Cambook.

To duplicate the issue I focused in carefully on the brightest detail area of the zone plate and chart (with nice clear white on black text). I set the camera to REDLogFilm (as that most clearly shows the issue in post) and boosted the saturation to make it easier for me to see live. As the plane of focus moved through the objects on test, I could easily see the green glow. This is happening in camera, so compression is now ruled out. As I moved focus from behind to in front of the chart, I could see the glow go from purplish through neutral through to green on the other side. Stopping down the lens reduced then made negligible the glow.

Then I swapped the Dragon out for my Canon 1D MK III, set live view mode on and zoomed in pixel-for pixel on the back LCD, repeated the test with the same lens and I observed the very same glow, although it was clearer once I took my stills into Lightroom and lowered the contrast (to somewhat replicate the low contrast look of REDLogFilm).

Conclusion is that this is axial chromatic aberration from the lens.

Graeme
 
Thank you for taking a hard look at this.

But it leaves us with the lingering question of why the Alexa charts do not show the same soft green channel effect, does it not?

I'm not really arguing that CA isn't an issue - it's nearly always present when you go this far in - I'm rather just drilling down into the other issue.

I'm shooting a bunch of charts today and will look to see if the same thing is present...
 
Last edited:
Maybe that's where the plane of focus was. If the chart is precisely in focus, you don't get this kind of chromatic aberration. As I noted, I was easily able to duplicate the issue on the Canon here, so this is not a RED specific issue.

Graeme
 
If you could you post the in focus chart from both cameras, that would be helpful. Thanks for taking a look, in any case.
 
I took some comparisons one one of my early tests before I was able to demonstrate to myself it was not a compression or demosaic issue. I think the order of the shots is wrong as they both get the same colour chromatic aberration depending on whether the plane of focus is in front of or behind the object.

Graeme
 

Attachments

  • canon.jpg
    canon.jpg
    97.8 KB · Views: 0
  • dragon.jpg
    dragon.jpg
    101.6 KB · Views: 0
Ok, that Dragon chart absolutely did NOT have the soft green effect in the high contrast areas.

Which tells us that the Red charts were probably out of focus and the Alexa not. Doh.

I'm going to duplicate this test today and will post just for more grist.
 
So the test confirmed basically exactly what Graeme was saying. That never happens :)

In other news, anyone know what causes this type of noise?
 

Attachments

  • blue.jpg
    blue.jpg
    28.4 KB · Views: 0
  • green.jpg
    green.jpg
    16.1 KB · Views: 0
That one cyan pixel? What was the exposure time?

Graeme
 
180 shutter@ 23.98
It was 5:1 shooting 6k

It does move with the noise as in the above thread Bjorn posted.

It looks a lot like film noise, so I'm not sure it's a real problem - I was mostly curious how it is generated.
 
Last edited:
You must log in or register to reply here.
Back
Top