32 bit & third party plugins

[Daniel Alexander]

Hello, i was told that certain plugins would not take advantge of the 32bit float capability of vegas 8 such as Magic Bullet Editors, and to confirm this i am presented with the blue icon next to the effect within the effect window. HOWEVER, i decided to run some tests because i couldnt see the logic behind it not working, i mean as far as i was concerned once in a 32 bit color space, whatever 'colour' i added to the picture whether it be from vegas' colour wheel or magic bullets colour suites i would imagine that colour would be applied with the extra freedom/headroom to do what its suppost to do. Anyway my test was this:
1.i dropped a hdv clip onto my timeline in 32bit float mode and added a magic bullet preset
2. i then rendered out the video to mpeg 2, dvd pal
3. i then added the same hdv clip to a new timeline in 8bit mode, applied the same effect and rendered it out to the same mpeg 2 setting
4. i then brought both clips back into vegas and lined them up perfectly so i could do a comparison.
5. i compared in both 8bit and 32bit timelines and on BOTH timelines the 32bit rendered hdv appeared to have a LOT more depth to the shadows and highlights and the colour scope shows quite a leap in colour shift.

now my question is this, if plugins like magic bullet dont take advantage of the 32bit float capability then why is there such a hugh improvement in the image when comparing 8bit to 32bit? or am i just seeing the effects of the original footage being affected by the 32bit colour space by therefor delivering a more dynamic picture when the magic bullet is applied?

[Daniel Alexander]

an ddition to my post is this: when the hdv clips in question are played through vegas and outputted via firewire to a monitor the image looks sharp and high quality, but when i play these rendered clips back on media player they look terrible, they look as if they were encoded as a low wmv or something. All the render settings were at best. Im baffled. I was really hoping for a smooth shift into the world of 32 bit, it seems its still some way away for me yet with all this confusion

[Glenn Chan]

1- Magic Bullet will yield different results if you feed it studio RGB versus computer RGB levels.

2- In an 8-bit project, HDV will decode to studio RGB levels.
In a 32-bit project, HDV will decode to computer RGB levels.

3- More details here:
http://glennchan.info/articles/vegas...or/v8color.htm

[Daniel Alexander]

thanks for that Glenn. is there anywhere you could point me to learn more about computer/studio rgb because if im very honest with you i have no idea. I've been prodcuing videos for indy bands for years and have always worked on a basis of 'hey it looks good on screen, looks good on monitor and thats all im concerned with' it seems now that the difference in rgb and the ability to switch them in vegas is going to massivly affect what i need to do. At the mo i don't even know what rgb im working in whether it be studio or compute and to make it worse i believe it will be different for me seeing as im in PAL

Im really hoping to be able to work with hdv footage like i did in vegas 7 without having to worry about what my video will look like once rendered out.

Hope you can help, thanks :)

[Glenn Chan]

Hi Daniel,

Read this:
http://glennchan.info/articles/vegas...lorspaces.html

And then this:
http://glennchan.info/articles/vegas...or/v8color.htm

2- Don't worry, even I got confused. And the Vegas 8 behaviour doesn't really make sense to me. I can see why it is designed that way... but it is not in line with how I'd like to work and what most people will naturally do and expect. For example, I think anyone would assume that changing between an 8-bit and 32-bit project would only affect the bit depth. But this is not the case... it affects codec behaviour too.

Im really hoping to be able to work with hdv footage like i did in vegas 7 without having to worry about what my video will look like once rendered out.

If you use an 8-bit project, the behaviour is exactly the same as in Vegas 7. But then it means you're not using the 32-bit stuff at all. If you touch the 32-bit modes, things get dicey. The article goes over why.

[Daniel Alexander]

Much appreciated Glenn, i'l have a look at those now.

[Renton Maclachlan]

I know nothing about this 8bit v's 32bit stuff and though I have read various threads on it, don't think I'm any the wiser. On the one hand I read there are improvements in image quality, but on the other it's a minefield.

I am not using HD and was satisfied with image quality in V7 and think at this stage I'd prefer to stay with 8 bit as V7 has. At least its the devil you know rather than the one you don't!

But how do I make sure I'm in the 8 bit mode?

[Daniel Alexander]

under file/preferences you can select whether to use the 8bit or 32 bit mode. If your in vegas 7 you dont have to worry as 8bit is native

[Adam Letch]

but I'm miffed at the whole 32bit process.

Basically I'm running 8.0b, and I'm running Windows XP Pro, with a 2.4Ghz Quadcore, 2Gig Ram, and a Radeon X800 256mb AGP graphics card. Now when I run even DV, I can't preview at the highest setting, and that's in 8bit, now if I run it at 32bit, it becomes a slide show, no motion, just a nice timelapsed frame here or there.

so you guys out there doing it 32bit, how on Earth do you do it? I think at least a reformat might be in order, or is it it's not ATI friendly and is more of a GeForce friendly application?

Or do you guys do your editing, and only switch to 32bit to colour correct?

thanks

Adam

[Bill Ravens]

My workflow, generally, is to work in 8-bit until I'm ready for a master print. Then I'll turn on 32 bit, check the color against my WFM, correct if necessary, then print. Once the print is made, I always check the color one more time. I always stick an NTSC colorbar pattern on the head to check against.

[Glenn Chan]

Adam, check that there aren't things that are slowing down your 8-bit preview. 8-bit DV should be real-time.

Right click the video preview window, don't have the preview stretch to the full frame.
Don't simulate aspect ratio.

Make sure the project properties matches the clip properties. The floppy disc icon in project properties will let you match project properties to a particular clip.

I don't remember other items to check for off the top of my head.

[Daniel Alexander]

I second what Glenn has mentioned Adam, having the wrong project properties drastically affects the playback speed of your video. Also try disconnecting the internet while using vegas, there may be something running in the background you are un-aware of.

[Mike Kujbida]

Since we're on the topic of unnecessary background applications, here's a list from the Sony Knowledgebase.
Nothing for Vista yet. Sorry :-(


Close all background applications. This is not limited to the
programs that show in the system tray. Do a ctrl+alt+del and end
task or process on as many applications as you can, leaving only
Explorer and Systray for 98 or ME. For Windows 2000 and XP
move over to the Processes Tab and click the "Image Name"
heading at the top of this window twice, you would be able to view
these items by alphabetical order. For Windows 2000, you should
only have:

explorer.exe
lsass.exe
mapisp32.exe
mstask.exe
services.exe
smss.exe
spoolsv.exe
stisvc.exe
svchost.exe
system
system idle process
taskmgr.exe
winlogon.exe
winmgmt.exe

For Windows XP, you will only need next to your user name:

explorer.exe
taskmgr.exe

Next to "system":
csrss.exe
lsass.exe
mspmspv.exe
services.exe
smss.exe
spoolsv.exe
svchost.exe
system
system idle process
winlogon.exe

[Adam Letch]

it was a mixture,


I had my 25p DV on 25i, and I reformatted as well, a lot smoother, but I wouldn't be able to edit in 32bit, but as Bill suggested only use it at the end to do colour correction.

So Glenn, if we correct in a computer colourspace at 32bit, when we render to DVD will the colours still be correct, or once we correct do we switch back to render out?

Thanks

Adam

[Bill Ravens]

Unfortunately, it really depends on which codec you're rendering with. Each one behaves differently, which is why I always check it with an NTSC pattern. Glenn has compiled a list of some codecs, but, it's not complete.