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

So what... is FLUT?

Great on all fronts,
To much work over the holidays Graeme and team....

My only question: what about REDfilm?

I'm kinda curious about this.

David
 
David Battistella said:
My only question: what about REDfilm?
Click to expand...

I suspect REDfilm replicates a log Dmin/Dmax scan for a logarithmic cinema DI workflow.

I have my issues with the intelligence of a log workflow derived from a linear sensor, but we must admit that some of the best colorists in the world are setup to work in log.

I've seen some requests for a single setting in Redcine which delivers the entire range within a 10 bit log file, with absolutely zero curves or grading. Perhaps that is what REDfilm is.

Anyway, how are you doing David? I'm saving up for one of your sliding baseplates. :)
 
just a quick and kind off-topic/on-topic question for gramme. Where did you learn to do all the magic that you do?
 
Will this new FLUT be a so called 2D or 3D LUT?
 
Alex Boothby said:
I suspect REDfilm replicates a log Dmin/Dmax scan for a logarithmic cinema DI workflow.

I have my issues with the intelligence of a log workflow derived from a linear sensor, but we must admit that some of the best colorists in the world are setup to work in log.

I've seen some requests for a single setting in Redcine which delivers the entire range within a 10 bit log file, with absolutely zero curves or grading. Perhaps that is what REDfilm is.

Anyway, how are you doing David? I'm saving up for one of your sliding baseplates. :)
Click to expand...

Good Call Alex,

I'm great. Hope you are well too.

David
 
Graeme Nattress said:
Ex-pat British, now Canadian. Love it here - fantastic country with nice wide open spaces and countryside, which I see non of as I'm in the office coding.

Graeme
Click to expand...

haha! glad you like it here... we hope you stick around!

we're really impressed by your expertise. i'm still hoping i can somehow make it to RED day.... we'll see!
 
I have a Post diaper change R3D file – since my daughter doesn’t visit the company that often – I didn’t get her first steps with the Red One. I am hoping Scarlet will be ready for the next baby.
 
Graeme Nattress said:
However, I can assure you that the precision in the image processing pathway is more than sufficient for that data, and that is relevant.
Click to expand...

I'm curious as to whether there will be specific implementations for different display types, and what type of display the new processing is targeted to. I'm assuming it's targeted to a "perfect" generic RGB display of some sort, but as you know, color is only relevant to the specific display the processing path is developed for. All other display types must use lookup tables to emulate the "ideal" display if that is to be the standard. In our business, this is all very relevant and critical because different deliverables use completely different display models, some of which are not electronic (film, for instance), and some of which have different display gamma characteristics (2.6 for digital cinema, for instance), as well as different gamuts. The primary deliverable (sometimes film, sometimes not) usually determines the display target that should have the least compromise, which is why DI's have been targeted to film and why Red has not fared as well as one would hope in "standardized" DI comparative tests. My guess is that your new processing targets a theoretical unlimited gamut rather than a display specific one, but real images will still require some sort of display as a standard reference. I suppose I should wait for the Red events in January and February for those kind of details, but if you want to discuss them prior to that, as I said, I am curious...

I'm also curious as to whether you're modeling this to be adaptable and relevant to the Academy IIF proposal. Being display agnostic does fit into that quite well, and allows third parties to determine output transforms. But it also requires the manufacturers to characterize their devices and provide input data transforms based on that characterization. I hope you're moving in that direction. It sounds like you might be.
 
M Most said:
I'm curious as to whether there will be specific implementations for different display types, and what type of display the new processing is targeted to. I'm assuming it's targeted to a "perfect" generic RGB display of some sort, but as you know, color is only relevant to the specific display the processing path is developed for. All other display types must use lookup tables to emulate the "ideal" display if that is to be the standard. In our business, this is all very relevant and critical because different deliverables use completely different display models, some of which are not electronic (film, for instance), and some of which have different display gamma characteristics (2.6 for digital cinema, for instance), as well as different gamuts. The primary deliverable (sometimes film, sometimes not) usually determines the display target that should have the least compromise, which is why DI's have been targeted to film and why Red has not fared as well as one would hope in "standardized" DI comparative tests. My guess is that your new processing targets a theoretical unlimited gamut rather than a display specific one, but real images will still require some sort of display as a standard reference. I suppose I should wait for the Red events in January and February for those kind of details, but if you want to discuss them prior to that, as I said, I am curious...

I'm also curious as to whether you're modeling this to be adaptable and relevant to the Academy IIF proposal. Being display agnostic does fit into that quite well, and allows third parties to determine output transforms. But it also requires the manufacturers to characterize their devices and provide input data transforms based on that characterization. I hope you're moving in that direction. It sounds like you might be.
Click to expand...

I always enjoy reading your posts, Mike. I'd be curious to hear more about this myself.
 
M Most said:
(Snip)
I'm also curious as to whether you're modeling this to be adaptable and relevant to the Academy IIF proposal. Being display agnostic does fit into that quite well, and allows third parties to determine output transforms. But it also requires the manufacturers to characterize their devices and provide input data transforms based on that characterization. I hope you're moving in that direction. It sounds like you might be.
Click to expand...

I want to second Mike's note about how great it would be to consider the Academy IIF (Image Interchange Format) as a nominal target. For those of you not familiar with this standard, the short version is that it creates a intermediate target space (ACES) with a known profile. You can then use input LUTs (profiles) and output LUTs to "normalize" (typically this would be an inverse curve to the particular characteristics of the acquisition or display device) your material to this intermediate benchmark.

Moreover, I predict our future as content creators and manipulators will require more and more intercutting of media generated from ever more inherently disparate sources and the adoption of the Academy IIF protocols and the use of the ACES benchmark should greatly simplify that process.

Cheers - #19
 
Blair S. Paulsen said:
I want to second Mike's note about how great it would be to consider the Academy IIF (Image Interchange Format) as a nominal target. For those of you not familiar with this standard, the short version is that it creates a intermediate target space (ACES) with a known profile. You can then use input LUTs (profiles) and output LUTs to "normalize" (typically this would be an inverse curve to the particular characteristics of the acquisition or display device) your material to this intermediate benchmark.
Click to expand...

I would also add that one of the major advancements in the proposal is that the proposed file format to contain the ACES representation is based on a subset of Open EXR, basically a floating point format. This eliminates many of the limitations in precision inherent in 10 bit, 12 bit, and even 16 bit file formats.
 
M Most said:
I would also add that one of the major advancements in the proposal is that the proposed file format to contain the ACES representation is based on a subset of Open EXR, basically a floating point format. This eliminates many of the limitations in precision inherent in 10 bit, 12 bit, and even 16 bit file formats.
Click to expand...

This level of precision is a major attraction for me, in part, because it lengthens the useful lifespan of the standard before revision is required which extends the compatibility window.

Cheers - #19
 
It is awesome how you guys invented a whole new universe around the camera with words and concepts specific to it with Fluts,R3ds,Redcodes etc. A universe with great images, I am glad to be learning about it, and being a part of it.
Happy Holidays Red team,
Cheers,
ƒ
 
You must log in or register to reply here.
Back
Top