iQ Pablo and RedCode

[DigitalPraxis]

As a reservation holder for a couple of cameras, and being a partner in a Camer Hire, Production & Post-Production facility that has a Quantel iQ Pablo as its main DI suite, I'm obviously keen to be able to ingest RedCode RAW into Pablo and have it de-compress and de-Bayer to 10 bit LOG DPX 4K files on the way in.

I know PJ's 'test film' was DI'd at Park Road Post in their Pablo, so hope this means my prefered workflow will be possible?

And yes, I have asked Quantel the same question...

My intention is to us FCP for offline, at the best resolution/compression for creative editorial interactivity, and with the realtime power of Pablo available for online DI perform all online 4K DPX uncompressed.

Thoughts?

[GlennChan]

I believe the workflow would be that the Redcine application can convert from the Redcode RAW files to a De-bayered uncompressed 4k DPX.

Offline editing can be done in FCP without transcoding via Redcine (just edit natively). Presumably, you export an EDL (or XML?) from FCP to Redcine, which generates a 'Red pull list' and knows what footage/clip needs de-Bayering (and hopefully it won't do the entire clip, but just the necessary segment with handles). This is my guess as the exact details of Redcine + Red Pull List haven't been released??

Info on the PJ short workflow in case you haven't seen it:
http://www.reduser.net/forum/showthr...ighlight=pablo

[DigitalPraxis]

Yep, I know all that (I actually helped Park Road Post set up their DI operation some time back - great team - hi Ian!).

My issue is I don't want to have to go through RedCine before going into the Pablo.

Should be dead easy as there is more grunt in the Pablo to do the de-compressing and de-Bayering than in RedCine.

That's if RED give Quantel the necessary info to implement... Hence my question.

I know they talked at NAB, so I'm hopeful!

[Nick Shaw]

Red clearly already have a relationship with Assimilate, and are releasing the necessary information to them to enable Scratch to read REDCODE RAW natively. I would imagine that in the fullness of time they may well release an SDK for REDCODE, to enable others to add REDCODE RAW to their applications. This kind of thing would help broader acceptance of REDCODE as a format.

That is of course unless they have some kind of exclusive deal with Assimilate. Time will tell.

[GlennChan]

As I understand it...

1- More complex + slower algorithms will give you better de-Bayer quality. For offline + making dailies etc., you probably will be doing quick and dirty de-Bayer. For online, you probably want to do a slow, high-quality de-Bayer.

Implementation-wise, you can either use the CPU, use GPU acceleration, or go with custom hardware (i.e. FPGAs). For first two you can do on typical desktops. If you want speed, presumably Redcine (in the future?) will have some sort of render farm functionality, so that you can use multiple desktops to speed things up.

2- From the little I know about iQ, it does have FPGAs on board. However, someone would have to invest the R&D into implementing the de-Bayer algorithm into hardware/FGPAs. This would be more expensive than coding Redcine into something that would run on a render farm. You might also be able to get speed increases from doing a speculative de-bayer... basically once you're done your first cut, you de-bayer everything in that cut (so you have less stuff to de-Bayer once you get picture lock).

3- A big advantage of implementing things into software is that it's easy to update... i.e. as de-Bayer algorithms get better, you stick new code in. Not so with FPGAs- they take longer to develop for

4- But basically, what you're asking for is a faster workflow to get material into iQ conform? Though even if Redcine was 'slow' (we still don't know its speed), it might not be bad compared to film scanning or tape/SDI conform.

5- The Scratch integration is mainly useful for making dailies??? The Redcode integration there means you don't have to transcode. It might be useful for conform, though you still have the speed problem; it would still take time to de-Bayer everything at high quality (and I don't think you want to tie up your iQ suite with that).

[DigitalPraxis]

The Pablo does ingest in the background, and could easily do the de-compressing and de-Bayering the same way - no system tie-up.

I'm sure Quantel will do any R&D necessary to impliment the software (the Pablo is a combination PC and dedicated hardware so the implimentation can be done a number of ways...)

I'm looking for easy workflow, and having to go through RedCine first isn't ideal.

If I can automatically ingest the selected circle takes in the background, via an edl or AAF, while I'm finishing a previous job in the foreground, that will be an ideal workflow.

[Ed van der Kruijssen]

I'm afraid that it will take quite some time before Quantel will anticipate on a RED workflow.
Working with Quantel equipment for almost 15 years (Editbox,IQ) I regret to say that Quantel isn't the most responsive company that I know.
In the meantime I will ask Quantel the same question you did maybe it helps...

Ed van der Kruijssen
BBP Digital Intermediate

[Lucas Wilson]

As I understand it...

5- The Scratch integration is mainly useful for making dailies??? The Redcode integration there means you don't have to transcode. It might be useful for conform, though you still have the speed problem; it would still take time to de-Bayer everything at high quality (and I don't think you want to tie up your iQ suite with that).

Hi Glenn...

The SCRATCH integration is useful for dailies in that SCRATCH can output in realtime to SDI directly from REDCODE files. So tape deliverables could be made pretty quickly.

Obviously for FCP, this isn't an issue, but for other editorial packages - it may sometimes be quicker to go to tape then to render out files.

It is also pretty useful in that SCRATCH is a full DI package. Temp and/or final color could be done directly from REDCODE files, then rendered out to 4K for a filmout or to tape, depending on the finals deliverables.

We will have a RED workflow page up fairly soon that shows several different potential workflows between the RED ONE, REDCINE, SCRATCH, and other packages.

Lucas
-----
ASSIMILATE, Inc.
LA, CA, USA.

[Lucas Wilson]

... I'm looking for easy workflow, and having to go through RedCine first isn't ideal.

If I can automatically ingest the selected circle takes in the background, via an edl or AAF, while I'm finishing a previous job in the foreground, that will be an ideal workflow.

Hi Steve,

Why not use REDCINE to render directly to the GenePool using the SAM data server? That would allow one or several low-cost machines to use REDCINE and render directly to Quantel-accessible storage without using up speed or productivity on your iQ for ingest.

With all the new Quantel kit, are DPX files supported natively yet? Or is an ingest to proprietary media still necessary?

If DPX is supported natively, then using multiple REDCINE stations (since you have multiple cameras) to render multiple streams seems like a fast and fairly inexpensive way to get performance.

If DPX is not supported natively, and you don't have GenePool/SAM, then you could still render to a specific folder and let QXML do all the background work for you.

Cheers,

Lucas
-----
ASSIMILATE, Inc.
LA, CA, USA.

[GlennChan]

Lucas, very neat.