Welcome to our community

Be a part of something great, join today!

  • 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 :)

Helium weird bokeh / clipped highlights (RED tech please look at this)

Oh Phil, you tease sir!

I always think that Graeme and RED will release newer color science when he/they are ready. Remember one of the things about Red Raw and RED's color science is that Graeme and gang are always tweaking and making it better.

But Phil, again your are a tease!
 
Out of gamut colors are the hard stuff. Dragon and Helium are prone to this under certain conditions. This shouldn't be much of an issue for a colorist in reality.

Actually with present set of tools at colorist's disposal it's not easy at all. You'd need to key those offending colors and then try to carefully diminish them, if you can. Luckily, FilmLight is well aware of this out of gamut issue and is addressing it. First, they introducing the new working color space- T-Log (Truelight-Log) where they take into an account various cameras gamuts (for example Sony is notorious for Red gamut going way past any other cameras). By using this new wider working space, they insure, that no camera goes out of gamut. In those rare times, when it does happen, they introduce a new auto gamut limiter, that is based on the deliverable gamut. The reason why you want an auto gamut limiter, is let's say you're grading in P3, but delivering for both XYZ and Rec-709. There can be instances, where narrower deliverable gamut (Rec-709) will then have an out of gamut colors, that will not be present in the wider gamut color spaces (P3). And finally, doing a hard clip is not a good thing, so in Baselight V5 FilmLight is introducing a new manual Gamut Limiter, where user can selectively and intelligently adjust the out of gamut color without any need for key. It completely eliminates the out of gamut errors, like OP posted.
And BTW, FilmLight just demonstrated it's new upcoming BaseGrade grading tool, that will be introduced with Baselight V5. It operates fully in the linear light and they conclusively showed, that there is no longer need to adjust camera metadata, like ISO and Color temperature. Red metadata adjustments or for this matter, any other RAW recording cameras, can be completely replaced by using very simple BaseGrade controls. That tool is actually based on a traditional photography methods- like zone system...
 

You don't need to key it and you also described how, though with a new tool, to make it easier.

Without spilling too much sauce on the plate, there are ways to handle this as shown even with the images here. This doesn't even need "new color" to happen.


The shortest thing I can say. The workflow for REDWideGamutRGB/Log3G10 works in a much more intelligent way in regards to what RED cameras actually capture. The addition of a well crafted transform LUT is the extra bit of the equation that lets everything play nicely in Rec.709 and Rec.2020 and produce solid color.
 
You don't need to key it and you also described how, though with a new tool, to make it easier.

Without spilling too much sauce on the plate, there are ways to handle this as shown even with the images here. This doesn't even need "new color" to happen.


The shortest thing I can say. The workflow for REDWideGamutRGB/Log3G10 works in a much more intelligent way in regards to what RED cameras actually capture. The addition of a well crafted transform LUT is the extra bit of the equation that lets everything play nicely in Rec.709 and Rec.2020 and produce solid color.

If we lived in Red camera only world, sure. But there is a vast number of various cameras as well as countless deliverables, that no amount of camera science will be able to solve. So, new approaches are needed, even with Red finally getting on board with WideGamut development. Using WideGamut is a good idea, but as I already described, it's still not panacea from out of gamut errors.
BTW, LUT and transform are not the same thing. For one LUT can't be easily concatenated without introducing rounding errors, where transform can. That is one of the reasons why ACES uses transforms instead of LUTs.
 
Actually with present set of tools at colorist's disposal it's not easy at all. You'd need to key those offending colors and then try to carefully diminish them, if you can. Luckily, FilmLight is well aware of this out of gamut issue and is addressing it. First, they introducing the new working color space- T-Log (Truelight-Log) where they take into an account various cameras gamuts (for example Sony is notorious for Red gamut going way past any other cameras). By using this new wider working space, they insure, that no camera goes out of gamut. In those rare times, when it does happen, they introduce a new auto gamut limiter, that is based on the deliverable gamut. The reason why you want an auto gamut limiter, is let's say you're grading in P3, but delivering for both XYZ and Rec-709. There can be instances, where narrower deliverable gamut (Rec-709) will then have an out of gamut colors, that will not be present in the wider gamut color spaces (P3). And finally, doing a hard clip is not a good thing, so in Baselight V5 FilmLight is introducing a new manual Gamut Limiter, where user can selectively and intelligently adjust the out of gamut color without any need for key. It completely eliminates the out of gamut errors, like OP posted.
And BTW, FilmLight just demonstrated it's new upcoming BaseGrade grading tool, that will be introduced with Baselight V5. It operates fully in the linear light and they conclusively showed, that there is no longer need to adjust camera metadata, like ISO and Color temperature. Red metadata adjustments or for this matter, any other RAW recording cameras, can be completely replaced by using very simple BaseGrade controls. That tool is actually based on a traditional photography methods- like zone system...
I really like this approach for vfx and vr are related projects, I have cut over to physically based light for everything I do. My current workflow does have a few pipeline issues as it moves to distribution formats, so thanks for posting this as I am pondering how all this works out.
 
Again, In Tim's Helium footage and also Stefan's , from another thread, all seem to push the footage toward green. Is this something to do with the Helium sensor not having its final color science or something else. Here again are some of the clips corrected for green except the last one.


30783988575_751c02fcfa_b.jpg
[/url]Untitled00086400 girl in dark by rand thompson, on Flickr[/IMG]


