DSMC Camera Firmware release 5.1.55 and 5.2.21 beta

[David Battistella]

No, David, that's often not right. Because it's not the way you do it does not mean it's not a legitimate workflow. Lots of people are using those Pix-recorded proRes files as the deliverable, even in network TV land. Just look at this thread: Dragon at 400 ISO for a great example. That SDI output is an important part of the RED ecosystem.

i did not say it was not right. To be clear, I totally understand the need and I would use it any second I would need to. I'm just saying it was not designed that way. If red wanted to build a "Prores out of the box" type of camera I am pretty certain they would have. I'm sure they have the very capable minds to create a nice 1080p, sharpened, color boosted, noise reduced out of the box image. There's no doubt they could do that.

philosophically they chose a film replacement digital RAW workflow for, IMHO all the right reasons and they have been very clear about that from the get go.

Now, we'd all like to have one camera to rule them all and I would take advantage of any feature red gives me.

I appreciate exactly what people are asking for, because it seems so simple to do, I'm just not certain it's that easy for red to do, or, if philosophically the focus is absolutely on RAW a workflows because they are, in the long run, much more powerful.

I read the 400 ISO thread, and it is great that a user filmed that way and got images to the clients and that's what they wanted and needed, I'm all for that and I would do it as well, but I also get that's not what the camera was designed to do.

I have just thought that if red goes down the 1080p rabbit hole, they might be focusing on something that they have been desperately fighting against, "that 1080P is good enough". So they kinda took the position, if you want to hook up a pix and hand your client a video tap, no problem (they even made it 1080P on the epic), then that's cool, but I don't think that's what they are about or where their energy is focused.

Battistella

 

[Daniel Stilling]

We are now in a world that's neither exactly like film or exactly like video anymore. It's hybrid now. A lot of clients that in the past would never dream of shooting film are starting to embrace RED. Therefore I believe that many different workflows are a reality and need to be taken into account.
I'm sure this is not an easy fix, but I agree that if at all possible it should be implemented in camera as well.

 

[David Battistella]

Well said. And obviously quite a few people concerned about Proxy workflow. And rightly so.

old news. Why is the proxy workflow creeping into the Dragon camera now as well. This was completely hammered out here a long time ago. Seems like whenever there is a highly viewed thread all of a sudden old issues (which have been clearly resolved) get put back into the discussion.

I wonder why?

its over.

Next.


Battistella

 

[Matt Ryan]

old news. Why is the proxy workflow creeping into the Dragon camera now as well. This was completely hammered out here a long time ago. Seems like whenever there is a highly viewed thread all of a sudden old issues (which have been clearly resolved) get put back into the discussion.

I wonder why?

its over.

Next.


Battistella

Pretty sure he doesn't mean a proxy recorder but yet other proxy devices like the pix and ninja, etc. That why he says proxy workflow.

 

[Bohdan Klos]

Pretty sure he doesn't mean a proxy recorder but yet other proxy devices like the pix and ninja, etc. That why he says proxy workflow.

Correct Matt. Next.

 

[David Battistella]

Alexa is a great proxy workflow.

no need to worry about RAW capture.

sorry. Could not resist.

seriously. No one is stopping anyone from recording the monitor feed and red made it easy with in camera looks, a clean feed, got rid of the look around, etc. so now people have that, but it's not enough, it has to be what an Alexa can deliver?

All I am saying is that it wasn't really designed for that, but still red has really accommodated these requests short of building their own module, which would have been a lot of R&D for something that was already being implemented in many flavors by 3rd parties.

battistella

 

[paul schefz]

amazing how a post fix for an acknowledged capture problem turns into a feature....with a proper name and all....all it needs now is it's own theme music...

i don't need proxies or video out of camera but know enough that a LOT of people do....and trying to force people into one fringe software or even latest updated to widely used software is a recipe for disaster....

i am obviously not an engineer but there is something not right if the sensor creates this noise in the first place.....or in this case...did not with the old olpf? wouldn't it make more sense to take a step back and work at it from that angle instead of a software post fix that will be very, very hard to implement in camera?

 

[Björn Benckert]

Alexa is a great proxy workflow.

no need to worry about RAW capture.

sorry. Could not resist.

seriously. No one is stopping anyone from recording the monitor feed and red made it easy with in camera looks, a clean feed, got rid of the look around, etc. so now people have that, but it's not enough, it has to be what an Alexa can deliver?

All I am saying is that it wasn't really designed for that, but still red has really accommodated these requests short of building their own module, which would have been a lot of R&D for something that was already being implemented in many flavors.

battistella

You can argue for and against... amira kicks out 200fps full sensor log or with a 3dlut to proress... it will for sure attract quite a few.

Here is a little amira test we did. It's straight from camera no grading.... and no stabilizing in post... Some friends are building a camera car together with volvos R&D team... which is quite cool, the tech guys at volvo had no budget restrains... so they made a 600 horsepower super volvo and put the scorpio crane on it

https://vimeo.com/100209902


