Only if you fail to add the inverse transform (ComouterRGB to StudioRGB) on the output. In 32bit Vegas decodes HDV differently to how it decodes other things

Are you sure Bob? My renders from 32bit projects do NOT differ in colours from the original, without an space/levels conversion.

Just like the renders from an 8bit project - they are the same in colours as the original mxf/hdv.

What does differ between 32 and 8bit is the preview window colours.

It depends on which codec you render with.

Sure it does - but since the poster didn't indicate otherwise, I assumed Mainconcept MPEG-2

"What does differ between 32 and 8bit is the preview window colours. "

Did you try applying the ComputerRGB to StudioRGB FX in the Preview window when in 32bit?
Then your preview window and scopes will read correctly.

Bob.

holy cow! applying an FX to the preview window affects the scopes!

Piotr...

You're assuming Mike is using Mainconcept? It could be avi or sony YUV or wmv, etc, etc.

are you guys using video or linear gamma? (or somewhere in between since it's just an integer that can be made to be anything.

Dave

Geez Bill,
I posted this over at DVInfo along with pictures over a week ago.
Glenn must have mentioned this here six months ago.

Scopes, where do you want the scopes to measure?
What do you want them to measure?

In 8 bit the values go from 0,0,0 to 255,255,255. In 32 bit they most likely go from 0.0000000 to 1.00000000 (maybe I missed a few zeroes).

Or do you want the scopes to read like the long deceased composite hardware scopes?
Seems daft to me, there's no burst or porches in digital video!

Bob.

OK: I knew that it depended on the render codec and I should have stated, but like Piotr, I assumed we were all talking MainConcepts for m2t or m2v.

Yes, I render to MainConcepts 1920x1080x24p at 35Mbps VBR to get an m2t file which as demo is played from a data DVD via a PS3 or directly from the computer HDD to a HD LCD TV.

So should I dare ask you all to start again?

Mike

Simple, basic suggestion.
The EX1 can record bars, assume Sony got them right.
Use them to calibrate everything through your chain and anywhere you have chains going off to the side, like connecting the camera directly to a monitor / HDTV.

I *think* Glenn did say that the HDV codec expects to see computerRGB, but what the heck, use the EX1s bars and test it.

You should be able to record bars in the camera, process through Vegas and get a m2t file. Open that back into the same Vegas project and get the same answer.

Bob.

hehehehe
a little slow on the uptake today, Bob?

Doesn't work for me. I import a colorbar pattern from my HD110(ARIB multuformat), then render in 32 bit to m2t with Mainconcept. No FX applied, whatsoever. Reimport the new m2t and it's been converted to studio RGB. It works in 8-bit, but not, apperently in 32 bit.

"Reimport the new m2t and it's been converted to studio RGB. "

That's strange, I would have thought if anything it'd have been converted to ComputerRGB. I should try this with the EX1, not that it should make any difference.

Bob.

On the contrary, Bob. I would almost welcome it if you discovered I made a mistake. This whole thing is very troubling to me.

When Bob and Bill worry we all should worry.

Well I just tested it!

Results are perfect.
I recorded multiburst bars in the EX1, converted through the clip browser to mxf, dropped onto Vegas T/L. Looked with scopes. I don't really know what those bars are supposed to read but the swtaches all lined up with significant marks so I guess they're correct. Switched to 32bit 2.222 gamma, switched scopes to Computer RGB and eveything was exactly the same. WOW!

Rendered to 50i HDV (no xdcam profiles so winging it a bit here). Bought the m2t file back into the SAME T/L. What I got from the EX1 and the rendered output matches exactly in both 8 bit and 32 bit.
Running the cursor down the T/L between the source and output clips the ONLY thing I can see is slight increase in the noise on the bars. No shifts in gamma, the linear grad is the same slope. I could probably null the two images and get next to nothing.

The only thing that's now buggin the is I didn't get any tone when I recorded bars, bugger, my EX1 is broken.

I really don't know what you and Mike are doing but there's something in common that doesn't add up. If there wasn't so much water between us I'd drive down and have a look see first hand.

Bob.

Bob: We could meet in Hawaii.

I'm off to follow you test because that is exactly my work-flow.

Mike
PS: I think you can turn on the tone in the menus.

And if anyone wants to see my results drop me an email, (addy is in my profile) and I'll email you back the screen grabs of the Vegas project and T/L and scopes just so you know I'm not cheating.

Hawaii, hm, been there several times now on the way to/from NAB.
Even got the royal tour thanks to another Vegas user.

We should invite Megabit (Piotr) I'm certain he'd like a chance to thaw out.

Bob.

I just noticed this in Glenn's article on 32-bit Vegas.

"Also note that flipping between the 32-bit and 8-bit modes in Vegas can potentially give you problems. I believe the intention of Vegas 8 is that you pick either mode and do not flip between them. However, it can be desireable to flip to a 8-bit project for the faster performance and then to 32-bit when you render. The problem is that the levels of the footage can change on you if you do this."

So maybe I should not consider to do this but stay in 32-bit and computer RGB always? - At least until I install NEO HD which is one of Glenns work-around options.

We should invite Megabit (Piotr) I'm certain he'd like a chance to thaw out

Thanks Bob - I consider myself invited :)

