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

Two Weeks... Change is COMING!!

mdharrington said:
being that i am a customer....no
I don't usually stop and think about what Red thinks of footage I shot with my camera.

Maybe we should slap on a proprietary lens mount so only...the best lenses can be used, so as not to embarrass Red with our poor lens choice.
Click to expand...

I guess I am not very good at making a point.

There is some serious disinformation, speculation and conspiracy theories that are simply far from the truth.

I'm gonna leave this whole damn topic alone - because, as my grandfather used to say, everything comes out in the wash.
 
I hear ya....

This will all be a thing of the past in a few days.
 
Offhollywood said:
Well ... what they "figured out" was how to take the recorded frames and debayer them - with their own algorithm - which is NOT the same as RED's debayer.

Different results.

And somebody may use that - and say "it looks great" or "good enough for me" ... but you know ... did you ever stop to think that it might not be good enough for Red.

Iridas and Cineform never played r3d material with exactly the same quality and results as Scratch does with Red's RedNode for Scratch.

Assimilate doesn't debayer R3D any way they want - they debayer with the Node from RED. You download that from the RED.COM/support page

This is something that so many people fail to understand.
Click to expand...

I don't think it's "Fail to understand" Mark... Some of us are pretty smart you know.. I think it's more "choose to disagree". I have a good set of eyes, and I have seen Cineform's latest debayer work at NAB. And, yes, it's good enough for me, and it's good enough for my clients.

And by good enough, I mean.. Excellent.

Enough said

Jay
 
I am glad that Red made build 16 less noisy. But CineForm's debayer of build 15 is already less noisy than RedCine or RedAlert debayers of build 15. IMO. Good call on leaving this thread Mark.
 
Mark Crabtree said:
I am glad that Red made build 16 less noisy. But CineForm's debayer of build 15 is already less noisy than RedCine or RedAlert debayers of build 15. IMO. Good call on leaving this thread Mark.
Click to expand...

So what you're effectively saying is that Cineform knows more about the R3D format than Graeme. You sure you want to go there? :)

Lucas
-----
ASSIMILATE, inc.
LA, CA, USA
 
guess some people aren´t looking forward to the release of the SDK.

in the sad case of a delay... cui bono?
 
I'll happily go there, Lucas. How many countless times throughout history has a product or idea been improved upon by others than the original creator? -- Fresh minds bring fresh perspective and fresh ideas. This holds true for software as much as anything else.

And for the record, the issue of 3rd Parties decoding the R3D isn't about the debayer process. Every demosaic/debayer algo out there has pros and cons. Different shooting environments, etc. will produce images which are better suited for different algos.

What makes RED unique in decoding their files, is the intellectual property of the matrices that build the resulting color/luma maps from the meta data. And in the end, this is all about the personal tastes of the Director/DP and the trained eye of the colorist.

With build 16, this is a little bit different because they have actually changed the way the images are encoded/decoded, and pulled some of that data into the application, rather than (traditionally) keeping it with the file. This is good because it reduces file size, and helps ensure consistency in how images from the sensor are compressed/decompressed.

But in the end, the same holds true... The magic is all about how the data/bits are handled from stage to stage. After all those stages, you have an image which is either pleasing to the eye, or isn't. And there will always been discriminating eyes and brilliant minds who argue that the image produced by the current tools "suck" and will find clever way to make it "better".
 
luki said:
So what you're effectively saying is that Cineform knows more about the R3D format than Graeme. You sure you want to go there? :)

Lucas
-----
ASSIMILATE, inc.
LA, CA, USA
Click to expand...

He didn't "want to go there" Lucas.. You simply spun what he said in an effort to "take him there".

I've been reading the english language for a long time, and I read that he liked the look of the Cineform debayerbetter then Red or RedAlert in regards to build 15. The software, not the company. I cannot find Graeme's name in there anywhere, not can I find a reference to Cineform knowing more about r3d.



Jay
 
I hate it when these things always degenerate into this kind of discussion.

If you read the heading it's about my excitement over the SDK being released and the possibilities that offers us all.

For those of you that are in love with and/or own MACs or a SCRATCH systems, I say "congradulations, and best of luck in your career".

But your business choices have no bearing on mine. Every system I have worked with has things I love and HATE. It's a matter of balance, and getting the system which gives you the most for what you need and can afford.

The REASON I am excited about the SDK is that this will allow more vendors to offer more choices and in doing so increase both the cameras ability, and appeal. All of this adds up to more work for me. Not to mention more creative choices in my projects.

And for me, that's what it's all about.
 
Mods (Someone other than Offhollywood and Luki since they posted)

I'd like to suggest we remove this thread. I don' t think it's revelant at this point. The SDK will be here soon, but perhaps a countdown mentality is not the best idea.

Jay
 
Offhollywood said:
Well ... what they "figured out" was how to take the recorded frames and debayer them - with their own algorithm - which is NOT the same as RED's debayer.

Different results.

And somebody may use that - and say "it looks great" or "good enough for me" ... but you know ... did you ever stop to think that it might not be good enough for Red.
Click to expand...

That's like saying that everyone should use Nikon or Canon's standard debayer algorithm for DSLRs.

I'm glad Adobe, Phase One, Bibble, etc DIDN'T.

Bruce Allen
www.boacinema.com
 
Jay A. Kelley said:
3 days
Click to expand...

you've got 1.5 to go...!!

luki said:
So what you're effectively saying is that Cineform knows more about the R3D format than Graeme. You sure you want to go there? :)
Lucas
ASSIMILATE, inc.
Click to expand...

