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....

Gunleik Groven

Gunleik Groven

REDuser Sponsor
Joined
Dec 28, 2006
Messages
13,465
Reaction score
5
Points
38
Location
Norway
Website
quine.no
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
 
YUP. I know... That's why, really

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


Gunleik
 
gunleik said:
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
Click to expand...
So 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?
 
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.
 
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
 
Good to know, sounds like a decent deal, thanks.
 
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.
 
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 said:
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
Click to expand...

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.
 
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
 
gunleik said:
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.
Click to expand...
 
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.
 
gunleik said:
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.
Click to expand...

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.
 
gunleik said:
But these are my choces, not yours :)

Cheers!

Gunleik
Click to expand...

Also I'm just evaluating SCRATCH again and the I'll tell you a difference between those two workflow results in a picture quality :).
 
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
 
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.
 
gunleik said:
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
Click to expand...

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

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