Plea to New Users -- Please Do Not set 32 Bit Pixel Format

Comments

DrNeb wrote on 2/7/2019, 11:06 PM

Huh? Gosh after watching Gotham lol, this post sounds like one of those loonies trying to convince the people that there's fish in sky and nothing in your eye! Pithy poetry people!

For ****sake of course you don't use 32bit video processing with 8bit image files...anyone who did that and then got on a forum and complained would deserve a little forum kicking. Now what you should be doing is processing with 32bitfp...even with 8bit image files...because of rounding errors. How do I know this...I come from an audio background and to get the best out of the analogue emulation aesthetic...you have to process and record at 64bitfp. The difference between a 24bit audio file with analogue emulation is night and day. 24bit grainy and harsh...64bitfp sounds like it could have been recorded in the analogue era.

I haven't done the same level of experiments in regards to floating point video processing...but I suspect we'd see a similar result. And even if not...why wouldn't you process at 32bitfp when in doing so your image files are corrupted or destroyed by doing so? Our computers are that powerful now...it makes little difference.

Now there's always a caveat...as there is in parallel with audio. In audio if you plan to go in and out of the box or process not using plugs or indeed you're recording and not much plug processing is to be done - I always recommend stick with 24bit. With image processing the same principle applies. If you've got some already compressed 8bit image files and you're splicing not processing...then again stick with 8bit processing.

Musicvid wrote on 2/8/2019, 5:15 AM

 

Well, it looks like this discussion has turned abruptly to mediocrity. But I've got more tests in the works.

You do not have permission to hijack my thread with a blustering rant about audio, DrNeb. However, my signature is worth a peek.

Permission given to move this to the OT boneyard, Captain. Fewer, and perhaps more selective eyes may lurk there.

Musicvid wrote on 2/10/2019, 7:43 PM

Continuation of the discussion, using narrow criteria, is here:

https://www.vegascreativesoftware.info/us/forum/this-is-not-about-grading--114804/

fr0sty wrote on 2/11/2019, 8:44 AM

Is it really worth clogging this forum up with new threads just because one person dared to challenge your point?

Musicvid wrote on 2/11/2019, 10:19 AM

No, it's not.

Finally putting an aging Sacred Cow to pasture may have some intrinsic merit.

It was actually Sony who started all the hype and confabulation that is "clogging up the forum" and people's workflows for 12 years now, and which remains with us as an albatross to this day.

https://www.vegascreativesoftware.info/us/forum/what-exactly-is-32-bit-float-processing--59324/

Actually, John's statement is as accurate today as it was in 2007, when taken in context with more recent advances.

craftech wrote on 9/9/2007, 12:55 PM

The problem with Sony's description for Vegas 8 is that it isn't really clear what they are talking about:

"32-bit Floating Point Video Processing. Surpass traditional 10-bit standards with 32-bit floating point video processing. Take advantage of greater color range for more vivid colors, reduced gradient banding and posterization for smoother color transitions, linear light capability for optically correct compositing, and many other precision enhancements."

Vegas 7 processes in 8-bit per channel files (depth of color). It seems unlikely that Vegas 8 would process in more than that so they are "probably" talking about a 32-bit mathematical computation of each pixel and NOT the processing each channel.

As a relative newcomer to the ongoing discussion, I understand your perspective completely. Some of us have worn our teeth down to the gums in defense of real-world credibility, and several have already expressed relief at finally having a clear target with graphic data upon which to focus and refer.

A belated welcome to the discussion, which has occupied volumes in our thoughts and archives.