As your source QT files are only 8bpc why go through all the hassle and uncertainty of Vegas's 32bit float pipeline?

DPX is a bit of a dark horse. From Wikipedia's entry:

SMPTE Specifications dictate a mild number of compulsory metadata, like image resolution,

I've tried several times to drop a DPX sequence into Vegas and see it display something remotely sensible. I'm kind of left thinking it ignores the metadata and I have no idea if or how Vegas writes the metadata when it exports DPX.

Bob.

Bob - If ProRes is 8 bit, then that is the solution. But the file reports as 1920x1080x24, Apple ProRes 4444.

Light bulb moment - does Vegas 8 bit mean 8 bits PER CHANNEL (3 channels), equaling 24 bit in total?

musicvid - I know what you mean re: Studio to Computer RGB, etc. But in theory, applying a Studio to Computer RGB filter should come close to fixing the issue right? It barely even scratches the surface of the adjustment needed. Maybe I'm being daft and missing a point, but I believed I previously understood Studio/Computer RGB (I even bought the VASST color correction DVD).

Keep in mind, these are sequential image files, not videos - I've never had this issue with any video file format on this project, and I preview on both a Computer RGB monitor and a Blackmagic Intensity Pro (HDMI signal). Check these out (taking DPX out of the equation and using JPG):

Output from Project changed down to 8 bit (and this is how it should look):
http://dl.dropbox.com/u/70705198/8-bit-video-levels-no-filter.jpeg

Ouput in 32 bit video levels, no filter (project native, but not how it should look):
http://dl.dropbox.com/u/70705198/32-bit-video-levels-no-filter.jpeg

Output in 32 bit video levels, studio to computer RGB:
http://dl.dropbox.com/u/70705198/32-bit-video-levels-studio-to-computer.jpeg

Output in 32 bit video levels, computer to studio RGB:
http://dl.dropbox.com/u/70705198/32-bit-video-levels-computer-to-studio.jpeg

I certainly don't want to be getting up anyone's nose by rehashing well worn topics, but for me this is new - this problem does not exist on any of the outputted videos (uncompressed AVI, MP4s, MP2's, etc) and seems different to the usual RGB space issue - it's much more severe than I've seen before.

Thanks in advance
Ent.

If you're going the OpenDCP route, you will want studio RGB levels in the image sequence stage for the conversion to x'y'z' color space. I'm getting into the same deep waters here in attempting a DCP build, and I may forego Vegas for a solution where I'm more comfortable with how levels are handled. Depending on what you need to do in frame rate conversion, you may consider going directly to a jpeg2000 image sequence and bypassing the tiff stage.

This link was valuable for me, but you may be already past my current level of knowledge -
https://github.com/wolfgangw/digital_cinema_tools/wiki/Open-source-tools-for-a-digital-cinema-pipeline

Good luck.

I know nothing about DCP images.

Does it expect 0-255 or 16-235, or something else?

I know TIFF expects 0-255.

"Light bulb moment - does Vegas 8 bit mean 8 bits PER CHANNEL (3 channels), equaling 24 bit in total?"

Yes.
and "32 bit" usually means 8bits per channel including an alpha channel i.e. 4 x 8bits.

Bob.

What the DCP package expects depends on what you select. It can take 16 bit sRGB as well as 8 bit cRBG, and a whole host of others, or at least on the one I am trialing (DCP Builder).

I'm going to use a chain of logic here, and skip the DCP questions:

If the source material is 8 bit, and my DCP package can take 8 bit, and Vegas is only getting the colour space right on 8 bit, then I'm going to short circuit the whole thing and turn the project 8 bit. Done! :-)

Thanks Bob - all this time I was thinking 8 bit was like the old fashioned colour space on computers and not actually 24 bit!!

It doesn't explain why the colour space is so wildly out of step in 32 bit on this project, and then only on sequenced still image output, but that can be a mystery we solve another time.

Happy to run suggested experiments when the rig isn't tied up on 8 hour renders - I firmly believe in putting back into this wonderful resource where I can. But in the mean time, I'll be in 8 bit [s per channel] land.

Thanks!
Ent.

"It doesn't explain why the colour space is so wildly out of step in 32 bit on this project,"

Hehehe.
One or more here have suggested quite emphatically that this is the only "correct" behavior in Vegas.

Best.

"Does it expect 0-255 or 16-235, or something else?"

It uses 12 bits per channel and the CIE XYZ color space.
For 2K it uses 10bpc. In both cases the active bits are packed into 16 bits.
From my understanding on how the digital values end up as light on the screen is determined by metadata carried with the image. The intent seems to be to have a system that could handle much wider gamuts than are in use today i.e. make it future proof. From what I've read mostly Rec 709 is used but of course you have to tell the system that's what you're using, it doesn't really expect anything.

Bob.

entilza72 wrote:

It doesn't explain why the colour space is so wildly out of step in 32 bit on this project, and then only on sequenced still image output, but that can be a mystery we solve another time.

It's been years there are gamma shifts (not levels) when importing images sequences in a 32 bit project. SCS support acknowledged the issue years ago...

LoTN - bingo. That's exactly how it looks, like an odd gamma shift. Well, I guess that's that then. Fortunately I have no business making this a 32 bit project any more and the 8 bit sequenced images look fine.

Thanks everyone.

Ent.

I'm working under the assumption that like Adobe Photoshop, if I'm working in a 32 bit project, outputting a 32 bit file will yield me identical results to what I see on screen.

That would make sense. Unfortunately, Vegas doesn't work like that. It has a lot of unintuitive behaviours. The long answer is here:
http://www.glennchan.info/articles/vegas/v8color/vegas-9-levels.htm

The shorter answer is that there is a lot of misinformation on this forum. (Umm... there have been some "heated" discussions about this.) And that other NLEs generally handle all this stuff for you. Whereas in Vegas you have to do this stuff manually and there is practically no documentation to help you out.

*What you see on the screen in Photoshop isn't always what you get... but that's a different story and has nothing to do with the original poster's issue.

VASST color correction DVD
That would be me in it. :)

