SDK Roadmap ? Any chance Red will let the debayering do others ?

[Manuel Wenger]

This is a question for the RED Software Heroes,

I LOVE Speedgrade and it´s absolutely groundbreaking how they are debayering Sensor Raw Data from Cameras like D21 or SI or Phantom.

With the current SDK they´re not able to get the reals sensor data but just some RGB information (i´m not a programmer so don´t beat me if i interpret it wrong) which slows the system down and doesn´t bring the full quality to daylight.

Is RED planning to open the RAW file to companies like Iridas or others just as Arri, Silicon Imaging and other RAW Camera manufactures do ?

I don´t need it tomorrow, but it would help a lot if this was on the Roadmap for the SDK.

thanks
Manuel

 

[gbalaji]

I too was told the same by other vendors too?

 

[Antoine Baumann]

I am not a programmer neither, bu may be red doesn't want their compression algorithm to be discovered by the competition, and I think that they are ahead in this domain.

But I agree that it would be the best for us, reduser, to have different debayering possibilities. And I have heard that Iridas was doing pretty amazing debayering on redcode before the sdk...

ciao,
antoine.

 

[RivaiC]

I am not a programmer neither, bu may be red doesn't want their compression algorithm to be discovered by the competition, and I think that they are ahead in this domain.

But I agree that it would be the best for us, reduser, to have different debayering possibilities. And I have heard that Iridas was doing pretty amazing debayering on redcode before the sdk...

ciao,
antoine.

which is GPU debayering

 

[Manuel Wenger]

which is GPU debayering

yes, but that´s not the reason for the amazing quality, you can achieve the same result via the CPU if required (distributed rendering via Metarender)

I really hope RED decides to open it up to other companies, they would also benefit from it, they could concentrate on camera development and not on software tools.

Manuel

 

[Trevor Meier]

I agree that RED needs to open up their RAW data. Keeping things close to the chest while the company gets off the ground is fine. But ultimately, do you think Nikon or Canon would be as popular if you could only use their software to view RAW files from the 5D or D300?

RED needs to open up this data in a standardized, open way to stay on top of the RAW camera pile.

 

[Manuel Wenger]

Fully agree with you, Trevor.

 

[Harry Clark]

I agree as well... but the SDK is likely a first step, yes?
Cheers,
Harry

 

[Mike Zinner]

Guys, cool down. RAW access is coming, it's only a question of time. Please see Jim's statement here:

http://www.reduser.net/forum/showpost.php?p=262061&postcount=87

I also am urgently waiting for it so that I can finally upgrade from Build 13...

 

[reality]

I was not at all impressed by Iridas' debayering quality. I've looked at alot of debayering algorithms from different companies and the Iridas one is not mature.

I also believe [but could be wrong] that neither canon nor nikon provide raw access. Mostly everyone that has raw access except for maybe adobe has reverse engineered it or used dcraw

 

[jbeale]

access to Nikon RAW

access to Nikon RAW

You may recall the concern over Nikon's white colorbalance encryption back in 2005. Nikon's position was that you can do what you need with the original file using their proprietary SDK, so you shouldn't need direct RAW access. I haven't followed the issue so I don't know if that position has changed.

See also: http://www.dpreview.com/news/0504/05042203nikonnefresponse.asp

I believe that Dave Coffin's DCRAW, which reads many raw DSLR formats, is entirely reverse engineered. Here's an interview with the author. The interviewer from DPReview mentions in a question "...we know none of the manufacturers openly document their RAW formats..."

http://www.dpreview.com/news/0504/05042701davecoffininterview.asp

As Dave mentions, pretty much every camera company believes that it is best qualified to deal with its own raw sensor data.

 

[RivaiC]

yes, but that´s not the reason for the amazing quality, you can achieve the same result via the CPU if required (distributed rendering via Metarender)

I really hope RED decides to open it up to other companies, they would also benefit from it, they could concentrate on camera development and not on software tools.

Manuel

I didnt say about the quality. GPU chunks out the debayer faster than CPU. It's the speed.

And i do agree about open it up. But i dont think so.

 

[Manuel Wenger]

reality, could yo please explain that to me ? I nmy humble opinion , the Speedgrade debayering beats all other debayering solutions by far, given that we´re comparing to motion picutre camera debayering, i didn´t compare to still image raw development.

 

[Jeff Brue]

The debayering quaity out of iridas is highly dependent on the sensor, and the imagery. I've seen it create some great results and some really bad ones as well. Hands down the camera manufacturer is the most qualified to interpret their own RAW data, as there are factors and maths involved in the A to D process that it can be critical to have for a quality debayer. IE the camera heat sensor is indicating 100 degrees farenheit which increases noise, lets boost the pixel averaging to deal with it. Or hey we're rating the camera for Tungsten lighting lets increase the blue channels analog gain so we can actually get a picture on this sensor that has a weak blue channel.

