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

4k Tiff Sequence

Sanjin, I am speaking about exporting from redcine. And QT will give you never the full color depth (12 bit or more). we discussed this a long time. Next thing is I wan't linear color space. And if you wan't to merge between FCP and Avid also you need dpx or tiff.
 
rainer said:
Sanjin, I am speaking about exporting from redcine. And QT will give you never the full color depth (12 bit or more). we discussed this a long time. Next thing is I wan't linear color space. And if you wan't to merge between FCP and Avid also you need dpx or tiff.
Click to expand...

Rainer,

let's make it clear.

Here we go:

All is good with your tiff exported from Redcine (A004_C006_080212_000000.tif that you offered from ftp)

Shake shows it's RGBA 16bit 4096x2048

ChristinaShake2.jpg


Original Shake's snapshot to see all GUI from my 30" desktop is here

Also everything is fine in AE CS3 where you should click in RGB Straight to see the file in colo(u)rs.

ChristinaAE2.jpg


Also original AE's snapshot to see all GUI from my 30" desktop is here

I'm not any POST or VFX specialist but always trying to find way as an average/ordinary user.

Hope this helps.
 
Allright, thx for info Sanjin. By end of the week I will reconform the hole video to 4k Tiff sequence 16 bit. We will see if this rocks in AE. I will also try Automatic Duck. If all is ok, then the 2k or 4k 4:4:4 workflow with Ian's skript will be alive.
 
Also try to avoid QT as a final output or master.

QT is OK as a proxy file only.

Classic POST files like a DPX or a TIFF are way to go with final output or master.
 
For broadcast @ 2k I am using QT 10bit uncompr. 4:2:2 which has a bandwidth of 137 MB/s, I think thats ok for TV and Blue Ray :) . Filmout will be Tiff. Need to buy a LTO drive anyway....
 
The Third Man said:
Also everything is fine in AE CS3 where you should click in RGB Straight to see the file in colo(u)rs.
Click to expand...

Sanjin,

You shouldn't do it this way. In the project window, you should right-click on the footage, select interpret footage/ignore alpha. If you look at the information in the alpha, you'll see that there is information there that shouldn't be.

What I've said all along is that the file shouldn't have an alpha. There isn't any transparency information in your camera capture - is there? There should be no compositing functions done to it to view it properly (ie; select RGB Straight in the viewer)

If you don't believe me, this is what the AE Help file says about that view mode:

Note: When you choose RGB Straight, which shows straight RGB values before they are matted (premultiplied) with the alpha channel, pixels with complete transparency are undefined and therefore may contain unexpected colors.

Does that sound like something you should be doing to footage to that shouldn't have an alpha in the first place?

Dennis Wilkins
 
rainer said:
For broadcast @ 2k I am using QT 10bit uncompr. 4:2:2 which has a bandwidth of 137 MB/s, I think thats ok for TV and Blue Ray :) . Filmout will be Tiff. Need to buy a LTO drive anyway....
Click to expand...

Rainer,

Just be sure to test this workflow with your editor (and edit platform). I've seen gamma shifts using the QuickTime Uncompressed 4:2:2 codecs - in this case rendering out of AE (mac) and going into Avid (PC).

Don't really have a definitive solution to this; we now use 16bit tiff files because they seem to work in almost any situation - unless there is a rogue alpha in the file :)

Dennis Wilkins
 
dennisw said:
Sanjin,

You shouldn't do it this way. In the project window, you should right-click on the footage, select interpret footage/ignore alpha. If you look at the information in the alpha, you'll see that there is information there that shouldn't be.

What I've said all along is that the file shouldn't have an alpha. There isn't any transparency information in your camera capture - is there? There should be no compositing functions done to it to view it properly (ie; select RGB Straight in the viewer)

If you don't believe me, this is what the AE Help file says about that view mode:

Note: When you choose RGB Straight, which shows straight RGB values before they are matted (premultiplied) with the alpha channel, pixels with complete transparency are undefined and therefore may contain unexpected colors.

Does that sound like something you should be doing to footage to that shouldn't have an alpha in the first place?

Dennis Wilkins
Click to expand...

Deniss,

maybe agree with you but let's wait until other "post workflow specialists" can say about that.

rainer said:
For broadcast @ 2k I am using QT 10bit uncompr. 4:2:2 which has a bandwidth of 137 MB/s, I think thats ok for TV and Blue Ray :) . Filmout will be Tiff. Need to buy a LTO drive anyway....
Click to expand...

LTO sounds good.
 
dennisw said:
Sanjin,

What I've said all along is that the file shouldn't have an alpha. There isn't any transparency information in your camera capture - is there? There should be no compositing functions done to it to view it properly (ie; select RGB Straight in the viewer)


Dennis Wilkins
Click to expand...

Treatment of Alpha between AE and Shake are different. Shake always likes to have an alpha channel. Hence, for an RGB file it makes sense for it to have a "dummy" alpha channel as far as Shake is concerned, because, otherwise, you have to "inject" that for an RGB file in Shake after loading a file that does not have one. AE is fine for composting purposes if the Alpha channel is not there.
 