Unfortuantely, a lot of the issues you touch upon came out after that DVD. Since that DVD, every version of Vegas got even more complicated. I think it's too complicated for the vast (no pun intended) majority of people to handle.

I have a project that uses 24 bit Apple Pro Res 4444 MOV files as source material.

It looks like the Prores files are coming into Vegas as studio RGB.
Between DPX and TIFF, it would probably be less complex to export TIFF. (DPX has a lot of variants.)
When Vegas exports to TIFF, you should probably convert everything to computer RGB.

So...
- Use an 8-bit Vegas project. Life is easier if you avoid the "32-bit floating point" mode in Vegas project settings.
- Add a filter with the "studio RGB to computer RGB" preset.
*THIS MAY NOT BE THE CORRECT ANSWER.
-To double check your work, do not use Vegas.

There are three problems you need to check for:
A- Vegas' levels being done incorrectly. Read the levels article on my website. Hopefully you understand it. If not, it's easier to use another NLE. (I'm not trying to be snarky.)
B- Vegas' gamma issues when using a floating point project. Easiest solution: don't use the 32-bit floating point mode. You definitely see this problem in the JPEGs you posted. Or, in Vegas, set compositing gamma to 2.222.
C- Quicktime gamma issues. This one is much subtler than B. Here's how you check: convert your footage to the format you ultimately want, send it back into Final Cut. Compare the camera footage to the footage you imported. Hopefully they look the same.
This issue pops up when you export footage into After Effects and bring it back into FCPro.
*I've never used Final Cut X. So maybe I am overly paranoid about an issue that may or may not exist anymore.

2- What you see in Vegas probably isn't what your footage should look like. This is really unintuitive but true in most situations. :/

Open the original files in Quicktime on a Mac.... that's probably what they should look like.

--------------
It might make more sense to make a DVD instead of a DCP...?
But, I don't know all of the details of your project and what exactly you are trying to do.

It can take 16 bit sRGB as well as 8 bit cRBG, and a whole host of others, or at least on the one I am trialing (DCP Builder).

This bugs me greatly, but PLEASE don't say sRGB when you mean studio RGB. And please don't say cRGB.

sRGB is a colorspace. IT HAS NOTHING TO DO WITH STUDIO RGB. When you say sRGB, you are going to create a lot of confusion. And in this case, it matters. If you mean studio RGB, say studio RGB. The same goes for computer RGB.

-----------------------
sRGB, Rec. 709, XYZ (used in the DCI format) are all colorspaces. sRGB and Rec. 709 have the same color gamut. XYZ has a much larger color gamut and can represent colors that you can't represent in sRGB/Rec. 709. The intense saturation of a laser or the rainbow reflections on a CD are such colors.

One benefit of digital projection from a DCI master is that you can show colors that typical TVs and computer monitors can't show.

In Vegas, you are pretty much working with Rec. 709/sRGB. It was never designed to handle output for DCI. I would just make a DVD.

entilza72:

bingo. That's exactly how it looks, like an odd gamma shift. Well, I guess that's that then.

My guess was right.

I've just checked and THIS IS the root cause of your problem: vegas (BUG) applies a 2.22 gamma compensation to your images (for PNG it is the exact opposite in V9 & V10).

I used your 32-bit-video-levels-no-filter JPEG into a 32 bit project, applied a 0,45 gamma correction on event and it looks exactly like your 8 bit project example. This issue with images sequences gamma compensation error lasts, at least, since V9...

I have switched off Vegas so I can't check sequences with V11 or V12.

Hmm LoTN you are correct.

you are correct

I knew that ;)

Not fixed for years, shame on SCS...

