R3D Color Discussion

[Mark L. Pederson]

In so many words, that is exactly what I had said. Writing to RAM or writing to cache is both writing PRIOR to the grade and dissolve.
As I said before, Baselight performs grading on R3D only from previously debayered and transcoded 16 bit uncompressed codec, as is Filmmaster, Pablo, Lustre, DaVinci do from from previously debayered and transcoded DPX. Only Scratch does it directly from RAW, unless it uses RR.

With all due respect Jake - writing to memory - is moving data - it's not transcoding it. SCRATCH debayers first (so does Baselight) and moves that data to GPU's memory - so ... I don't really see your point.

 

[Martin Tlaskal]

Hi Martin.
I afraid you missed the original point of this discussion. I had surmised earlier, that every grading solution uses some kind of intermediate codec, PRIOR to actual grading with the exception of Scratch.
I appreciate your explanation, but it only reinforces my original point

In so many words, that is exactly what I had said. Writing to RAM or writing to cache is both writing PRIOR to the grade and dissolve.
As I said before, Baselight performs grading on R3D only from previously debayered and transcoded 16 bit uncompressed codec, as is Filmmaster, Pablo, Lustre, DaVinci do from from previously debayered and transcoded DPX. Only Scratch does it directly from RAW, unless it uses RR.

Hi Jake,

I'm afraid I'm a bit slow here. I don't understand the constant use of the terms "transcoding" and "uncompressed codec" in this context. We simply debayer the image (using tools written by RED to provide maximum image quality by their standards) to an uncompressed, in-memory image format which has sufficient bit depth to handle the dynamic range of the sensor. You can effect the tone curves of the resulting RGB images by adjusting the settings/sliders which are part of the debayer parameters. This is "grading" that has nothing to do with Baselight.

Once an RGB image is available, we then allow you to manipulate those high dynamic range, unclipped images using whatever tools you like.

I'd be surprised if any colour corrector was performing significant amounts of colour correction directly on the un-debayered image, but I could be wrong, I guess. Anyway, I think I've repeated myself enough for now.

Regards,

-Martin

 

[Lucas Wilson]

Hi Jake,

I'm afraid I'm a bit slow here. I don't understand the constant use of the terms "transcoding" and "uncompressed codec" in this context. ...

Jake,

I do appreciate your support of SCRATCH!!!

But see my earlier post - the way that Baselight accesses the R3D files and the way SCRATCH accesses the R3D files result in *no* quality difference. None.

If we're going to compare products, let's discuss cost differences and workflow differences between Filmlight and SCRATCH and how people use the products in different contexts. I can list several sales opportunities where both Baselight and SCRATCH have been in the running and the customer ended up buying a Baselight, and I can also list many where customers have ended up buying SCRATCH. I can also list a few where neither of us won!

But Baselight is a fantastic color product. The Filmlight team know their sh*t, have a justifiably dedicated and loyal user base, and are (for me) worthy opponents in the manufacturer world. : )

Best,

Lucas

 

[jake blackstone]

Jake,

I do appreciate your support of SCRATCH!!!

But see my earlier post - the way that Baselight accesses the R3D files and the way SCRATCH accesses the R3D files result in *no* quality difference. None.

If we're going to compare products, let's discuss cost differences and workflow differences between Filmlight and SCRATCH and how people use the products in different contexts. I can list several sales opportunities where both Baselight and SCRATCH have been in the running and the customer ended up buying a Baselight, and I can also list many where customers have ended up buying SCRATCH. I can also list a few where neither of us won!

But Baselight is a fantastic color product. The Filmlight team know their sh*t, have a justifiably dedicated and loyal user base, and are (for me) worthy opponents in the manufacturer world. : )

Best,

Lucas

Hi Lucas, Mark and Martin.
I'm just giving Scratch it's due, when it's justified. I would never blindly champion any product without proper justification. As an owner of Baselight HD in the past, which I chose over all other grading systems, I had never regretted that decision, ever! So, I have nothing, but highest regards of the Filmlight company, all of their products and it's personnel. Now, going back to the discussion in question and "what's the point". It simply started as a discussion of how great it would be to be able to edit and output R3D of the conformed timeline. To which I had replied, that for now the simplest way is to conform R3D and output it as a DPX. The suggestion then was made, that using DPX wasn't good enough and someone even exclaimed: "I would never trust DPX". Don't worry, we're almost there My next point was, that these statements don't make any sense, as ALL grading, with the exception of Scratch, RC etc. is done exactly like that- from transcoded DPX or, in case of Baselight, from 16 bit uncompressed codec, regardless, if it was read from RAM or cache. I had never claimed, that one way of grading is superior to others. Actually, my point is an exact opposite- both ways result in the same quality. That why I suggested the DPX route. I hope that is all on this subject and we can put it to bed

 

