Welcome to our community

Be a part of something great, join today!

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

Adobe - A new hope

When Joofa speaks, I STFU. :innocent:

Oh no Fredrik, please no.

Let me give a little more detail. There are two major parts to compression:

(1) Change of basis (axes)
(2) Quantization

When we say that one used say, DCT, then no compression has occurred at that stage as it is just the change of basis (typically matrix multiplication for image data). I.e., we have just changed axes in the multi-dimensional space. Think of it like in 3-D you rotate the co-ordinate axes. We do that so that we align the data along those axes which will help us in:

(1) We either throw away some of those axes that have little data content. Therefore it is very important to de-correlate the axes data, which DCT type transforms do.

Or.,

(2) Even for those axes we keep, we quantize them so that we coarsely define the axis co-ordinates.

Therefore, compression is actually happening in this second stage where we decide to throw away some axes and coarsely quantize some axes.

Hence, it is important to choose those axes which will help us keep a lot of image while throwing away some axes and its data, and for that it is not easy to beat PCA.
 
Let's be honest, none of us really quite understand what Joofa says -- he sounds authoritative and knowledgeable so we just accept that he's right...

I've decided he's an escaped mental patient... :)

Very funny Sycophant :)

However given a choice among:

(1) sounding authoritative than being one, and,
(2) being authoritative than sounding one,

I shall pick (2). :biggrin:
 
Very funny Sycophant :)

However given a choice among:

(1) sounding authoritative than being one, and,
(2) being authoritative than sounding one,

I shall pick (2). :biggrin:

OK, that one I did understand. : )
Joofa, are you by any chance teaching at the University of Texas at Austin? You seem to have a grasp on so many aspects of video theory - and you speak/type like someone who is used to having pretty smart people around you all the time. ; )

I hope you don't mind me asking.
 
Very funny Sycophant :)

However given a choice among:

(1) sounding authoritative than being one, and,
(2) being authoritative than sounding one,

I shall pick (2). :biggrin:

Why not. I know many who choose number 1.

For me I find that I only understand these topics if I don't think too hard about them. The more I think about them, the more confused I become.
 
Joofa, are you by any chance teaching at the University of Texas at Austin? You seem to have a grasp on so many aspects of video theory - and you speak/type like someone who is used to having pretty smart people around you all the time. ; )

I work in industry in Austin. However, I occasionally teach some lectures out of the full semester courses that other professors are teaching at The University of Texas at Austin.
 
Hi All,

Everybody seems to think that once the .r3d file format is "opened up" that they will be able to use the native RED footage just as they would use other media formats such as DPX, AVI & QT.

I don't believe this will EVER happen. R3D is not a CODEC. It can't be.

R3D is a type of data structure derived from photons hitting a CMOS sensor in the camera -and then being processed via a number of hardware circuitry stages before being saved to the CF card or hard drive(s).

You can DEcode R3D on a computer, but you can't ENcode it... There is no "CODEC" for R3D, and as such, your options for working with the native footage will be limited to playback, cuts-only editing and grading.

As cool as it might be to think about, my belief is that "normal" editing tasks such as cross-dissolves in your Premier (or FCP) timeline and/or multilayer compositing (AE, Nuke, Flame, etc) using native r3d files are never going to happen.

At least, not that I can foresee.
cineform is doing -exactly- that since years.


No other 2K/4K acquisition platforms allow you to simply yank the footage off the camera and inject it directly into the post production pipeline. That's a pipedream.
How could anybody expect .r3d to be any different?
you are wrong.
look at si, check ps, look at iridas.
its reality since 2007.
 
cineform is doing -exactly- that since years.



you are wrong.
look at si, check ps, look at iridas.
its reality since 2007.

Hmmm.