You're backing your boy...he's a smart fella who has put in a hellva lot of work into his product, which isn't to say the boys at Cineform aren't clever and done the same.
But before you make this into a pissing competition where you pit Red's abilities against one of your competitors..I suggest you stop and see how blatantly bulging in self interest that looks to everyone here.
You want to go there?
I'm sure you do....but we don't!!
D
 
david farland said:
you've got 1.5 to go...!!

I suggest you stop and see how blatantly bulging in self interest that looks to everyone here.
You want to go there?
I'm sure you do....but we don't!!
D
Click to expand...

There are a number of things that are tied to camera firmware and hardware and this is why there will be an sdk fo deal with all the complexites. When someone reverse engineers a format, they're guessing at a number of things and that puts both our customers and their customers at risk. Things will continue to change with the format/codec and maintaining compatibility in a central place (ie. SDK) is the proper way to go.
 
Deanan said:
There are a number of things that are tied to camera firmware and hardware and this is why there will be an sdk fo deal with all the complexites. When someone reverse engineers a format, they're guessing at a number of things and that puts both our customers and their customers at risk. Things will continue to change with the format/codec and maintaining compatibility in a central place (ie. SDK) is the proper way to go.
Click to expand...

I'll jump in and acknowledge Deanan's comment. Remember, we've been doing in-camera RAW compression plus deBayering algorithms for about four years so we understand these things.

Unrelated to deBayering, and as Deanan indicated for Red, CineForm also does some post-processing upon *decode* of CineForm RAW (when C-RAW is used in-camera such as the SI-2K) that should be considered part of the camera's signal processing chain. So if somebody were to understand our format and decode it without understanding the post processing we apply upon decode, the images would not be identical to those decoded by CineForm. These algorithms are somewhat sensor/camera dependent. Hence, we understand Red's preference to control the decode of the files back to uncompressed RAW.

Hopefully the SDK will present the uncompressed RAW file(s) for further processing (including DeBayer) by third parties. But we, like others, will have to wait and see the details.
 
Deanan said:
There are a number of things that are tied to camera firmware and hardware and this is why there will be an sdk fo deal with all the complexites. When someone reverse engineers a format, they're guessing at a number of things and that puts both our customers and their customers at risk. Things will continue to change with the format/codec and maintaining compatibility in a central place (ie. SDK) is the proper way to go.
Click to expand...

Deanan, do you own a DSLR? If so, please tell me what converter you personally use to read the RAW files. Does that converter use a centralized Nikon or Canon-approved SDK? Or do they just read the file on their own? I suspect the latter, for speed and quality reasons.

Does this mean that Red won't release the file format specs, or allow people to read the files directly? Eg all data accessed will have to be through calls to Red SDK functions?

Hope those functions are super-fast, real-time, cross-platform and allow access to the raw (pre-debayered) data. Just saying.

Otherwise it will hobble 3rd parties who try to play by the rules. I'm sure the ones who care about performance would much rather just have access to your file format specs. Even if Red changes the file format drastically, it's not a big deal to update if the changes to the format are documented.

Bruce Allen
www.boacinema.com
 
Bruce Allen said:
Deanan, do you own a DSLR? If so, please tell me what converter you personally use to read the RAW files. Does that converter use a centralized Nikon or Canon-approved SDK? Or do they just read the file on their own? I suspect the latter, for speed and quality reasons.

Does this mean that Red won't release the file format specs, or allow people to read the files directly? Eg all data accessed will have to be through calls to Red SDK functions?
Click to expand...
It would be terrible if no one could access the fileformat directly - that is necessary for more versatile, better & faster decoding solutions, especially the one adding hardware power besides CPU.

But red always spoke about documenting the fileformat (which is, iirc, pretty much JPEG2000 anyhow) once R16 is implemented.

Bruce Allen said:
Hope those functions are super-fast, real-time cross-platform and allow access to the raw (pre-debayered) data. Just saying.
Click to expand...
That wont help to much with the most powerful solutions as clusters (i.e. baselight) or sheer hardware power (dvs clipster) - and these are the only realtime 4K options right now.


Bruce Allen said:
Otherwise it will hobble 3rd parties who try to play by the rules. I'm sure the ones who care about performance would much rather just have access to your file format specs. Even if Red changes the file format drastically, it's not a big deal to update if the changes to the format are documented.

Bruce Allen
www.boacinema.com
Click to expand...
100% correct - i have to agree here.
 
Bruce Allen said:
Deanan, do you own a DSLR? If so, please tell me what converter you personally use to read the RAW files. Does that converter use a centralized Nikon or Canon-approved SDK? Or do they just read the file on their own? I suspect the latter, for speed and quality reasons.

Does this mean that Red won't release the file format specs, or allow people to read the files directly? Eg all data accessed will have to be through calls to Red SDK functions?

Hope those functions are super-fast, real-time, cross-platform and allow access to the raw (pre-debayered) data. Just saying.

Otherwise it will hobble 3rd parties who try to play by the rules. I'm sure the ones who care about performance would much rather just have access to your file format specs. Even if Red changes the file format drastically, it's not a big deal to update if the changes to the format are documented.

Bruce Allen
www.boacinema.com
Click to expand...

I'm going out on a limb here and saying that I am pretty sure RED is going to grant the access everyone needs to the R3D files. To force people into a specific pipeline with the SDK would massive step backwards, and would do horrible things to the potential of the camera and it's choices for post... Not to mention speed.

Besides, it would only be a matter of time before the file is hacked by someone who wants to do a better job of meeting customers demands in regards to things like speed.

No... RED knows what its customers (like me) have been BEGGING for for quite some time. They are not going to do anything like that this late in the game. If they were, they would have warned us early on rather than crush our hopes.

Jay
 
You must log in or register to reply here.
Back
Top