So I bought Gluetools....

[Gunleik Groven]

Tired of manually wrapping the dpxs with the Kona wrapper.

Now I hope I can roudtrip properly.

Any advice while I wait for my licence?

Gunleik

[Noah Kadner]

Haw- I guess start practicing in Color. DPX is lovely in Color.

Noah

[Gunleik Groven]

YUP. I know... That's why, really

Is there anything to remember. I'll roundtrip with Crimson...
Naming conventions out of RC/RL?


Gunleik

[Nick Wolf]

Whats a licence cost?

[Zach Hilton]

Tired of manually wrapping the dpxs with the Kona wrapper.

Now I hope I can roudtrip properly.

Any advice while I wait for my licence?

GunleikSo explain to me why you'd want gluetools? What is the suggested workflow? What benefits do you get using gluetools that I don't already have by editing proxies, roundtripping to redcine and exporting DPX's to color in Color, then export finals back to FCP?

[Jeff Kilgroe]

Much higher image quality for one because you're not using the real-time generated proxies.

GlueTools with Crimson looks like a nice solution until Apple can get full R3D support across all apps in FCS2. I'm about to pull the trigger on GlueTools myself. I saw a glimpse of it at NAB, I'm going to play with the demo this weekend.

[Noah Kadner]

Well you skip a lot of proxy steps and image degradation- you can go DPX right off your R3Ds and stay DPX for editorial and color correction. The license is $399 I believe. It also has a demo mode so you can test out the workflow- just gives you a watermarked render.

Not that I work for the company- we use it and I happen to think it's an awesome product that's perfect for RED. Met the developer at NAB and he's a really, really bright guy who takes user input as well. Also a one-man band which I'm always down for supporting the little guy.

Noah

[Nick Wolf]

Good to know, sounds like a decent deal, thanks.

[Sanjin Jukic]

GlueTools is a nice solution.

Also I tried out demo.

But there is still FREE solution to deal with DPX files and there are AJA FREE apps

AJA DPXToQT Translator and AJA QTToDPX Translator.

Here is a very good explanation for that partly quoted from another place:

"Regarding Tim Sassoon's comment:
"Well, computer OS's can really chuff when sorting thousands of frames.
I'd like to see QT be able to do package files, where frame-based
media is available, but ordinarily hidden."

This is actually how the AJA DPXToQT Translator application works.
When you are working with sequential DPX files (or Cineon) within a
QuickTime based application, you are seeing only the QT reference movie, not
the individual files - but those DPX files are actually what you are
playing back, not a proxy.

There are some real advantages to this type of workflow:
a) you can accommodate applications that only read QuickTime files and
not frame based media such as DPX or Cineon. (Final Cut Pro without
something like the GlueTools QuickTime components is a good example).
b) you can make a frame-based change(s) without re-rendering. Say one
DPX file has dust removal performed on it in an application - the
reference movie will be intact and the change present the next time you open
it - no need to re-render it - IF the file you created to replace the
old one has the exact same name and resides in the exact same
location/directory/path, etc.

As for computer operating system and drive bandwidth issues: most of
these issues stem from the performance necessary to handle 12+ MB per
frame at 24 frames per second. Typically, drives controller cache is the
weak link as it must cache the frames - having said that, AJA regularly
demonstrates playback of 2K DPX files, wrapped as QuickTime Reference
movies using 4Gb fibre channel disk arrays with 16 drive modules and
dual controllers each with 512MB cache (more being better in this case -
2GB if possible) Such a drive array, like those offered by InforTrend,
are very capable of playing back such media. You need to achieve over
300+MB/sec, but the cache is the other significant point for the array
as noted.

Finally, keep in mind that I am still referring to DPX media without
any compression, so ideally you don't want to wrap things longer than a
typical shot in an edit - wrapping a whole reel is unwieldy for a
variety of reasons.

My hope, probably like many of you, is that the header data for files
like DPX, Cineon or DNG come in some form that contains at least some
data in "expected" locations - in particular, timecode data. This allows
for off-line and on-line scenarios. Cintel scanners, as an example,
can put timecode data into DPX headers in a location that can be read by
the QuickTime Reference movie. This provides a lot of flexibility for
post-production workflows.

In addition to the AJA DPXToQT Translator, AJA also provides the
inverse, AJA QTToDPX Translator to create sequential DPX files from Log RGB
or linear RGB QuickTime files. Additionally, there is the AJA VTR
Xchange application which can capture to sequential DPX files and
simultaneously generate a QuickTime Reference movie. All of the applications
mentioned are freeware for use with the AJA Kona3 card.

Whitepapers on workflow(s) related to these applications, DPX files and
QuickTime Reference movies can be found at the AJA website under the
sub-heading "Documents" at the following URL:
http://www.aja.com/html/support_kona3_doc.html

Not sure if this helps in this discussion, but thought this information
worth mentioning here.

