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

The IBC betting game - realtime 2k or more out of RAW files - How many?

Hey David,

I get the subjective nature of demosaic algorithms, and what can be perceived as "better."

I think I may have just misread Laguun's post. I initially thought he was saying that GPU-based debayer was universally better. Rereading it, I don't think that's what he meant. : )

Tx,

Lucas

yeah, i think you misread:
Iridas, as example, is delivering Speedgrade XR which is using GPU-basing debayer, which is much faster and allows better quality debayer in less time than the CPU-basing approach.

better quality in *less* time is the keyword.

Naturally, one could also use the faster GPU speed to utilize even more sophisticated debayer algorithms which would be much to slow on an octacore.
 
I'm not providing an endorsement of any one toolset here, but I'll share my experience from a unique perspective of having had access to pretty much ALL of the relevant software platforms -and the fastest hardware platforms currently available.

None of the testing we have done (and we have done ALOT) has shown any evidence that GPU-based processing of RAW clips provides any wide margins in "performance" or "image quality" compared to CPU-based processing or other "hybrid" GPU-CPU approaches. This assumes, of course, that there are further coding optimizations that and will can be made by all the vendors in this space.

My base of experience includes testing of several RAW 2K, 3K and 4K formats on several different technology (software) platforms.

The point is, I think it's an overly simplistic view to simply say that one methodology is "better" or "faster" than the other. There are trade-offs, and of course much of the criteria used to measure these metrics is subjective by nature.

I feel confident that sooner than later, there will be a plethora of options for any number of RAW workflows.

It's a sure bet that if there is a novel approach to improving the state if the technology, there is a small team somewhere in a development lab piecing it together.

It's still early in the game and we all see this technology maturing every day.

This said, I'll make a prediction. I'll predict that there will be no new realtime 2K (or dare I say 4K) solutions for native RED clips at IBC.
 
I'm not providing an endorsement of any one toolset here, but I'll share my experience from a unique perspective of having had access to pretty much ALL of the relevant software platforms -and the fastest hardware platforms currently available.

Hello Boxxlabs.

So, do you "tested" discreet smoke, flame, inferno, quantel q-series, iridas speedgrade, dvs clipster then?

i am surprised, because most of these software vendors dont recommend your assemblies, but hewlett packard

None of the testing we have done (and we have done ALOT) has shown any evidence that GPU-based processing of RAW clips provides any wide margins in "performance" or "image quality" compared to CPU-based processing or other "hybrid" GPU-CPU approaches. This assumes, of course, that there are further coding optimizations that and will can be made by all the vendors in this space.

So, have you been unable to reproduce the speedgains (which are multipliers on any system) because you werent able to install the correct driver or because you only run a demo license of flame?


The point is, I think it's an overly simplistic view to simply say that one methodology is "better" or "faster" than the other. There are trade-offs, and of course much of the criteria used to measure these metrics is subjective by nature.
Other people usually call this "technology".
Thats these companies whose parts you buy and plug into each another - intel and nvidia.
The technology is called "benchmark" - you take a watch and reproduce the same process twice.

If you didnt succeed in getting better performance - we offer great trainings.

I feel confident that sooner than later, there will be a plethora of options for any number of RAW workflows.
really?
do you think that adobe and autodesk will also offer raw workflows? that is really surprising! would they maybe switch from HP to boxx systems because your intel cpus are so much more awesome?


It's still early in the game and we all see this technology maturing every day.
This said, I'll make a prediction. I'll predict that there will be no new realtime 2K (or dare I say 4K) solutions for native RED clips at IBC.
Certainly not from Boxxlabs.
But realtime 4K raw options - now, there will be plenty. As there have been.

BTW: Do you think that all your platform are outdated once nehalem systems can be sold by you or do you think that this is just a slight incease in power?

btw: do you still mainly use tyan motherboards?

ps. do you have a booth a IBC? we are at 11G31.
 
Absolutly true.
And its excellent what red achieved so far - really outstanding.
The camera is great - quality, price, features...

However, some peices of the puzzle still have to come together: many people (that includes us over here) are *not* happy with the workflow yet, and it makes no sense denying this.

red improved a lot on feedback, red convinced a lot of skeptics with its quality, and in order to convince the nay-sayers in the post world the best way is simply to solve the problems (sound, windows, edl/tc) and to have the camera supported by the best of the best.

red already succeeded in bringing a real small revolution to the camera market, taking for good reason the lions share of the 35mm market. But in post, most systems are not compatible. As like the camera wouldn´t have an Arri PL mount, but rather an eclair mount, not a V-Mount, but a notebook-battery etc. Sure, us here at reduser would find a way around it - but the common cameraman would be somewhat irritated - and thats still (hopefully soon to end) situation in red postpro.

Certainly RED has demonstrated their willingness and desire to listen to good feedback. The problem seems to be those who can't figure out how to offer constructive feedback.

To me singling out a specific issue that you don't like and stating that RED's justification for implementing that feature is flat out "not valid" simply because it's not something fits your specific desires, begins to cross the line.

When RED states that feature X is coming, and they need some time to ship it, all the while demonstrating commitmement to deliver new (and often unadvertised) features to current owners at an amazing pace (and price), and then people gripe that what they want isn't here fast enough, that begins to cross the line.

When people make statements like "there are tons of things that can be done with no resources", and then tie that in to RED having a bad attitide, all the while not having the perspective that RED is attempting to build an ecosystem, and not a single product that's just what YOU want, that begins to cross the line.

But hey... maybe those people are tired of having such unfettered access to the process of developing an amazing product family, and want to see if they can piss off the guy who owes you nothing by continuing to post with such an attitude of entitlement.

-Steve
 
Come on, I wrote graphics file readers when I was 14 in QuickBASIC (dealing with RLE compression in PCX files, etc). It didn't take me that long.

Also, COME ON. The major aspects of the file format (JPEG2000) are not changing.

Documented file format updates are NOT A PROBLEM (and Red has to document them anyway to share with existing partners - this is not extra documentation work). This is smoke and mirrors.
(emphasis mine)

Pease tell me a file parser you wrote in basic is NOT your basis for claiming the developing an entirely new file format that is cross platform (including being generated by a real-time embedded system), and implementing features for hardware which still is evolving is a trivial task.

Shall I even bring up that this format will likely be consumed by dozens (if not hundreds) of different software packages over time, and often on projects with multi-million dollar budgets?

To quote Seth and Amy, "REALLY?!?"

-Steve
 
Hello,

A couple of things which are answers to various mails in this thread. We at Digital Vision showed Red Raw files being conformed on our systems (commonly refered to as Nucoda) at IBC last week. We were conforming from EDL's created using Metacheater which have a 16 character tape names. Having conformed we could grade, or export DPX

We could also batch load all the rushes and then export DNxHD MXF for offlining.

Regards

Nigel Hadley
Director of Training
Digital Vision
 
Back
Top