WHY!!!! are people still using color baked DPX's F&%*@#%*#K!

[jake blackstone]

You sound a bit angry Jake... ?

Do I?
Just because I don't jump from joy at any "new" color science iterations, that should had been done right in the first place? RedLog anyone? Or because I don't buy this demonization of DPX?
Funny thing Mark. It seems, that you yourself, without even realizing it use DPX for grading every time you use Resolve. Why? Because, as you know you can't grade RAW. First RAW has to be debayered, decompressed and finally gamma encoded, be it linear or log. Only then you can start grading it. And guess what happens in Resolve or for that matter in any other grading software? The same process, except some software, like Nucoda or Flame/Smoke does it explicitly in the background and actually writing DPX to the drive, while other, like Resolve or Baselight (instead of DPX, it uses uncompressed 16 bit RGB files) do it on the fly and keeps it in the RAM without writing it do disk. But it's the same process. So, I don't understand this notion, that using DPX is bad and anyone still using it is wrong. There are many reasons why you'd want to use DPX, as few already pointed out. May be if Red would stop releasing new SDK every few months, may be then manufacturers would have a chance to catch up with "newer and more better" SDK. In the same time frame, how many SDK did ARRI released?
I work with pretty much every camera out there. I can't afford to favor any camera, Red is just one. And I do what I have to do to keep up with ever changing technology in order to provide quality service. Said that, Red clearly takes more time to keep up with, than all other cameras combined. May be Red should listen a bit more instead of keep talking over users. There is a clear need to simplify and KiPro or Sound devices is not it...
No, I'm not angry

 

[Mark Toia]

Jake,

My original post was about poorly made (colored) DPX's created by some unskilled monkey in a back room, and then I was ranting about how flame operators didnt know how to conform in flame (easily) using RED tools within... or post house not conforming and at least spitting out good tech grades or best grading the images in Resolve or baselight scratch anything!!!!.... other than a 2 day mac export from Redcine X in some contrasty default setting from shoot day.

The DPX format is fine... I don't have an issue with DPX. but having people just transcode shit is my gripe !!
Once its transcoded poorly from the start, you, me and anyone else that touches that file cannot make it good again. Thats a FACT.
It's the same as a BAD one light! or a bad tech grade... or a bad film scan, once its baked its gone! unless you go back to the RAW file. (hence why I like to have those close by)

I also make DPX's for our effects work. but the ones we make are colour corrected to the cleanest white-balnce - REDFLOGFILM Log look, or beautifully graded before hand... So then at least the flame artist or colourist (like yourself) has a great image to play with at the end or during the composite.

If the job does not need any effects in it, then we just grade directly from the R3D's (irrespective if the Resolve makes background DPX... I don;t care... so long as Im working from the RAW file from a log base... Then Im happy.

So Jake.. again, this is not a discussion about DPX, but more about how (professional post house) people make shit colour bake ones !

I pretend that the R3D is film... and I make make propper tech grades or log scans to work from or grade from the film directly...

Nothings changed. Just the film emolsion and the telecine itself has left the building..



Okay everyone.. we back on track. )))

 

[Philipp Straehl]

Because, as you know you can't grade RAW. First RAW has to be debayered, decompressed and finally gamma encoded, be it linear or log. Only then you can start grading it. And guess what happens in Resolve or for that matter in any other grading software? The same process, except some software, like Nucoda or Flame/Smoke does it explicitly in the background and actually writing DPX to the drive, while other, like Resolve or Baselight (instead of DPX, it uses uncompressed 16 bit RGB files) do it on the fly and keeps it in the RAM without writing it do disk. But it's the same process.

I admit I wasn't really aware of how this real-time debayering actually works in the machine. Thank you for pointing that out.

 

[Jason Diamond]

Agreed 100% Mark. We recently went thru a similar experience with a well known Hollywood DI facility which I will not name here.
They are extremely open to learning from us and did the opposite of your experience and brought us in to help model the proper workflow to get the best out of the files as they are extremely interested in native pipelines where applicable.

