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

So I bought Gluetools....

NoahK said:
Sweet- you can actually see that live!

http://www.wien.gv.at/english/webcam/stadtpark/index.htm

Noah
Click to expand...

strauss_handheld2.jpg

Even "sculpted girls" around monument are getting crazy about JS.

In a real world girls in the park keeping eye on a guy with RED camera that has also JS initials :) .
 
Hi
Just about to purchase Gluetools too , I'm still having the 24/25 fps timecode problem with dpx files out of Redcine ( 25fps files coming out with 24fps timecode ), can anyone confirm if you can use gluetools to duplicate the dpx files with the correct timecode ? Actually Gunleik have you worked out a solution for this by any chance ?

Thanks Marcus


www.belladonnathemovie.com
 
Cyclotron said:
Hi
Just about to purchase Gluetools too , I'm still having the 24/25 fps timecode problem with dpx files out of Redcine ( 25fps files coming out with 24fps timecode ), can anyone confirm if you can use gluetools to duplicate the dpx files with the correct timecode ? Actually Gunleik have you worked out a solution for this by any chance ?

Thanks Marcus


www.belladonnathemovie.com
Click to expand...

Try the demo and you can see for yourself it's free up front....

Noah
 
NoahK said:
Try the demo and you can see for yourself it's free up front....

Noah
Click to expand...

Unfortunately timecode is one of the things that is not enabled in the demo version.

I have not yet had any success with getting Redcine to write correct 25 fps timecode into DPX headers, but I spoke to somebody from Assimilate at NAB, and he said they were aware of the problem and the reasons for it. So let's hope it will be sorted soon.
 
Nick Shaw said:
Unfortunately timecode is one of the things that is not enabled in the demo version.

I have not yet had any success with getting Redcine to write correct 25 fps timecode into DPX headers, but I spoke to somebody from Assimilate at NAB, and he said they were aware of the problem and the reasons for it. So let's hope it will be sorted soon.
Click to expand...

I'll ask the developer about that and get back to you...

Noah
 
I can't really say much about TC issues and such yet, but I did a quick test tonight, just a small clip.

