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

SDK - that's not hype...

offholly..
We all know the SDK is a shit afterthought to someones sdk.(red dont even hide the fact they dont have a format, they just use anothers j2k sdk, badly)

Its still a shit and jpeg2k, the only saving grace is Assimilate tried to help as they were working on there j2k plug....
 
Bruce Allen said:
This did not happen at all with DSLRs.

Care to give me an example of people saying a Canon or Nikon DSLR is bad based on results with crap RAW developer?
Click to expand...

There are so many examples that I hardly know where to start.

DPReview.com, the most popular and respected DSLR review web site, has many very serious errors riddled throughout their high-level "pro/con" and conclusions due to the use of ACR (the Adobe Raw Converter), compounded by the use of 100% crops (ridiculous) and major problems in their "secret sauce" software.

For example, they claim that the 50D has more noise, poor resolution, poor "per pixel sharpness", and diffraction issues compared to the 40D. It's all part of their misguided and unfounded crusade against pixel density. By using ACR, 100% crops, and other secret methodology to build their data, they've come to draw conclusions that are the exact opposite of reality. Using a raw converter that treats cameras with no bias (e.g. dcraw, IRIS) and resampling images correctly shows that the 50D has improved quantum efficiency, less read noise, and higher resolution.

When the D3 raw conversions came out with such little shadow noise, people thought it was 1-2 stops better than the 1Ds Mark III. But the truth is that the raw converters were just doing more noise reduction in the D3 raw conversion. Specifically, they are totally desaturating the deepest shadows, then desaturating on a curve, and doing it stronger for the highest frequencies (where the noise is visible). The same exact noise reduction applied to the 1Ds Mark III brings the two cameras to within just a third of a stop of each other, a far cry from 2 stops. All popular raw converters use different settings for different camera models.

Almost every noise measurement or comparison I've ever seen has been based on measurements made after the RAW conversion is done with some popular "black box" commercial raw converter. Conclusions are drawn about the camera, when it can't be known how greatly the converter factored into the equation. Probably 1% of the tests are based on the raw data itself, before conversion, which truly do measure the performance of the camera.

On the other hand, there are also some examples of the opposite: where RAW converters hide problems in the camera hardware itself. Few people even know that their cameras don't really store "RAW" at all. Everyone but Canon clips the blacks above the mean, instead of preserving the entire noise floor, which improves noise through stacking and darkframe subtraction. Nikon does a white balance, clipping highlights and introducing rounding errors. Canon applies "angle of incidence" pushes to the raw for all apertures wider than f/2.8. Pentax does a slight high ISO noise reduction (27% reduction. All the cameras clip 1, 2, or 4 stops of highlights for ISO above 1600 by pushing the RAW data instead of leaving it RAW. Many don't put all of the dark pixels into the RAW file, which could be used to reduce noise.

Many say that they don't care what the true performance of the camera is, all that matters is what comes out of their choice of software. That's a valid opinion. But even with that testing simplification, people make tremendous testing blunders. The most common mistake is using 100% crops, which, again, has led to the anti-pixel-density tirades at DPReview, such as the pointed and ignorant pixel density questions in the interview with Canon's DSLR/digicam CEO. Such errors in measurement methodology give a four-fold penalty to RED when it should be an advantage.

Having said all that, I would prefer that RED allow direct R3D reading and third-party debayer, despite the fact that it will certainly result in a flood of unfair criticism of the camera. I figure that people will mess things up and blame RED no matter what they do, so they might as well open it up. RED, however, seems to want to reduce the number of ways they can be wrongly blamed. (From infinity to infinity minus one.)
 
Tresch said:
Ibloom,

Be sure I don't have anything against your great tool.

Just wondering why the biggest player in postproduction (Autodesk) still promote DPX instead of the use of native 12bit REDcode?

But you probably got an argument saying R3D is not a way to go for postproduction...

Even so, it's faster/easyer/cheaper to confom and CC R3D with Scratch (last job I did we used the native R3D files) and it's a pitty that the actual SDK don't permit other manufacturers to be as competitive as Assimilate.

Ian, I hope this was not misinformation.

Patrick
Click to expand...

Autodesk isn't doing Redcode yet because they are on Linux. That's the only reason. I think this is a smart thing for them to pick that platform but they are just about the only ones, I'm sure there will be an SDK compiled for Linux eventually but there's a learning curve involved in supporting each platform.

Saying that the current SDK is "hype" is truly silly.

I think your comments aren't helpful. The reason things aren't as good as you want them to be is because these things don't happen over night. Not because no one has asked for them.

IBloom
 
Offhollywood said:
Can you define EXACTLY what you need in two sentences that you do not have now?
Click to expand...

Adobe plugin.

Apple's version of the same plugin.
:innocent:


Emmanuel
 
Offhollywood said:
Can you define EXACTLY what you need in two sentences that you do not have now?
Click to expand...

One program that can color correct and transcode, with audio in the most time efficient manner and can understand an EDL from final cut or avid. One that can batch looks and easily open multiple files as well as set in/out points for each.
 
SF Geek said:
One program that can color correct and transcode, with audio in the most time efficient manner and can understand an EDL from final cut or avid. One that can batch looks and easily open multiple files as well as set in/out points for each.
Click to expand...

They are a lot of programs doing that, working with QT, DPX... and there are a lot of software developpers eager to implement R3D support using a fully fonctionnal SDK.

I've been told here in the forum that R3D support will happen in the "next few years".

:innocent:

Patrick
 