This is the way all facilities should at least start their pipelines until and when they need to go to a different format for VFX, etc but at least they will then understand how the Native files function and can get the best out of them as you aptly pointed out.

 

[Mark Pugh]

I love PRORES 4444 / REDLOGFILM @ 4k is all Ill need for the next 10 years !
Who ever makes that happen straight out of a camera body will have my dollars immediately sent to there bank account.

As a DP who more often than not is in a different city, or country by the time online takes place, I'm sure I'd have been better served, more than once, by just handing over good LOG Prores files, rather than a bunch of RAW files.
I've seen good shots screwed by poor transcodes to DPX.
Mark Toia in your opening post you're illustrating the real risks of a RAW workflow, and there's definitely times in commercial work, when that risk would be best avoided.

 

[Rob Lohman]

Good discussion. We are listening.

I want to correct a piece of wrong information. The reason we have a Rocket has nothing to do with the debayer/demosiac, it has everything to do with the decompression. Bruce: GPU can't do our decompression faster, trust me, I've tried. All those other cameras don't do compression + 4K/5K. ProRes 1080p ain't the same game.

 

[M Most]

Y

and to be honest. I've had the shits with clients and suppliers in the past and pushed them away from my business me due to bad attitudes... I don't have a clue what Jim or REDs issues are with the people you have mention above... but Im sure there are two sides to the stories..

As I recall, the "official" line was that they (Red) didn't want third parties coming up with their own debayer algorithms because they felt that if they were inferior, it would give the camera - then a relatively new product trying to make a mark - a bad name, particularly when many were criticizing things like the noise level, compression issues, and the like. As I also recall, they not only asked Iridas to stop developing their own debayering and decompression technology, they also began encrypting the files so that nobody else could do it, either - like Cineform, for instance.

This, to me, isn't "good" or "evil," it just indicates that Red was both very protective of its IP, and at the same time very reluctant to have partnerships at that point in their development.

 

[Rob Lohman]

Wow. The encrypting comment is still around? That has never been the case (I know, as I designed the R3D format). This is why we have a great SDK, you don't have to worry about our file format changes. We handle that for you.

In the end we want our products to make the best images, be the easiest to use and be affordable

 

[M Most]

All those other cameras don't do compression + 4K/5K.

From what I've been told and the demos that I've seen, the F65 does. And also from what I've been told and seen, they do real time decompression on commodity GPU's.

I think what Bruce was doing was urging Red to do their best to port their decompression algorithm to those commodity GPUs, even if it ultimately requires more than one card to be present. Two $500 cards are still a lot less than one $5000 card. And they have value for cameras and files other than R3D. The Rocket was a great development, and it has largely served its purpose. But today, many people and companies are reluctant to buy into anything proprietary, especially when it only deals with one type of file. That's a situation that what many here seem to call "democratization" has created.

 

[M Most]

Wow. The encrypting comment is still around? That has never been the case (I know, as I designed the R3D format). This is why we have a great SDK, you don't have to worry about our file format changes. We handle that for you.

And that's a very good design decision. However, the file format also changes a bit too regularly, thus breaking any software other than yours that hasn't released an update. And most third party software publishers have other things to think about than doing maintenance upgrades every time there's a new R3D file and/or SDK revision.

In the end we want our products to make the best images, be the easiest to use and be affordable

I understand that and support it. Once again, though, the notion of "the best images" and "the easiest to use" are sometimes in conflict if you do a file format revision every time you come up with an image improvement.

I think Bruce and I are saying a lot of the same things. Something of a cottage industry has grown up around your products, and third party supporters are now relied upon by many of your users, particularly those companies that have designed pipelines to handle both your files and other cameras as well. Sometimes supporting your customers requires holding back a bit on new releases and allowing them to be seeded and integrated by those third parties prior to general release. The atttitude of "you have to keep up" just doesn't always fly in an industry that values stability, requires efficiency, and doesn't necessarily want to use RedcineX as primary software.

 

[jake blackstone]