If you use Cineform Raw (the format you're basically talking about with SI/Premiere Pro) it is true that editorial can proceed directly from the raw files without serious overhead. However, you must ultimately do a full render/debayer for final deliverables, just like you must do with Red. The difference is that editorial is much smoother with Cineform's raw files than with Red's, for various reasons that go beyond the obvious 4K/2K difference - although it should be noted that there isn't currently any editorial workflow for Red using the raw files "directly" (and by this I mean using the QT wrappers) beyond 2K anyway.

The render and debayer for Cineform's 2K files is currently considerably faster as well.
 
Hmmm.

If you use Cineform Raw (the format you're basically talking about with SI/Premiere Pro) it is true that editorial can proceed directly from the raw files without serious overhead. However, you must ultimately do a full render/debayer for final deliverables, just like you must do with Red. The difference is that editorial is much smoother with Cineform's raw files than with Red's, for various reasons that go beyond the obvious 4K/2K difference - although it should be noted that there isn't currently any editorial workflow for Red using the raw files "directly" (and by this I mean using the QT wrappers) beyond 2K anyway.

The render and debayer for Cineform's 2K files is currently considerably faster as well.

ok mmost - yours is a more concise read on the situation than mine.
 
Extending Mike's concise post just a bit, and offering "due" to others who chimed in, both R3D and CineForm RAW are Wavelet based, and both are acquisition-only formats. However, the Wavelet implementations are different. As others have commented, CineForm's Wavelets are pretty fast - because we made design decisions for performance, including lots of Intel architecture optimizations. We also did not compromise visual fidelity, and CineForm compression exceeds that of the respected HDCam SR format: http://www.cineform.com/technology/12Bit-RGB-QualityAnalysis/12Bit-RGB-QualityAnalysis.htm.

But at some point, as was pointed out, you must render, and a render means a demosaic, and a demosaic means you can never go back to RAW. So you must render to another format. Typically in a CineForm RAW workflow you'll render to CineForm 444 which is our 12-bit RGB format. So within PPro (and within FCP for that matter), you can have both CineForm RAW (unrendered) and CineForm 444 (rendered from CRAW) coexist on the same timeline. Also, we can do this at 4K on the PPro timeline (2K in FCP) while moving material back and forth between AE. Because CineForm compression was designed for post and then later moved into acquisition (D2D recorders, SI camera) the camera-to-post workflow is pretty efficient.
 
Ok , these last posts seem to scary me a little now. So this means it won't be to easy or maby not possible to edit the native footage like we're used to with dvcprohd?

Right, but you can't edit 35mm film negs like DVCproHD either...

It all requires some "processing" at one point or another.

;)
 
Also, we can do this at 4K on the PPro timeline (2K in FCP) while moving material back and forth between AE

Ok.. so does Cineform optimization work just as well in Premiere on the Mac? Or am I better off under XP. And is there any reason running XP on a MAC Pro would be problematic for a Cineform workflow?

I like the idea of being cross platform compatible.
 
Ok.. so does Cineform optimization work just as well in Premiere on the Mac? Or am I better off under XP. And is there any reason running XP on a MAC Pro would be problematic for a Cineform workflow?

I like the idea of being cross platform compatible.

Great question. First of all, CineForm files created on either Mac or Windows are completely cross-platform and cross-applications compatible. CineForm AVI files created on Windows play on Mac (in FCP). CineForm MOV files created out of FCP or AE can be played on Windows. There are a few rules to obey to ensure you always get full extended (10 / 12-bit) precision, but for these high-level purposes this isn't an issue.

Second, the RT engine we developed replaces the video engine in PPro (Windows). That's because Adobe publishes an SDK that allows us to do that. Unfortunately no such capability exists in FCP so we're stuck with the FCP engine that throttles (our) performance. To the specific Q you asked, we have not yet ported the CineForm RT engine to PPro (Mac) but it can (and will) be done. So our best RT workflow today is on Windows.

As you may be aware we also have an active metadata workflow for CineForm RAW that allows applying white balance, color matrix, and 3D LUTs dynamically without flattening the color information into the file itself. Currently on Windows you can change the active metadata (for instance choose different 3D LUTs) dynamically. By NAB we *should* be showing the ability to modify active metadata on Mac. Please stop by to see us if you'll be there.
 
Right, but you can't edit 35mm film negs like DVCproHD either...

It all requires some "processing" at one point or another.

That's the thing - the workflow for RED should be compared to 35mm more than to tape I think. Or at least that type of workflow should be kept in mind.
 
Great question. First of all, CineForm files created on either Mac or Windows are completely cross-platform and cross-applications compatible. CineForm AVI files created on Windows play on Mac (in FCP). CineForm MOV files created out of FCP or AE can be played on Windows. There are a few rules to obey to ensure you always get full extended (10 / 12-bit) precision, but for these high-level purposes this isn't an issue.

Second, the RT engine we developed replaces the video engine in PPro (Windows). That's because Adobe publishes an SDK that allows us to do that. Unfortunately no such capability exists in FCP so we're stuck with the FCP engine that throttles (our) performance. To the specific Q you asked, we have not yet ported the CineForm RT engine to PPro (Mac) but it can (and will) be done. So our best RT workflow today is on Windows.

As you may be aware we also have an active metadata workflow for CineForm RAW that allows applying white balance, color matrix, and 3D LUTs dynamically without flattening the color information into the file itself. Currently on Windows you can change the active metadata (for instance choose different 3D LUTs) dynamically. By NAB we *should* be showing the ability to modify active metadata on Mac. Please stop by to see us if you'll be there.

David, is metadata only available from footage captured from the SI2K? At least for now?
 
When we release support on MacOS for modifying active metadata you'll be able to attach active metdata to CineForm RAW files regardless of where the clips originated and regardless of whether the original CRAW file has active metdata present.
 
When will HDLink for Mac be available?

When will HDLink for Mac be available?

David,

Can we expect to have the HDLink for Mac for NAB? As you know, I have the Prospect 4K, and I do have CS3 for Mac, so it will be great to finally have the application for Mac. We have been waiting for your Mac support... I use PPro and company in XP via Bootcamp and it is so fast, so I will love to have such experience in OX.

Regards,
 
dave,

Thanks for the info. It sounds really promissing.
 
Back
Top