Regards,
Jon
Jon Thorn
Product Manager
AJA Video Systems, Inc."

So think about it once more before you make GT purchase decision.

[Gunleik Groven]

YUP Sanjin, I know. But there were a couple of things changing my mind (after a couple of weeks using this exact solution.

1. Rendering in FCP. as far as I understand GT does the same RGB/YUV trick Graeme is talking about with the ProRes proxies, thus (I hope) a render with titles and all won't immediately "ruin" your file.

I'm sitting here finishing off projects with up to 100 cuts....
The manual wrap/import (with a lot of crashes with the AJA app) sorta gets irrational after a while. It's good for seeing the power of DPX workflow. It is not a DPX workflow...

I could sidestep FCP alltogether after initial cuts (using EDLs from FCP to import the DPXs into Color), but that is also not very satisfactory.

I have now used the last couple of days on the ProRes workflow, as I suspect that that's what quite a few of my clients will pay for. While it works very well and definitely is a quantum leap up from DVCPRO HD, it is very hard to go there after seing how the dpx solution performs. They're not even on the same planet IMHO.

I will be setting up a chain for delivery for film out the next weeks and QC it with the film-out place/lab/whatever you choose to call it.

They use COLOR for CC and cinevate for realtime printing of the filmstock. To make this remotely close to effective, there was in the end no choice but Gluetools...

Thanks to AJA for letting me know!

Gunleik

[Sanjin Jukic]

YUP Sanjin, I know. But there were a couple of things changing my mind (after a couple of weeks using this exact solution.

1. Rendering in FCP. as far as I understand GT does the same RGB/YUV trick Graeme is talking about with the ProRes proxies, thus (I hope) a render with titles and all won't immediately "ruin" your file.

I'm sitting here finishing off projects with up to 100 cuts....
The manual wrap/import (with a lot of crashes with the AJA app) sorta gets irrational after a while. It's good for seeing the power of DPX workflow. It is not a DPX workflow...

I could sidestep FCP alltogether after initial cuts (using EDLs from FCP to import the DPXs into Color), but that is also not very satisfactory.

I have now used the last couple of days on the ProRes workflow, as I suspect that that's what quite a few of my clients will pay for. While it works very well and definitely is a quantum leap up from DVCPRO HD, it is very hard to go there after seing how the dpx solution performs. They're not even on the same planet IMHO.

I will be setting up a chain for delivery for film out the next weeks and QC it with the film-out place/lab/whatever you choose to call it.

They use COLOR for CC and cinevate for realtime printing of the filmstock. To make this remotely close to effective, there was in the end no choice but Gluetools...

Thanks to AJA for letting me know!

Gunleik

Gunleik,

all respect for your workflow research but I still cannot get deeply your frustration with AJA tools.

For example I do the thing very simple like this:

1. Open _H.mov file in QT and then export in 2K using AJA Kona 10 bit RGB compression.

2. If I need a pure DPX sequence then open AJA KONA QTToDPXTranslator.app and the translate AJA Kona 10 bit RGB file to DPX sequence.

3. Import in FCP Aja Kona 10 bit RGB and cut in 2K using Medea SCSI RAID that gives me 300+MB/sec speed.

4. Sent to Color and do CC/grade.

5. Sent to FCP.

6. Export XML and AJA Kona 10 bit RGB files.

7. USe Crimson to deal with FCP XML for more confirm like an option...

8. Go back to step 4 and then always have DPX sequence for output (FREE thans to AJA).

Of course that there are more other workarounds and options to do the thing but this could be a very easy.

[Gunleik Groven]

Thanks Sanjin.

I'm not frustrated with AJAs tools, actually I am quite gratefull, but your example (to me) proves my point. And it starts with a compressed AJA QT...
For this workflow, I need to get RID of compression alltogether. (Not all workflows, but this particular workflow...)

For simple workflow tests, the AJA wrapper let me test the options.
When now dealing with larger projects, it became far too timeconsuming.

I don't really follow your receipe, though, as that would create far too big files (and too many copies of them)

I cut from proxies, go to crimson and create DPXs either directly via Crimsons send to REDLINE functionality or (still) more often go through the headaches of RC (which is becoming not a very good promotional tool for Scratch...)

That way I don't online all the material uncompressed...
I will still get two heaps of dpxs, though, one before Color and one after.

The thing with the AJA RGB codec is that (AFAIK) it's rendered @ 8 bit in FCP if you add any effects or titles. For this particular workflow, I want to stay in 10 bit untill finish. As far as I have understood, gluetools interprets the DPX's as YUV to FCP (still haven't tested, though...) and can be rendered @ 32bit float internally and output to new 10 bit lin or log DPXs.

But these are my choices, not yours :)

Cheers!

Gunleik

[mikeburton]

[QUOTE=gunleik;206907]Thanks Sanjin.


The thing with the AJA RGB codec is that (AFAIK) it's rendered @ 8 bit in FCP if you add any effects or titles. For this particular workflow, I want to stay in 10 bit untill finish. As far as I have understood, gluetools interprets the DPX's as YUV to FCP (still haven't tested, though...) and can be rendered @ 32bit float internally and output to new 10 bit lin or log DPXs.


gunleik,

Make sure (if you haven't already researched) that you have disk speed upwards of 300MB's Constant READ speed and a fast MacPro capable of playing back 1080p or 2K without dropping frames in FCP. DPX files are quite heavy on computer resources. Also, the way i recall, Gluetools DPX in FCP gets converted from RGB to YUV 10bit to satisfy FCP basically. Then on export will go back to RGB from the source files.

[Gunleik Groven]

Yup, this is exactly why I put my money down...

As to disk speeds etc... I know.
And I have been researching the DPX with RED workflow since the cam came in. Still a lot to learn, but gluetools eventually stood out as an extremely logical choice - for me, that is.

[mikeburton]

Yup, this is exactly why I put my money down...

As to disk speeds etc... I know.
And I have been researching the DPX with RED workflow since the cam came in. Still a lot to learn, but gluetools eventually stood out as an extremely logical choice - for me, that is.

GlueTools is awesome! You won't regret that choice so long you have the hardware to support it. I too have been researching and doing a lot of post RED projects since there was a workflow. Every project so far has required slightly different needs and hence a slightly different approach. That said, DPX is usually what I recommend if the client doesn't want to go to a Scratch suite and it works flawlessly. Good purchase.

[Sanjin Jukic]

But these are my choces, not yours :)

Cheers!

Gunleik

Also I'm just evaluating SCRATCH again and the I'll tell you a difference between those two workflow results in a picture quality :).

[Gunleik Groven]

Scratch is the 4th workflow I'll be looking into...

But a good, illustrated non-emotional comparative writeup would be a nice read.
AFAIK, when treated right (thus gluetools...) the DPX workflow should bring you a long way, even though the disk requirements explode...

Please write a report!

I'd love to see RAW 16 bit stills, compared with stills output through the DPX route, the Scratch route and the prores route, with 2 sec clips @ 1080 processed for the same look with the different toolset and workflows.

Are you up to it?

Gunleik

[conrad gaunt]

I still expect to be making good use of photoshops `automate` function for processing of DPX files to start with. There`s too much emphasis on real-time in many applications for my taste, but I understand many with a R1 won`t have the luxury of excessive amounts of time. I expect to split jobs and process on 2 or 3 low power laptops, if I need faster processing.

[Sanjin Jukic]

Scratch is th 4th workflow I'll be looking into...

But a good, illustrated non-emotional comparative writeup would be a nice read.
AFAIK, when treated right (thus gluetools...) the DPX workflow should bring you a long way, even though the disk requirements explode...

Please write a report!

I'd love to see RAW 16 bit stills, compared with stills output through the DPX route, the Scratch route and the prores route, with 2 sec clips @ 1080 processed for the same look with the different toolset and workflows.

Are you up to it?

Gunleik

I'll start tonight but probably to finish over the weekend.

Just have got a meal and opened a bottle of Rosso di Montalcino "Mastrojanni" 2005.

Need a break because of back pain from the handheld shooting with my RED around

the Josef Strauss golden monument in the Viennese Stadtpark today late afternoon :) .

http://homepage.mac.com/sanjinjukic/RED/strauss_handheld.jpg

[Andrew M.]

Nice, have bin there, good times.....
.
.
.
what lenses:-)