I had been told about 6 months ago by the program manager at one very prestigious high end post manufacturer, that they were ready to assign a team of engineers to work on R3D GPU debayer, only to be waved off by Red. Yes, Red said no go. So, that team was reassigned to work on GPU debayer for F65. Hm...

 

[Rob Lohman]

I was talking about decompression, not debayer. Debayer can go very well on to a GPU.

Mike: we've only done a couple of file format updates over the last 4 years, none of which had to do with image improvements

Understood about the integration issue. It's hard to give new cool features and get it out there. How long should we wait for everyone to integrate updates?

Anyway, we appreciate the discussion

 

[Bruce Allen]

Good discussion. We are listening.

I want to correct a piece of wrong information. The reason we have a Rocket has nothing to do with the debayer/demosiac, it has everything to do with the decompression. Bruce: GPU can't do our decompression faster, trust me, I've tried. All those other cameras don't do compression + 4K/5K. ProRes 1080p ain't the same game.

Rob - when did you last try? With a modern Fermi setup, like GTX580, or a previous architecture?

I put Graeme in touch with my friend of 10 years at nVidia (he used to do DirectCompute driver stuff for Fermi).

If you guys are ever interested in trying again (especially when Kepler comes out)... and I can ever help, please let me know if there's anything I can do.

Bruce Allen
www.boacinema.com

 

[Rob Lohman]

Bruce: this was pre Fermi, but that doesn't really change the problem (it has to do with the compression algorithm). But yes, we're always open to try again as things change, technology is always marching forward. It's going to be an exciting year with RED, and that's true for post as well

 

[Sergio Perez]

Its this sort of communication that makes this forum great. I've learned a lot in this thread. Thank you to all involved in this. Just ordered a rocket and it should arrive tomorrow.

 

[Roberto Lequeux]

Bruce: this was pre Fermi, but that doesn't really change the problem (it has to do with the compression algorithm). But yes, we're always open to try again as things change, technology is always marching forward. It's going to be an exciting year with RED, and that's true for post as well

Really? Fermi was a big jump, and the same is happening with Kepler. There is an other leap coming if Kepler doesn't do the trick, but if you didn't try Fermi I'd say that we might already be there! This chart is just efficiency, but with efficiency come the goodies... We would love you if you tested decompression out on them again.




Alleged/rumored performance gains with Kepler are sick: http://hexus.net/tech/news/graphics/34261-nvidia-gtx-6xx7xx-kepler-rumour-round-up/

However, the bulk of this rumour has been formed from unconfirmed, leaked performance slides of the new Kepler series of GPUs.

 

[M Most]

Understood about the integration issue. It's hard to give new cool features and get it out there. How long should we wait for everyone to integrate updates?

I guess the easy and rather flippant answer is as long as it takes for the major third party suppliers to tell you that they have updates ready to go out. But the logical answer is probably for Red to discuss this with those same suppliers and get some kind of consensus as to what's sensible in terms of lead time for them to integrate, test, and "bless" any new SDK release. Red, at the outset, was living in something of a vacuum, with the only serious support coming from themselves and Assimilate. That is no longer the case. Red is now a mainstream camera supplier with a unique format, and a lot of post companies and individuals now rely on equally mainstream third party programs for their support of that format. Becoming a bit more mainstream carries with it a bit of responsibility to be responsive to those new needs. It's probably time to let go of the "we're not a scam" chip that some still seem to carry around on their shoulders and embrace the success that has led to that new status. Part of that might very well include accepting and embracing the importance of the third party support.

That's what I think, anyway. But you did ask.....

 

[Rob Lohman]

I know about fermi, I've had good conversations about it. This problem is not (just) about speed, I wish it was! The game comparison doesn't really apply here.

 

[Rob Lohman]

Appreciate your thoughts Mike! As an example, there are partners who have year long (or longer!) cycles. It's a tough one. There's people who want it now and there's people who want broad support. Such is life I guess?

 

[Roberto Lequeux]

So I guess it has to do with other 'less important' aspects of the card. Think we might have gotten lucky with Kepler?

Pretty please do test it out.