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

DSMC Camera Firmware release 5.1.55 and 5.2.21 beta

Timecode Buddy is used on many many sets up here in San Francisco...works a charm. Set it, forget it, all in sync. As it should be

I was told, by RED and others that Tc Buddy (1 or 2) does not synch at 23.98, with Dragon. Remember, Epic X was not a problem, but the Dragon upgrade/new cameras behave differently, with the same gear, that works fine on Epic X.

Thank you very much

Fury
 
So, to put it in very simple terms, this is basically working as a noise reduction piece of software to be used in post. Is that a correct assesement?

It's a special kind of adaptive demosaic specifically tailored to the needs of the camera.

Graeme
 
Graeme-

Appreciate your input and talent. Any way this can or will be implemented on-camera?

Thanks!

It's a special kind of adaptive demosaic specifically tailored to the needs of the camera.

Graeme
 
Leaving the adaptive algorithm in the SDK opens the door to Graeme making continual improvements that:
1) Can be retrospectively applied to existing RAW footage
2) Not be limited to the CPU capabilities of the Brain.
3) leaves the recording frame rates as high as possible
4) keeps the recording time as high as possible (no additional power consumption)

AJ
 
Leaving the adaptive algorithm in the SDK opens the door to Graeme making continual improvements that:
1) Can be retrospectively applied to existing RAW footage
2) Not be limited to the CPU capabilities of the Brain.
3) leaves the recording frame rates as high as possible
4) keeps the recording time as high as possible (no additional power consumption)

AJ



But SDK solution leaves external recorders with noisy footage. And when RAW footage is being handed over directly to client it leaves the footage with noise.


Noise correction in post sounds like a step forward for picture quality but certainly feels like a solution that needs to be implemented at camera.
 
But SDK solution leaves external recorders with noisy footage. And when RAW footage is being handed over directly to client it leaves the footage with noise.


Noise correction in post sounds like a step forward for picture quality but certainly feels like a solution that needs to be implemented at camera.


Agree 100%…..Hopefully down the road it'll be implemented into the camera (I hope). Until then we'll have to deal with handing over footage and HOPE it's dealt with properly.
 
Agree 100%…..Hopefully down the road it'll be implemented into the camera (I hope). Until then we'll have to deal with handing over footage and HOPE it's dealt with properly.
not sure how many people use RCX unless they actually own or shoot with red....it will be months before this might show up in premier, resolve, fcpx....
if red keeps adding things like ADD and this it might make more sense to make more robust "plug-ins" (like the one in fcpx) with all settings that are available in rcx (incl. ADD and also alchemy, USM, skin,...)
but regardless this should really be taken care of in camera especially in regard to external recording....
 
Honestly, while the image looks great with D.E.B, I want it in camera by default.
Having it be part of the SDK and Debayer just adds more to the Red workflow to producers and editors, and makes it more complicated for them (as some of them already see it hard to work with compared to other workflows).

Also it'll take a while for applications to implement the new SDK, and if they hide the D.E.B button, it'll be hard to tell if it's the new SDK or not.
By comparison, if D.E.B is in camera, the footage won't work in applications as R3D until they apply the new SDK, which will force editors to use Redcine-x until then, but they won't get noisy footage because they used old software with old SDK.

I don't want to see a producer use old software without D.E.B, and then claim Dragon isn't a good camera, because they didn't know about D.E.B, and influence others to use other cameras.
 
I think it's completely fine if D.E.B is performed in the SDK because it sounds very similar to the DRX switch. One thing I would LOVE to see for both settings is to auto-defualt to on. DRX for the MX chip gives us beautiful accurate highlights, and it sounds like D.E.B. for the DRAGON chip will do the same for shadows. I think the idea of incorporating those switches in the debayering system is great, just please find a way to default both of those settings to On for the next SDK release so we can confidently hand off footage right after it's shot.
 
Its an interesting debate, a provocative one that I am not going to get to deeply into.

Red has has never sharpened their images in camera. I agree with that. I don't think you should filter to soften hard video images. So it's nothing new that red leaves some things to the post pipeline.

The video tap is really designed for dailies and if RED had a RED Prores recorder and they were trying to compete with Alexa that way, (recording Prores in camera) I can understand the argument but the EPIC is not a camcorder style camera, it never has been, so doing stuff in camera to make the video tap look better (as an argument) doesn't make sense to me.

That said I know that people do want to record dailies or whatever that way, but hey, they're dailies right.

I see see ADD and DEB as post tools designed to get the most out of what you shot or to fix extreme exposure situations. Properly exposed stuff looks great on Dragon.

maybe what RED should start doing is somehow forcing users into the most up to date version of their post tools, sorta like what Adobe does with flash for web browsers. This way the whole, producer has the wrong software argument is also dead. It's the responsibility of a professional post house to stay current.

If you turn over well exposed negative there shouldn't be many problems.


Battistella
 
+10000

All of us camera guys shooting that have to hand over footage and have clients on set examining the image NEED this in-camera. Having it in Redcine-X is a temporary solution in my honest opinion.

ditto. In camera has to happen or this is a half fix.
 
+10000

All of us camera guys shooting that have to hand over footage and have clients on set examining the image NEED this in-camera. Having it in Redcine-X is a temporary solution in my honest opinion.
Agreed. Having it in Redcine-x is great for previous shoots, but I prefer my near future shoots to be implemented in camera.
 
+10000

All of us camera guys shooting that have to hand over footage and have clients on set examining the image NEED this in-camera. Having it in Redcine-X is a temporary solution in my honest opinion.


Agreed! "To get clean looking blacks from the Dragon footage we just shot, make certain you use this post software procedure". THIS, is NOT something I want to have to tell producers as I say goodbye.
 
Last edited:
Within the current implementation of D.E.B. I think one thing that can be done is by default of D.E.B. set to "On" via the metadata. Of course after testing it 100% that is. I more or less feel it's safe for that from what I can tell. Haven't found a situation that has freaked anything out. It's actually been the opposite. Just makes things that 2% better overall.

This way when R3Ds are ingested D.E.B. is on and ready to go in Redcine-X and eventually the other tools that will support it.


In camera is interesting. It will be far more important to have something in there for the eventual release of the 4K Broadcast Module, though since that's the straight pre-REDCODE RAW data it's going to be different looking from the get go. Monitoring and 3rd party recorders in 1080p is a "maybe" for me. If you are shooting at 3K and lower I can see the desire. At 4K+ capture resolutions for 1080p out via HD-SDI or HDMI the "need" is actually pretty minimal if any.

If it can be done Red will get it done. In it's current implementation as Graeme stated it's an adaptive demosiac algorithmic. To me that makes realtime "difficult" and playback "easier" to achieve.
 
Any possibility of M.E.B. (D.E.B.'s non-union equivalent) to get a nicer image out of high ISO MX?

Better yet, what does DEB look like on MX footage (just like how DragonColour can actually look good on MX too)?
 
...

The video tap is really designed for dailies and if RED had a RED Prores recorder and they were trying to compete with Alexa that way, (recording Prores in camera) I can understand the argument but the EPIC is not a camcorder style camera, it never has been, so doing stuff in camera to make the video tap look better (as an argument) doesn't make sense to me.

That said I know that people do want to record dailies or whatever that way, but hey, they're dailies right.

...

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.
 
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. .


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