[Noah Kadner]

Sweet- you can actually see that live!

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

Noah

[Sanjin Jukic]

Sweet- you can actually see that live!

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

Noah

http://homepage.mac.com/sanjinjukic/RED/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 :) .

[Marcus Struzina]

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

[Noah Kadner]

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

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

Noah

[Nick Shaw]

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

Noah

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.

[Matt Gottshalk]

The Aja boys were talking to the Gluetools dude when I was at his booth.

Stay tuned....

[Noah Kadner]

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.

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

Noah

[Gunleik Groven]

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

[Robert Monaghan]

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

Noah

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.

[Miguel "Macgregor" De Olaso]

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?

[Nick Shaw]

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?

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.

[Noah Kadner]

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.

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

Noah

[Meryem Ersoz]

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.

[Cüneyt Kaya]

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.

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.

[Noah Kadner]

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. (http://www.callboxlive.com/resources/?p=76)

-Noah

[Zach Hilton]

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.

[Cüneyt Kaya]

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.


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.

[Gunleik Groven]

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.

[Noah Kadner]

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

[Robert Monaghan]

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

[Greg M]

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.


www.gluetools.com

Great news...I'll start harassing Ian immediatly. He is ready now, he just forgot to tell you.

[Curran Giddens]

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.

www.gluetools.com

Yes please. If you guys do some collaboration like this then I will buy both you softwares for my FCP editor.