30783988685_4ffe471a3a_b.jpg
[/url]Untitled00086400 2 by rand thompson, on Flickr[/IMG]


30747517386_8fcf45d0fa_b.jpg
[/url]Untitled00086400 girl against headlights by rand thompson, on Flickr[/IMG]


30747517296_d584f4734d_b.jpg
[/url]Untitled00086400 jpeg by rand thompson, on Flickr[/IMG]
 
Last edited:
If we lived in Red camera only world, sure. But there is a vast number of various cameras as well as countless deliverables, that no amount of camera science will be able to solve. So, new approaches are needed, even with Red finally getting on board with WideGamut development. Using WideGamut is a good idea, but as I already described, it's still not panacea from out of gamut errors.
BTW, LUT and transform are not the same thing. For one LUT can't be easily concatenated without introducing rounding errors, where transform can. That is one of the reasons why ACES uses transforms instead of LUTs.

I don't want to get into another heated debate regarding if Transform LUTs are or aren't transforms. Personally that was a wasted 6 pages of conversation. REDWideGamutRGB's goals are set forth to handle things even ACES doesn't exactly do well, but that's a whole other conversation.

Graeme's been hard at work and the math, the "workability", as well as the visible results are very good. There will be more news on much of this later.
 
Again, In Tim's Helium footage and also Stefan's , from another thread, all seem to push the footage toward green. Is this something to do with the Helium sensor not having its final color science or something else. Here again are some of the clips corrected for green except the last one.

Untitled00086400%20girl%20in%20dark.jpg
[/URL][/IMG]

KV0RftP.jpg
 
Graeme was kind enough to let me test drive what he has been working on and now the video has been updated with a render using RWG/L3G10 + his special wizardry. The first go round was DC2/RG4

https://vimeo.com/189478583
 
Exploding saturated highs are solved with Graeme's RWG & Log3G10.




Exhibit A: DC2, RG4

Exhibit B: RWG, Log3G10 > rec.709
Custom route. Same applied on all three.



2hciz46.jpg



dq4oc6.jpg



29xw5ex.jpg
 
BTW, LUT and transform are not the same thing. For one LUT can't be easily concatenated without introducing rounding errors, where transform can. That is one of the reasons why ACES uses transforms instead of LUTs.

Each route has its advantages and limitations.
 
I don't want to get into another heated debate regarding if Transform LUTs are or aren't transforms. Personally that was a wasted 6 pages of conversation. REDWideGamutRGB's goals are set forth to handle things even ACES doesn't exactly do well, but that's a whole other conversation.

Graeme's been hard at work and the math, the "workability", as well as the visible results are very good. There will be more news on much of this later.

Phil.
I truly hope you stop making misleading statements. If you do that, then we don't have to get into this, but if you do, then I don't have a choice, but to correct your misstatements, like you just did again in relationship to Wide Gamut in ACES statement or confusing LUTs with transforms, like they are interchangeable...
There is no need to claim, that the Wide Gamut is something, that is a brand new Red invention. ARRI WideGamut had been in use for years now and it's use in ACES, as well as in Resolve Color Managed or Truelight Color Spaces is well documented.
It's OK to occasionally admit, that Red didn't invent something...
 
Phil.
I truly hope you stop making misleading statements. If you do that, then we don't have to get into this, but if you do, then I don't have a choice, but to correct your misstatements, like you just did again in relationship to Wide Gamut in ACES statement...
There is no need to claim, that the Wide Gamut is something, that is brand new. ARRI WideGamut had been in use for years now and it's use in ACES, as well as in Resolve Color Managed or Truelight Color Spaces is well documented.
It's OK to occasionally admit, that Red didn't invent something...

It's not about inventing, it's about it being "different". Tuning out tonight. Happy Halloween.
 
...


1j2fdd.jpg
 
So looking at the R3D, what you're seeing are colours that cannot be properly represented under REC709 and thus go funky. To avoid this for now, best use original DragonColor or RWG/Log3G10. Testing new processing here on the R3D (thanks for the links to the R3D) shows it's all working as expected and making some nice images.

Graeme

Thank you Graeme for the reassurance. I have learned much more about the way Helium works and have been confident enough to take it to my commercial shoot yesterday. I had massive problem with it at first but I told my director that I am quite confident that I could dodge the issue entirely and that I would like to use the camera for the cleaner blacks than any other. The dynamic range is indeed comparable to the Dragon. RedWidegamut + Log3G10 is not the answer to fixing those weird Bokeh's, as the problem can still occur with that. The key is to dodge blue/red colored spikes of highlights, which can be really difficult at times but I did mange to shoot a whole commercial around it. I also found that 5600k/3200k bulbs don't really cause the broken bokeh issue, but spikes of highlights will still blow out extremely heavily (the tungsten source from first 2 images - they were heavily diffused but still blown). Helium seems to be extremely sensitive with highlight spikes...

2Yz1iAN.jpg

umhZqCL.jpg

u0RpMZE.jpg

13LawKn.jpg

ve9Ln9G.jpg

8pwkcDZ.jpg

rMbnJu4.jpg
 
Last edited:
I really do hope the responsiveness of the sensor to specular highlights is looked at or at least explained.

Are these shots on the standard OLPF? I'm ordering the STH in the hope that it settles it a bit.
 
Back
Top