This is what I always thought / saw: as far as colours are concerned, the actual renders (using Mainconcept MGEG-2) do NOT differ between 8/32bit (and what's more important, are identical to the source hdv/mxf if no FX was added). Therefore:

- when I am in a hurry and/or do not need increased computational precision, I stay in 8bit throughout my edits; the colours I judge using the Windows Secondary Display with Colour Management and Studio RGB checked

- otherwise, I use 32bit (colours are then fine also in the Preview Window).

No need for levels/RGB spaces conversion here (well, apart from this adjustment for the Secondary Display - but not to my material, actually).

Of course, the 32bit renders are supposed to differ from those 8bit ones in colour precision (e.g. less banding), which I actually did witness here and there.

I posted my results here:
http://www.dvinfo.net/conf/showpost.php?p=832396&postcount=83

I haven't tried applying an FX and switching modes to see what if anything happens, possibly what Glenn meant is that the FX could pickup the current mode and not switch when you changed although I doubt that's what he meant. The only time I've seen this kind of thing happen is with gen media switching between 4:3 and 16:9 but that's almost certainly something different again.

In the end I'm kind of amazed at the level of confussion. I do think that SCS themselves have a lot to answer for. It's great that Glenn has taken so much time to investigate this however the responsibility must rest with the developers. As far as I'm concerned if it's not documented it doesn't exist. There's two big new features in V8, both of which are supposed to be big selling points and yet they're not documented.

But ignoring that I also have to ask, why the headlong rush into 32bit processing anyway? I still use V7 almost exclusively, it works just fine for me. The 8 bit pipeline works, so why would I waste hours rendering in 32bit if I don't have any of the issues it's designed to address. Come to think of it I'm yet to see anyone find any circumstance where it achieves anything. On top of that comes the obvious question. If 32bit is all so vital then we've been mugs for a few years, V7 didn't have 32bit, was everything we did with V7 seriously flawed, I think not.

What did seem to happen was shortly after V8 came out a few were jumping up and down about how great it was that their footage was suddenly more colorful in 32bit. In hindsight it seems they fell into a trap but unfortunately the 32bit buzz generated has carried over and not helped at all.

There are situations that can benefit from a linear light 32bit FP pipeline but they're rather esoteric and as far as I can see Vegas still has no way of getting the material in or out that would make use of that kind of pipeline.

And in the end, as the old saying goes, all that matters is how it looks on the big screen.

Bob.

Bob...
Just repeated your test. Using the EX1 colorbars and rendering to 50i, following your "recipe", I can confirm your results. Wooohooo!

Next question: Sorry for being so thick-headed, but, these files are OK when viewed in the scope and on a computer monitor as Computer RGB. If I wanted to view this on an NTSC monitor, wouldn't the hi's and lows be blown out/crushed, since the monitor is StudioRGB? In fact, viewing in my NTSC external monitor, the pluge is blown out...gone...no pluge bars at all. So, in effect, the scopes say everything is fine, but, the displayed image on the studio RGB monitor isn't. Is this where you're suggesting modifying the preview window with a LEVELS FX and ignoring what the external monitor is showing? note that the PREVIEW WINDOW and external monitor window can show DIFFERENT things. The Preview Window always shows computer RGB, the external monitor will show the effect you have selected in the preview device settings.

P.S. Yeah, you need to turn on the audio test tone in the menu.

This is what I always thought / saw: as far as colours are concerned, the actual renders (using Mainconcept MGEG-2) do NOT differ between 8/32bit (and what's more important, are identical to the source hdv/mxf if no FX was added).
A situation where it matters is if you have, say, the color bars generator on the timeline (or DV, etc.).

Try sticking that on the timeline. Render to MPEG-2, with an 8-bit project and then flip it over to a 32-bit project and render again.
Bring both files into the same Vegas project. The levels on the rendered files will be different.

As you already noticed, MPEG-2 clips won't have that problem in that situation.

--What's happening:
Some codecs always decode to studio RGB levels. The color bars generator effectively behaves like this.
In an 8-bit project, the MPEG2 codec expects to see studio RGB levels. The rendered file will have correct levels.
In a 32-bit project, the MPEG2 codec expects to see computer RGB levels. But you are sending it studio RGB levels. The rendered file will have incorrect levels.

If I wanted to view this on an NTSC monitor, wouldn't the hi's and lows be blown out/crushed, since the monitor is StudioRGB?
It depends on whether you're going firewire out or SDI out. (Ok, I actually haven't tested SDI out but I strongly suspect it will be different.)

For example...
Suppose you have MPEG-2 clips on the timeline, and are going firewire out.
Flip the project between 8-bit and 32-bit.

On your external monitor, the levels will change. But if you render the files out and make DVDs, the DVDs will have the same levels.

---------------
So I outlined the cases where things screw up. A table like the one in my article can help you figure out when these situations occur and how to avoid them.

(Better yet, Vegas could be designed to handle all these conversions for you. In which case you wouldn't even need a table to begin with.)