I work with a lot of Post Houses over the world and I don't know one of them who actually uses a workflow hardware or software that benefits from the SDK at this given moment. I'm not including the ones who has Scratch in their workflow system.

(All of them has developed successful workflows but they're all work around)

So in many ways I think what Patrick writes is right. I also see his post being intended as a cry for help. I think that asking to make the SDK better is not wrong and it no ways means that it's not good that it's out there. It just simply means that as it is (the SDK) right now, it's not really there, at all.
 
It is interesting that Scratch involves workarounds, too...

I think what we're waiting for is roomsized hardware to come up to speed with te current RED (which doesn't debayer for a reason). When that has happened.... we'll all have epics and still be pulling our hair out :)

We're sorta on the wrong end of the technology. DV works just fine by now...
 
gunleik said:
We're sorta on the wrong end of the technology. DV works just fine by now...
Click to expand...

Exactly. For some reason, many people think this stuff happens a lot faster than it does. It took SEVERAL YEARS for DV to become a user-friendly and widely supported format. And that was even with it seeing rather quick and widespread adoption on the consumer end of the market. Look at the state of DVCPROHD P2 workflow... How many major NLE systems still require third party tools and work-arounds.

Lots of posts where people complain about developer support and no new software coming to market. The SDK has only been available for about 90 days. This stuff takes time. I'm not aware of any developers who are really complaining about the SDK... Most have a long list of what they would like to see implemented, some even think they're entitled to customized requests, but that's a different matter. See Deanan's post in this thread.

I used control over the debayer and image quality as one example or reason of why RED doesn't simply open up the R3D file format and data specs. There are many other reasons that have been mentioned, I'm sure there are other internal reasons that haven't been mentioned.

All the workflow FUD and misinformation gets so tiresome. It's mostly spread by RED competitors or those who have vested interests in other workflows that may feel threatened. If I had $500K invested in HDCAM hardware and workflow implements, I might have serious issues with RED workflow whenever a client brings it up.

There are many ways to approach RED workflow. The available tools are evolving quite fast, even though it seems rather slow when you work with them every day. Lots of new things on the horizon and I think by NAB in April, there will be lots of exciting new options. With the introduction of Scarlet and other future cameras, I can only see an increasing number of developers supporting the RED workflow.
 
Which NLEs edit HDCAM or HDCAM SR natively?

Graeme
 
weirdcrew said:
I work with a lot of Post Houses over the world and I don't know one of them who actually uses a workflow hardware or software that benefits from the SDK at this given moment. I'm not including the ones who has Scratch in their workflow system.

(All of them has developed successful workflows but they're all work around)
Click to expand...

Having worked in post houses for 20 years, EVERYTHING is workaround to some extent.
 
Graeme Nattress said:
Which NLEs edit HDCAM or HDCAM SR natively?

Graeme
Click to expand...

From my memory:

there were 2 failed native HDCAM systems Sony Xpri and a version of DPS velocity (eyeon spent ages cleaning and re-writing the codec to be less cpu expensive for DPS)

IMHO SR is too high bandwidth to be worth the trouble of native suport.

regards

Michael
 
This whole thread reeks of someone who doesnt understand software development getting information from people who understand it even less. You write code then you test test test. And when you think you are done testing, you test some more. Everything takes longer than expected - usually because you are breaking new ground. As one who is currently working with the R3D SDK, yes there are limitations and requests but slowly we are getting things working.
 
SF Geek said:
One program that can color correct and transcode, with audio in the most time efficient manner and can understand an EDL from final cut or avid. One that can batch looks and easily open multiple files as well as set in/out points for each.
Click to expand...

That is on it's way - I have seen it - and it's NOT Adobe or Apple.

But I will say this - to all the folks who don't have Scratch - and even the folks like us that do - I have said it many, many times before - native R3D support within the Adobe suite is a GAME CHANGER - not ONLY in terms of "Red post workflows" - but in terms THE POWER & QUALITY A FILMMAKER/PRODUCER CAN HARNESS WITH A FRACTION OF THE BUDGET OF 35MM PRODUCTION & POST. PERIOD.

The integration between Adobe apps is nothing short of stunning, add to that fact it's cross platform, the bounty of plug-ins available for After Effects - (http://www.pluginz.com/After+Effects), the available SDK for Adobe applications and NUMEROUS solutions for INTEGRATION WITH PRETTY MUCH ANY APP. Try to give me an example of a professional application, 3D, compositing, etc. that you can't import/export via a 3rd party plug-in. You name it - PFTrack, Maya camera import, etc. etc. etc. -

Take a deep breath ... you will get everything you want and more than you can imagine.
 
reality said:
Having worked in post houses for 20 years, EVERYTHING is workaround to some extent.
Click to expand...

Exactly. That is what a WORKFLOW is. It's not a single application. It's not a single platform.

It's a way to get from A to B. That works.

You can hit a small nail with a big hammer ... or a big nail with garage of tools. It's really not the point.

But if you get A to B .... you have a WORKFLOW.

Please want speed and ease. People want intuitive UIs. People want everything for free. If there's a demand .. clever folks make the solutions and the "workflows" get easier and cheaper.
 
Graeme Nattress said:
Which NLEs edit HDCAM or HDCAM SR natively?

Graeme
Click to expand...

Ehm well, Sony Xpri worked with HDCAM natively, and Smoke/Flame also used to have an HDCAM codec option.

In fact the coolest thing about Xpri was the faster than real time HDCAM transfer feature.

Dead in the water now of course but it did exist. SR of course is a different matter, I could argue that DPX is the native file format for SR workflows but thats a different matter.
 
You must log in or register to reply here.
Back
Top