[Martin Tlaskal]

Jake,

I do appreciate your support of SCRATCH!!!

But see my earlier post - the way that Baselight accesses the R3D files and the way SCRATCH accesses the R3D files result in *no* quality difference. None.

If we're going to compare products, let's discuss cost differences and workflow differences between Filmlight and SCRATCH and how people use the products in different contexts. I can list several sales opportunities where both Baselight and SCRATCH have been in the running and the customer ended up buying a Baselight, and I can also list many where customers have ended up buying SCRATCH. I can also list a few where neither of us won!

But Baselight is a fantastic color product. The Filmlight team know their sh*t, have a justifiably dedicated and loyal user base, and are (for me) worthy opponents in the manufacturer world. : )

Best,

Lucas

Hi Lucas,

Thanks for the help in clarifying the issue and for the kind words - a very classy post.

Kind regards,

-Martin

 

[Martin Tlaskal]

Hi Lucas, Mark and Martin.
I'm just giving Scratch it's due, when it's justified. I would never blindly champion any product without proper justification. As an owner of Baselight HD in the past, which I chose over all other grading systems, I had never regretted that decision, ever! So, I have nothing, but highest regards of the Filmlight company, all of their products and it's personnel. Now, going back to the discussion in question and "what's the point". It simply started as a discussion of how great it would be to be able to edit and output R3D of the conformed timeline. To which I had replied, that for now the simplest way is to conform R3D and output it as a DPX. The suggestion then was made, that using DPX wasn't good enough and someone even exclaimed: "I would never trust DPX". Don't worry, we're almost there My next point was, that these statements don't make any sense, as ALL grading, with the exception of Scratch, RC etc. is done exactly like that- from transcoded DPX or, in case of Baselight, from 16 bit uncompressed codec, regardless, if it was read from RAM or cache. I had never claimed, that one way of grading is superior to others. Actually, my point is an exact opposite- both ways result in the same quality. That why I suggested the DPX route. I hope that is all on this subject and we can put it to bed

Hi Jake,

It's all good - glad you have fond memories of Baselight and hope we can lure you back into the fold in the future..

-Martin

 

[Peter Moretti]

...

The cineon and it's later cousin, dpx, use a hack of data redistribution to pack more data into the head and toe of the image AT THE EXPENSE of data in the midrange. This was done because it generally directly corresponded to the density of the camera negative. But that was in 'film land' and we're not in 'film land' any more.

...

:sosp:

What in the world does this mean? Log is not barbell shaped.

And AFAIK, film responds logarithmically to light.

 

[JonathanF]

:sosp:

What in the world does this mean? Log is not barbell shaped.

And AFAIK, film responds logarithmically to light.

Peter,

You're right to call me out on this, scanned film data that is stored in log format, usually roughly corresponds to density of negative stocks fromt he time that the standard was developed. However stocks have changed since 5244 (which is by the way an intermediate stock) on which the original specification was based.

The digital acquisition systems we are concerned with in this forum are however linear in their response (or nearly linear), so encoding the data as log is just absurd when you will only have to convert it to linear before applying any color transformations (that is if you want the resulting transform to be correct).

Again you're quite correct in calling me out on that but the point has always been that you can't shave bits and not have data loss, log, linear or whatever. Bit is bits.

J

 

[JonathanF]

My next point was, that these statements don't make any sense, as ALL grading, with the exception of Scratch, RC etc. is done exactly like that- from transcoded DPX or, in case of Baselight, from 16 bit uncompressed codec, regardless, if it was read from RAM or cache. I had never claimed, that one way of grading is superior to others. Actually, my point is an exact opposite- both ways result in the same quality. That why I suggested the DPX route.

The problem Jake is that you can't take 12 bit linear camera source and debayer it and convert to a 10 bit log format and not lose data, so your assertion that both result in the same quality flys in the face of the most basic principles of computer science.

 

[Sarah C.]

One of the more interesting threads I stumbled over in a long while (including my own!) Thanks for having the discussion!

(I got here because I had learned of the Pablo not using R3D files directly yesterday..this thread more than answers the story on that..)

thanks again!
~s

 

[Lucas Wilson]

Hi Lucas,

Thanks for the help in clarifying the issue and for the kind words - a very classy post.

Kind regards,

-Martin

Hi Martin,

Just saw this now... thanks! There are lots of talented teams of people working in DI. Competition should breed respect, not the other way around.

Best,

Lucas