In the case of Red we don't know what the balance of analog signal processing versus digital processing occurs, based on the overall firmware quality improvements I have to say that this balance is what Red has been working so diligently on.

Any effort to reverse engineer a debayering solution from an incomplete set of information will only result in less dynamic range, which will only reflect negatively on Red. The same goes for every other camera manufactuer. It's silly to let that get into others hands as well their interests as we go foward with an all data pipeline might not be in line with showing a camera like this in the best light.

 

[RivaiC]

Good post Jeff,

In short, it's all entirely up to RED if they want to add support GPU based debayer or not. Iridas certainly will be ready to jump in once RED added that capabilties inside the SDK.

Whether it happens or not. Only RED can answer

 

[Lin]

The debayering quaity out of iridas is highly dependent on the sensor, and the imagery. I've seen it create some great results and some really bad ones as well. Hands down the camera manufacturer is the most qualified to interpret their own RAW data, as there are factors and maths involved in the A to D process that it can be critical to have for a quality debayer.

Jeff,

I heavily disagree. The most important factor in debayer quality is the maturity of the algorithm. While the manufacturer may have the best shot at creating the best algorithm, it doesn't say he succeeds in actually creating it.

Please feel free to post an example of "bad" quality coming out of RealTime RAW 2.0.

Anything else is just opinion, not fact.

And I am not even talking about the fact that we have 30fps playback up to 4K (uncompressed, not RED) in full quality. Let's just compare the results, regardless of the time factor.

We have a lot of people doing debayering with SpeedGrade and MetaRender right now. All of them happy.

We spent 3 years building a GPU based debayer at render quality - I am sure people can come up with even better algorithms (we are trying), but it's gonna be bloody difficult.

And yes, Manuel is right, it also runs on the CPU. Also very fast.

The main advantage is one tool for all cameras as opposed to one workflow per camera with different software in each.

Thanks,
Lin

 

[Dj Joofa]

Any effort to reverse engineer a debayering solution from an incomplete set of information will only result in less dynamic range, which will only reflect negatively on Red. The same goes for every other camera manufactuer. It's silly to let that get into others hands as well their interests as we go foward with an all data pipeline might not be in line with showing a camera like this in the best light.

Jeff, I think deBayering should not pose the type of problem you are describing for a 3rd party vendor. The problem is posed pretty straight forwardly to generate missing values from data.

There is a huge amount of technical literature on how to do it. Even if one follows the published algorithms to the hilt, one should get very good results.

And, contrary to the information that sometime people glean from this forum, good deBayering can be accomplished in hardware, at a high resolution at a high framerate.

 

[Jeff Brue]

Lin Joofa,
I only have my experience to part from so if you want an example with back up footage. I can provide a recent commercial series I did for the Acura TL shot phantom.Numerous test and commercials shot on Red and 3 months in developing my own solution for the cursed Modula camera. Also work on development of D21 data mode I'll throw in there for fun.

Long and short of it is very very few camera manufacturers provide all of the information that they feed into their own color matrix. Or access to how they're massaging the "RAW" data to be fit into their software better. I can and will argue all day on artifacts based on shortcuts in the debayering process that I've seen in all processing software, and been talked sternly to about by some very picky directors.

In any case Lin I'm opening up a new facility I'm planning on buying speedgrade as a data management tool, just because Red is the most ahem qualified that doesn't mean that they'll actually get it out there for professional post market in a timely manner, and there have been cases where I've seen your toolset do a better job than the camera manufacturers.

Joofa, yes there's an inordinate amount of technical literature out there. What those tech docs don't really talk about is the error masking and filling that has to occur with most major cameras today to 1. increase the dynamic range 2. reduce noise 3. aleviate aliasing and unpleasent optical artifacting.

What's unique about the camera manufacturer developing their software is that they have the opportuinity to like red did, to instate an optical change (the lowpass filter) to make their debayerer do less work on the anti-aliasing.

In regards to in hardware debayering well to be honest I'd rather use those CPU/GPU cycles for 10 times more realtime rotoshapes instead of fighting to get enough power going to do a high quality debayer in the DI thats me.

Bleh I'm tired, sorry for the run on and the sarcasm. Yes I think that the camera manufacturer should be the one to implement. I'm tired of halfway solutions, IE frames being dropped while playing out of any realtime based system. The biggest thing I'm tired of is It's me sitting in the DI bay looking at a 30 ft screen having to explain to a producer why there are tiny dots in this version and why there aren't any in this other one that took 5 times longer.