I think a lot of people want just that clean picture straight from camera... the DP does the primary grading etc... I hate it, find it boring and want nothing of it, but for sure producers like to have a good looking image right there in the monitor and then care nothing more about it trough editing and so on. Most does not want to pay DIT's data vranglers, transcodes etc. But personally I agree with you, I do not want that type of clients, I want to get out the best of whats possible and then a RAW workflow is the only way... so my philosophy is to tell the clients to just take it, raw or nothing

 

[Björn Benckert]

Question I did not read the whole thread but I suppose this imporved blacks in rcxp works also on allready captured material. I think about my diving friends that went down in pitch black 70meters down in the baltic sea with our dragon two weeks ago. They would very much benefit from improved blacks So is it just for them to apply this and viola, better picture?

 

[David Litchfield]

Because right now it is specfic to Dragon footage with the new OLPF. Remember this was originally going to happen in the camera calibration... We shifted the code from being in camera to being in the debayer which gives the opportunity for Graeme to adapt this in a smaller form to more hardware combinations... perhaps even to MX footage ( no promises ) . Since its more open there is the SDK support and Rocket support and everything else that goes with it so there needs to be an on off switch until it works with everything... and until there has been hundreds of more hours of testing to make sure there is no negative side effect that pops up where you would want to turn it off.

Doesn't RCX know that its Dragon footage because of its meta data?

It looks like a big improvement. You should definately ditch the on/off button though. Otherwise it looks to the world like a 'denoise to fix a problem' button, even if it isn't.

David

 

[Rob Macey]

No, David, that's often not right. Because it's not the way you do it does not mean it's not a legitimate workflow. Lots of people are using those Pix-recorded proRes files as the deliverable, even in network TV land. Just look at this thread: Dragon at 400 ISO for a great example. That SDI output is an important part of the RED ecosystem.

Correct. I would not be able to use my Dragon on most television shoots if it weren't for Pix/Nano, etc. 50mbps is the limit for some network TV shows I shoot. Others are ProRes at 145. What is great is that I can use Dragon and introduce them to it, even at 1080. Very important note is that Dragon's 1080 out is ultra clean and better than my Sony F cameras. This is my real world experience. 1080 out from Dragon is gorgeous and perfect for many network and cable productions as well as shoot and ship clients.

For my own company productions however, we shoot and post with 6K files. The last set of commercials we produced were finished with DPX files at Light Iron and VFX from The Mill. So, having both 4/5/6K as well as 1080 out record options allow Epic/Dragon to thrive in an even wider body of client work.

 

[Elsie N]

Question I did not read the whole thread but I suppose this imporved blacks in rcxp works also on allready captured material. I think about my diving friends that went down in pitch black 70meters down in the baltic sea with our dragon two weeks ago. They would very much benefit from improved blacks So is it just for them to apply this and viola, better picture?

Yes, and no promises made, but maybe even to old MX footage.

EDIT: Not sure if it will initially work on the old Dragon OLPF footage. Maybe someone else knows?

 

[Bohdan Klos]

It seems like in camera noise fix is the way to go. The more I read/think it seems like DEB is a deliberate stop gap measure till in camera is ready.


Did I miss the fix for the magenta line issue? Has it been addressed?

 

[Elsie N]

You can argue for and against... amira kicks out 200fps full sensor log or with a 3dlut to proress... it will for sure attract quite a few.

Here is a little amira test we did. It's straight from camera no grading.... and no stabilizing in post... Some friends are building a camera car together with volvos R&D team... which is quite cool, the tech guys at volvo had no budget restrains... so they made a 600 horsepower super volvo and put the scorpio crane on it

https://vimeo.com/100209902


I think a lot of people want just that clean picture straight from camera... the DP does the primary grading etc... I hate it, find it boring and want nothing of it, but for sure producers like to have a good looking image right there in the monitor and then care nothing more about it trough editing and so on. Most does not want to pay DIT's data vranglers, transcodes etc. But personally I agree with you, I do not want that type of clients, I want to get out the best of whats possible and then a RAW workflow is the only way... so my philosophy is to tell the clients to just take it, raw or nothing

Someday I may need that image immediacy, but for now it is so much faster just to look at the histogram and expose to the right. Pretty much just turn on the camera, wait for the T/E greens, and start shooting. Post is where the Dragon reaches its Zenith, IMO.

But the camera has been adopted by such a variety of shooters, I understand different needs.

 

[Brian Boyer]

I probably have this all wrong but...

AFAIK, the debayer basically happens at the moment of playback. Since D.E.B. is a demosaicing algorithm, it seems there's a good chance current SDK implementations wouldn't be able to read the new code.

If that's the case, putting D.E.B. in camera first would render every Dragon useless until software vendors implemented the new SDK.

If it's going to take time for most of them to do that either way, with it being a part of the SDK first, you can still load your Dragon footage in the current SDK. It seems like the lesser of two evils until everything gets hammered out.