Joofa said:
Treatment of Alpha between AE and Shake are different. Shake always likes to have an alpha channel. Hence, for an RGB file it makes sense for it to have a "dummy" alpha channel as far as Shake is concerned, because, otherwise, you have to "inject" that for an RGB file in Shake after loading a file that does not have one. AE is fine for composting purposes if the Alpha channel is not there.
Click to expand...

Joofa,

Why do think this should this be the case? dpx and cineon files (The preferred formats for film scan/plate delivery for years now), don't even support alphas.

The problem with the alpha in the current tiff exports out of RedCine is that it's real dumb - as in wrong. :umm:
 
dennisw said:
Joofa,

Why do think this should this be the case? dpx and cineon files (The preferred formats for film scan/plate delivery for years now), don't even support alphas.

The problem with the alpha in the current tiff exports out of RedCine is that it's real dumb - as in wrong. :umm:
Click to expand...

I agree with you that having an alpha when it is not needed is just increasing file size. However, when you import such files in Shake, then the alpha channel is A = 0. Hence, you have to go to the FileIn node and "inject" alpha via the clicking on the "Auto Alpha" box so that Shake's compositing can work fine. What happens is that for complex projects with hundreds/thousands of nodes, many times compositors forget to do that for each such file and may have unpredictable results.

AE is fine, as it internally does create an opaque Alpha channel for an RGB file with no Alpha.
 
Joofa said:
Treatment of Alpha between AE and Shake are different. Shake always likes to have an alpha channel. Hence, for an RGB file it makes sense for it to have a "dummy" alpha channel as far as Shake is concerned, because, otherwise, you have to "inject" that for an RGB file in Shake after loading a file that does not have one. AE is fine for composting purposes if the Alpha channel is not there.
Click to expand...

I preffer Shake look with Alpha or RGBA.

Shake has more "filmic" look then AE that has more "clinic" look.

Also colo(u)r correction filters and plug-ins in Shake give you pretty good result.

Output 4K DPX with a help of Glue Tools.

Have look at

LINK>>>
 
dennisw said:
Joofa,

Why do think this should this be the case? dpx and cineon files (The preferred formats for film scan/plate delivery for years now), don't even support alphas.

The problem with the alpha in the current tiff exports out of RedCine is that it's real dumb - as in wrong. :umm:
Click to expand...

Small correction - You are correct that CIN does not support Alpha. But DPX does. It is not widely supported in applications, but the file format does include an alpha channel. A few scanners with infrared will put dirt information into DPX alpha.

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

can you download the Tiff from Rainer's previous post and check something for me? (I'm chained to a machine that doesn't have Shake installed on it)

Load it with the alpha in that's embeded in the file, and then duplicate the node and replace the alpha with a fully opaque one (the one in the file is not).

Then do a difference on them - they should not be the same.

If the alpha in the tiff was just a "dummy" or fully opaque alpha, it wouldn't be as big a deal, although the thought of purchasing storage for millions of 4k frames that happen to have unnecessary alphas kind of makes me think...
 
dennisw said:
Joofa,

can you download the Tiff from Rainer's previous post and check something for me? (I'm chained to a machine that doesn't have Shake installed on it)

Load it with the alpha in that's embeded in the file, and then duplicate the node and replace the alpha with a fully opaque one (the one in the file is not).

Then do a difference on them - they should not be the same.

If the alpha in the tiff was just a "dummy" or fully opaque alpha, it wouldn't be as big a deal, although the thought of purchasing storage for millions of 4k frames that happen to have unnecessary alphas kind of makes me think...
Click to expand...

Sure, going to do that.
 
dennisw said:
Rainer,

Just be sure to test this workflow with your editor (and edit platform). I've seen gamma shifts using the QuickTime Uncompressed 4:2:2 codecs - in this case rendering out of AE (mac) and going into Avid (PC).

Don't really have a definitive solution to this; we now use 16bit tiff files because they seem to work in almost any situation - unless there is a rogue alpha in the file :)

Dennis Wilkins
Click to expand...

Going to avid will be over Tiff Sequence. But I think for HDTV release we can stay on Apple Plattform.
 
luki said:
Small correction - You are correct that CIN does not support Alpha. But DPX does. It is not widely supported in applications, but the file format does include an alpha channel. A few scanners with infrared will put dirt information into DPX alpha.

Lucas
-----
ASSIMILATE, Inc.
LA, CA, USA
Click to expand...

Luki,

Thanks for the correction - that's good to know. I've never seen an alpha used in a film scan. I'm guessing this isn't widely used? Maybe more for restoration purposes over current movie production pipelines?

The point I was trying to make is that there shouldn't be an alpha in a film scan/plate arbitrarily, especially if there is going to be errant data in it.

Dennis Wilkins
 
You must log in or register to reply here.
Back
Top