"Black Sun" Revisited - RAW Processing Bug?

[Jeff Kilgroe]

I'm posting this up quick while I'm thinking of it. The two images here don't illustrate this well at all. So I'll round up some better images later...

Working with my footage that shows the infamous "black sun" or dark grey / purple spot in bright flares, I'm able to recover information out of that dark spot. It behaves just like an error with some sort of clipping threshold. The threshold seems to be defined or influenced in relation to which ASA the RAW image is being "exposed" for. A higher ASA value appears to raise the threshold, lower ASA values lower it.

The "black sun" or sensor protect or whatever we call it, appears to be pixels that have exposure values extending beyond this limit or threshold. At this limit, instead of simply being left at a 100% luma value, it's as if they're being rolled-over to zero. Increasing the ASA seems to change that upper limit and much of the dark or black pixel data no longer "rolls over" (assuming that is what is happening) and it remains white or at a 100% luma value.

So I'm thinking that the "black sun" is completely fixable and may even be a bug in how the camera, REDCINE and RED Alert all interpret the RAW data as the anomaly is present in the camera outputs as well the software tools.

This image is a 1:1 crop showing a flare with slight "sensor protect" artifacting. Shot / exposed for ASA 320.


The exact same frame from the same R3D file, but exposed for ASA 400. The "sensor protect" artifacting has disappeared.

[Graeme Nattress]

It's a sensor thing, not a processing thing.

Graeme

[Brook Willard]

Will it ever be possible to map the sensor to turn those super-clipped areas to white instead of purple?

[Graeme Nattress]

I leave that kind of thing to the sensor gurus at RED.

Graeme

[Jeff Kilgroe]

Thanks for the response, Graeme. I remain hopeful that a solution will be found. At least I'm finding that it's pretty easy to compensate for the effect, or even eliminate it, in REDCINE. Severe instances of the anomaly will probably have to be dealt with by tracking and removal in other software.

[Deanan]

We are working to fix it but for now pushing up the highlights a bit will correct for the pink sun.

[Andrew Benz]

Thank you Deanan, this is great news.

[jjrecort]

well.. I'm no sure it's a CMOS issue, maybe the purple area showed on the picture is.. but what I get si not...

Because the If I render to DPX files purple pixels are gone... but the effect it's different.. mine look like real dead purple pixels..maybe is not the same issue..

[Graeme Nattress]

JJRecort, I need to see that R3D file from that shot to debug, and what version you're using to get that error.

Graeme

[jjrecort]

Thanks Graeme, I will upload to my FTP the smaller R3D file I have where the problem appears.

Shots was done on Studio, at 3200K - 320ASA - 2K - 50 and 100 fps
Can not tell now if we where using build 13 or 15 (should ask to cam operator)
Now with the experience I think we shot a little bit overexposed.

All is up to date on the REDCODE; REDCINE, REDALERT software side.

I'm my case I have tried in two Macpros

one Macpro (prior to JAN08) with 10.4.11 it's happening always, whatever you use REDAlert, Crimson, or REDCine, whatever Codec it's chosen. Only rendereing DPX files with REDALERT it's working fine.

On my other Macpro (post jan08) I'm having the same issue but only if I render with RedCine.. the weird purple pixels are appearing on some parts of my shots... If I manually render with redalert, or Crimson shots are rendered okay...

BTW.. we meet in person the last -manufacturer's -day at IBC.. I was one of the hundreds of skeptics not believing how to fit 4K on a CF....

Cheers! (and thanks!)

Come to you later on with the FTP details.