Nice find LoTN. Here's another issue we can add to the list: regardless of the project being 8 bit(s per channel) or 32 bit, those image sequence files are all 32 bit. Maybe not a problem, but unexpected behaviour. I've found the DCP program I'm now using doesn't take 32 bit still image files. :-/

Glenn - nice to have your input here. I didn't know sRGB was different to Studio RGB. Thanks for pointing that out. Still a lot to learn.

Glenn, this begs a question I'd love your input on - what colourspace are we outputting from VP11 8 bit? On the DCP packager, do you think defaulting to sRGB or BT.709 is sufficient? sRGB seems to be OK but has a slightly redder cast (only marginal) but this could be the dedicated DCP player. Other options include XYZ (I don't think we need to be going that far!), Adobe, Apple, PAL & NTSC (we can mark those last too off).

And why DCP? Cinema projection - some film festivals demand it for screening. And the project native is 2538x1080 - I suffered all the crashing and data problems, now people are going to enjoy the resolution. :-)

I'm learning some things along the way here re: DCP creation. I'll post them up for other Vegas users when I'm finished, though I will still be no expert.

Glenn, this begs a question I'd love your input on - what colourspace are we outputting from VP11 8 bit?
It would be whatever colorspace your footage is. I don't believe that Vegas ever applies colorspace conversions for the primaries (primary colors). The most saturated green is different between Rec. 709 / sRGB, EBU, and SMPTE C. Rec. 709, EBU, and SMPTE C are all really close to each other... in practice, people use those formats interchangeably so your green might be slightly different because the correct conversion wasn't applied.
http://www.glennchan.info/articles/technical/hd-versus-sd-color-space/hd-versus-sd-color-space.htm

Oh god this is going to get complicated. The short answer is that Vegas (like most NLEs) will leave your primaries alone. It won't try to change them.

You do need to handle levels correctly.

On the DCP packager
I don't have any experience working with DCP so I can't really help you. I just know the theory behind (some) things.

My *guess* is that the simplest and best solution would be this:
Did you shoot at 23.98fps? If so, make sure your master is 23.98fps... not 29.97fps.

The frame size I don't know about.

Audio: stereo or 5.1 or something else? No idea.

Make a Quicktime Prores that's 1920x1080. Make sure that it's correct. From there, convert it to every other format you need.
Don't do any colorspace conversions... as in, do things like you would do for HD Rec. 709 video. Like you were going to make a Blu-Ray or something.

A digital cinema projector can project 2048x1080 instead of 1920x1080. You could fill up those extra pixels on the side. I really wouldn't bother.
A digital cinema projector can show colors outside the Rec. 709 color space. If you had a lot of time, you could utilize that. I wouldn't bother.
The theatre can play surround sound (various formats) instead of stereo. That's up to you.

If you make a Quicktime Prores (1920x1080, Rec. 709/HD, 23/98) then you can check that yourself. You can't check a DCP yourself easily unless you have access to a DCP system and projector (AFAIK). With the Prores file, you can send it to other people to convert it to DCP, HDCAM, HDCAM SR, Blu-Ray, etc.

I don't know if that's the best solution for you.

----
lotn: Yeah yeah I jumped to conclusions there earlier.

Thanks for the detailed reply Glenn. And levels are fine.

Re: colorspace, I now understand why I'm having a mental disconnect:

The source material is Arri Log C. It's been corrected and graded on Vegas 11 (12 supposedly supports Arri Log C as a colorspace, but I couldn't get a render out of it so went back to 11).

Levels are beautiful and the project looks great on our calibrated monitor with the Studio RGB levels via HDMI. In terms of renders, I've had no problems with Blu-Rays (709) and DVDs (624).

So, the colorspace answer should be to render out as 709 and select "709" when importing into DCP Builder.

BUT ...

Some Render-outs allow you to select the colorspace (eg, MainConcept MPEG2). But others do not, and the sequenced images I need to use do not have this option. And out of all the sequenced image formats, I'm forced to use DPX because the others come out as 32 bit images (from an 8 bit project) and the DCP packager (DCP Builder) rejects those. Wikipedia suggests (to me) that DPX colorspace can be anything you want, which is really useless because I do not know what SCS chose.

With no colorspace selected, it must be defaulting to something. I just don't know what that is.

I'm going to seek help from the DCP Builder forum - but if anyone here has an idea, I'm all ears. As I understand it, I need to know what vegas is building into the DPX

Thanks again everyone for your help - and I promise to return in another thread to write up what I've leanred about DCP...

Ent.

PS: Glenn, I know what you're saying about using a 1920x1080 master, but this project is an anamorphic 1.3 times desqueeze from a full 1920x1080 frame, giving a 2.35:1 aspect (Scope). By putting the image desqueezed inside a 1920x1080 frame, I'm losing roughly 1/3rd the res. The projection format supports that side space, so I'm using it.