The bad: I went a bit ape in color (it was so fun) and some very strange rendering issues in color (that trashing the preferences got rid of btw.

There're also some serious gamma issues I'll have to learn how to compensate for...

I will also have to run through all my RED-test clips once more.... Guys, this is the real dope. The AJA wrapper is not the same thing. It's almost as addictive as RED itself. I guess there are bugs and hazzles, but you'll never look back.

the stupidfun test:
here
http://byacserv.com/vulture/elnaz_01.mov

Don't take it as a grading or aestetic example. It's not. It's more like porn, or overplaying a new toy, because this was like getting COLOR all over. On stereoids...

Thanks Noah!

Gunleik
 
NoahK said:
I'll ask the developer about that and get back to you...

Noah
Click to expand...

Hi Noah,

yes, you can override the frame rate and timecode of the incoming frames. ie: if the frames are 25 fps, but have 24fps in the header, my software will let you export a duplicate set, with 25 (or any other frame rate) in the header.

bob.
 
macgregor said:
Why do i want to use the timecode embeded in the DPX if i have started capturing as digital files in the first place? WHat help can a timecode give me here?
Click to expand...

I would always want to be able to reference the DPX files back to the .R3D files they were generated from, and timecode is the only way to do that easily.

If you generate DPX frames, and treat those as the new master, you don't NEED to be able to trace back to the .R3D files, but I would not call that best practice, as you are eliminating much of the flexibility of RAW.
 
Nick Shaw said:
I would always want to be able to reference the DPX files back to the .R3D files they were generated from, and timecode is the only way to do that easily.

If you generate DPX frames, and treat those as the new master, you don't NEED to be able to trace back to the .R3D files, but I would not call that best practice, as you are eliminating much of the flexibility of RAW.
Click to expand...

Exactly- you never know when you might want to go back to your .R3Ds and it's easy enough to setup.

Noah
 
Hi Noah - I've been enjoying your blog, great stuff on there. Any chance that you will be posting about Gluetools or working in DPX files, for those of us who may not have worked with this format before? I feel like there is stuff that I should know, that I don't...just purchased a license at NAB and feeling my way through it. I finally had a chance to load it yesterday, and I know I'm doing something wrong. There's no RED-specific info in the guide.

And Gunleik, I'm glad that someone is initiating a discussion about this product. It has been flying under the radar for quite some time, with occasional allusions to it, but not much straight-up info.

10-bit 4:4:4 uncompressed files round-tripped between Color and FCP seems a bit and round-tripping with Crimson Workflow like the holy grail of the budget indie. I'm not sure why there isn't more info on Reduser about this.

Here's my questions--

Will it convert R3D files? Or do I use a proxy conversion...it seems like if the proxies are already lightly REDCODE compressed, then that defeats the purpose of the product.

But it doesn't seem to read the R3D in Quicktime...what am I doing wrong here? How do I initiate the uncompressed 10-bit file? When I do this using the proxy, I just get individual frames. How do I get these into a wrapper that I can edit in FCP? I've tried both Compressor and Quicktime for converting but don't know how to re-wrap all these files for FCP...I know I'm missing something basic....it looked so easy at the demo.
 
Meryem Ersoz said:
Hi Noah - I've been enjoying your blog, great stuff on there. Any chance that you will be posting about Gluetools or working in DPX files, for those of us who may not have worked with this format before? I feel like there is stuff that I should know, that I don't...just purchased a license at NAB and feeling my way through it. I finally had a chance to load it yesterday, and I know I'm doing something wrong. There's no RED-specific info in the guide.

And Gunleik, I'm glad that someone is initiating a discussion about this product. It has been flying under the radar for quite some time, with occasional allusions to it, but not much straight-up info.

10-bit 4:4:4 uncompressed files round-tripped between Color and FCP seems a bit and round-tripping with Crimson Workflow like the holy grail of the budget indie. I'm not sure why there isn't more info on Reduser about this.

Here's my questions--

Will it convert R3D files? Or do I use a proxy conversion...it seems like if the proxies are already lightly REDCODE compressed, then that defeats the purpose of the product.

But it doesn't seem to read the R3D in Quicktime...what am I doing wrong here? How do I initiate the uncompressed 10-bit file? When I do this using the proxy, I just get individual frames. How do I get these into a wrapper that I can edit in FCP? I've tried both Compressor and Quicktime for converting but don't know how to re-wrap all these files for FCP...I know I'm missing something basic....it looked so easy at the demo.
Click to expand...

Red shoots in RAW....
but you cant edit RAW files, so you use Proxies files....this is your offline edit.
then you use crimson, to translate your fcp xml to a redcine xml...this way you dont have to export all your footage to dpx files out of RECINE or REDLINE , just the ones you need.

ok...redcine outputs the dpx files....they are a lot of frames...no QT movies.
FCP cant read DPX sequences, so here you need/use Gluetools as a FCP Plug In....
now you have your timeline with dpx files, these timeline you can send to COLOR and start grading.

Gunleik, me too, are fans of dpx log files....so you need a 3d LUT in Color to view your stuff correctly on the monitor.
 
Glue is not directly compatible with R3D. The workflow is more- R3D to DPX and then DPX from then on via Glue Tools. It allows you go seamlessly go from source to editorial to color correction and VFX to final while staying in one format. Which as anyone who has worked with 4K knows is highly desirable. I don't have a blog about Glue Tools in DPX just yet. I'm working a RED gig with Glue this weekend, I'll post something up about that. In the mean time here's one on Glue Tools for Phantom.

-Noah
 
So, in order to properly use gluetools for your edit, you'd need to render out ALL your footage to DPX, correct? Isn't that kind of counter-productive, lengthy process for those who don't have endless supply of processing time and power? It seems that editing some sort of lower-res (or quicker to process) proxy file (not necessarily the camera generated ones) and then DPX-ing your edit makes a little more sense. In that case, you don't really need gluetools. It sounds like a great product, I'm just failing to see it's real benefit. If I need to render dpx's for a week before I can even start editing, then that's not really a solution in my opinion.
 
Strongbad_2Z said:
So, in order to properly use gluetools for your edit, you'd need to render out ALL your footage to DPX, correct? Isn't that kind of counter-productive, lengthy process for those who don't have endless supply of processing time and power? It seems that editing some sort of lower-res (or quicker to process) proxy file (not necessarily the camera generated ones) and then DPX-ing your edit makes a little more sense. In that case, you don't really need gluetools. It sounds like a great product, I'm just failing to see it's real benefit. If I need to render dpx's for a week before I can even start editing, then that's not really a solution in my opinion.
Click to expand...


to avoid rendering out all of your footage....you use crimsonworkflow
you use crimsonworkflow after you edited with proxies.

then ou have dpx files....
the befenit with gleutools is that you can import these exported files into fcp, without it, you have to export a EDL out of FCP and Import these EDL into COLOR and point to the DPX files....with gluetools its less complicated.
 
Hi.

Doing all the main cuts from proxies does indeed make sense (to me), what is lovely with the DPXs is how they hold up through CC and compositing work. It's a highly addictive pill.

In Norway there is an other side to this. Filmprints are done from DPX, so if you can deliver 10 bit log that are tuned for the printer without ever going into REC, that is good.

Correcting the DPXs into videospace is also a pleasure worth testing.

It takes up space and needs some bandwith, but on some productions you could actually SAVE a lot of time and money by going this route.

What surprised med (with gluetools) was how much better the "RAW" DPX's feel in color, than the AJA wrapped ones. I wasn't prepared for that... I was prepared for a more efficient workflow, but not a better and more flexible fileformat. Gee was I in for a cool surprise.

Sanjin disagrees with me here, but that's life...

Maybe RED/Apple will give us RAW in COLOR within the next few weeks, and then this will be an unneccesarry tool for many. As I need to deliver DPXs anyway, this is a good investment for me.

BTW Kaya, you still export EDLs from FCP to COLOR.
The main advantage versus FCP is that you can work directly in the timeline and (supposedly, haven't tried yet) even render out effects there, without compomising the files... That is if the effects themselves don't compromise your work :)

Again:
Your milage may wary, and it is not at all a neccesary workflow to have fun with the RED IMHO.
 
What Kaya said. If you do a lot of color correction and/or VFX- you need Glue Tools. If you're just cutting and printing with the proxies and happy with the look you're probably not going to benefit from it.

Noah
 
Hi Everyone,

I just read the entire thread, and felt I should jump in.

DPX was created by SMPTE to get around an annoying problem with Film and HD production. That problem was perfect portability of your footage. The DPX file format is a way to move imagery from platform to platform, device to device, and between all of the software packages out there, without loss of quality, or information (or that was theory.) Its not perfect, but it works awfully well, 99% of the time. This file format is the only way to completely move your footage around the production world accurately, and completely. Tiff files can't even do that. (Tiffs have no timecode, or film/video metadata capabilities.)

However, this amount of freedom often requires some understanding of when and why to use it.

As for AJA's software, I think that AJA staff would be the first to point out that the format has some limitations. While it is a "cheap" way to view DPX frames, it isn't very robust. It only accommodates a very narrow range of the DPX specification. You can't access the metadata in the DPX headers. I doesn't handle alpha channels. Nor can it load 8 or 10-bit YCbCr encoded frames. I can go on, with a list of things the AJA software doesn't support.
It works, and for some, AJA wrappers will be "good enough". But I suspect that most people that need portability, will need something more flexible, such as my tool.

As for my Cineon/DPX Pro for FCS2 package, I don't have a "Red Workflow". But we have a pretty damned nice DPX workflow. I hope that before long, Ian and I will have some time to do some much needed collaboration with Crimson. I suspect that when he is ready, we can add some nifty abilities to our package to benefit Red production. I have a couple ideas, such as embedding Red Slate/Shot information into the DPX files. Also Reel name and Time code info, that helps when moving projects using EDLs. (this is a common task with DI.) Conforming projects also will become easier if Crimson can push data into DPX frames, as well.

Right now, Red workflow(s) are in its infancy. Actually, Digital Cinema production is also in its infancy. I've spent years in VFX, where many of these issues have been solved. Its pretty fun to watch the Cinematographers twist and squirm, as they experience the growing pains of digital work. It reminds me of how hard VFX had it, 10-15 years ago, when we had to figure all of this stuff out. (Using computers that were horribly slow, too.)

I will be watching these forums with interest. If anyone has a suggestion that would improve Red and DPX production, feel free to post your idea. I'm always open to good ideas!

bob.
www.gluetools.com
 
You must log in or register to reply here.
Back
Top