Remember, the ONLY reason any piece of software can read an .R3D is because of the SDK. Once it's implemented, you won't have to explain anything to anyone about a new procedure (provided D.E.B. defaults to being on, which would be up to the individual vendors to set, I'm assuming). Plus, it works on your older footage as well.

There was a point when no Dragon footage whatsoever worked in other applications until the SDK that allowed it was implemented. It's not the end of the world.

If RED put in the camera FW first and there were an issue (besides possibly not being readable in 3rd party software), they'd never hear the end of it. How do I know? Because the thing isn't even officially out yet and people are already lighting torches and reaching for the pitchforks.

People complaining about having to update software in order to take advantage of new features are being utterly ridiculous. That's how software works.

If it's not a new RED feature, it's something new from Arri, Canon, Sony or a whole new file format altogether. It never ends and should be expected as par for the course.

 

[D Fuller]

i did not say it was not right. To be clear, I totally understand the need and I would use it any second I would need to. I'm just saying it was not designed that way. If red wanted to build a "Prores out of the box" type of camera I am pretty certain they would have. I'm sure they have the very capable minds to create a nice 1080p, sharpened, color boosted, noise reduced out of the box image. There's no doubt they could do that.

philosophically they chose a film replacement digital RAW workflow for, IMHO all the right reasons and they have been very clear about that from the get go.

Now, we'd all like to have one camera to rule them all and I would take advantage of any feature red gives me.

I appreciate exactly what people are asking for, because it seems so simple to do, I'm just not certain it's that easy for red to do, or, if philosophically the focus is absolutely on RAW a workflows because they are, in the long run, much more powerful.

I read the 400 ISO thread, and it is great that a user filmed that way and got images to the clients and that's what they wanted and needed, I'm all for that and I would do it as well, but I also get that's not what the camera was designed to do.

I have just thought that if red goes down the 1080p rabbit hole, they might be focusing on something that they have been desperately fighting against, "that 1080P is good enough". So they kinda took the position, if you want to hook up a pix and hand your client a video tap, no problem (they even made it 1080P on the epic), then that's cool, but I don't think that's what they are about or where their energy is focused.

Battistella

What you said was, "... people do want to record dailies or whatever that way, but hey, they're dailies right." and for many people, that's not right, they record the SDI feed, and that's their deliverable. You keep calling it a "video tap" and the recordings "dailies" but neither of these have been like their counterparts in the film world for a long time. I shoot knowing that my final image is going to come out of a color suite, but my clients want the monitor on my set to look as much like the finished product as possible. In the film days, when a client was worried about the image they saw on the tap, you let them look through the lens. Today, the monitor on the set is the look through the lens.

I completely understand Red's commitment to raw recording. But they've also enabled this ecosystem of SDI recorders by putting start-stop signals on that feed. They are not fighting that workflow, they are just not producing it themselves. The Red ecosystem has always included far more than just the things Red produces. And nobody is asking Red to go down a "'1080 is good enough' rabbit hole". What they're saying is that the SDI feed from the camera, that everybody on the set judges the picture by, and that some people record as a deliverable, should not be an afterthought.

Now FWIW, i don't know if I don't know if any of the issues addressed by DEB are present in the SDI signal. I understand that signal is pre-redcode compression, so if the red noise is a product of the raw compression, then it may not be an issue for that workflow at all. But if I may quote you, "doing stuff in camera to make the video tap look better (as an argument)" certainly does make sense to me.

 

[Daniel Stilling]

Reality is: some productions have a lot time for tweaking post. Some need to deliver immediately.
The fact that RED has become such a multifaceted and highly adaptable platform is one of the great things about this camera.
I would hate to see that go away and only be able to get the best out of it only when full post is available...

 

[Blair S. Paulsen]

I think Brian's notes about the order in which DEB is added to the ecosystem make sense. Cart/horse and all that.

Hopefully the adaptive demosaic technique Graeme cooked up can run real time in camera, if so I expect it will come in due course.

The sequence of the Dragon ecosystem rollout has been frustrating. That said, if it results in the development of an adaptive demosaic scheme that doesn't introduce odd artifacts, that is a gift that will keep on giving as long as Bayer CFA's on CMOS are the front end.

Cheers - #19

 

[Antoine Baumann]

....and trying to force people into one fringe software or even latest updated to widely used software is a recipe for disaster....

i am obviously not an engineer but there is something not right if the sensor creates this noise in the first place.....or in this case...did not with the old olpf? wouldn't it make more sense to take a step back and work at it from that angle instead of a software post fix that will be very, very hard to implement in camera?

YES exactly! Work from the old OLPF calibration because it was SO GOOD! Please RED team one step backward and then two steps forward. Come on this RED sparkle noise at camera start up is not acceptable.

 

[steve green]

YES exactly! Work from the old OLPF calibration because it was SO GOOD! Please RED team one step backward and then two steps forward. Come on this RED sparkle noise at camera start up is not acceptable.

I kind of agree…..The old OLPF was tested by all the Red "heavyweights" and worked great. Then we discovered some missteps……But the main body of work (with the old OLPF) was "off the charts". Wouldn't it make sense to go back to THIS starting point and amend from there? Instead of where we are here…….months and months away from what? In camera, not in camera, SDK on /off, will it be right?……Please, make it like every camera we've ever owned or rented. Shoot it and it's good! Please, RED team……this business with our Dragons is a heartache, make it right!