The XDCAM EX thread: https://www.vegascreativesoftware.info/us/forum/vp15-rendering-16-235-instead-of-0-255--109582/

Thanks for your answer and for pointing at pixel format. I'm confirming that changing pixel format to 8-bit solves the issue with Sony AVC encoder.

I use Sony AVC encoder for rendering drafts only as it is fast and by my tests gave better and more stable results than Mainconcept (one of my bug reports to Sony was about Mainconcept encoder issues. It was not reported as fixed so I'm not using the encoder any longer. Unfortunately, I do not know if the bug is still exist).

I use 32-bit pixel format as I'm using external encoder (through frame server) for final renders where I have ready to use scripts. I do remember that long time ago (Vegas 11 era) I played with different pixel formats for my SD video projects and found some detectable differences (32 bits gave better results) and then decided to use it "by default" for all my projects. It is possible that my tests was not absolutely correct these days (I just started with video editing then) or my perfectional-ism forced me to believe in this. I do not have the test project I used for the comparation.

P.S. I'll send a bug report about the issue.

It is one more option from my WISHLIST - selectable - full or video - levels when rendering. Now all we have is to add Computer RGB to Studio RGB before rendering.

Floating point won't provide any advantage in this case, but worse playback and longer render times instead. I'd really recommend using 8 bit instead.

2 Cornico: You suggestion is about levels in preview. I do not care about preview as I'm using scopes while tuning levels (However, it would be really-really good to have working preview in one-monitor setup. Can I vote for the feature somewhere?).

The bug is not about preview, it's about levels that are changed in rendered video.

> Floating point won't provide any advantage in this case, but worse playback and longer render times instead. I'd really recommend using 8 bit instead.

It is possible.

However, If I understand correctly, we can also get slightly better results with 32-bit pixel format when we use chains in filters (as the results after the first filter is not rounded up and used as-is by second filter etc). And I always have chains in filters for almost every part of my project.

I would prefer not to loose any bit of quality if possible without a reason (this is why I use external x264 encoder).

I agree, that speed is much better with 8-bits pixel format. Unfortunately, I cannot work on my project in 8-bits and then switch it in 32-bits before the final render as some filters give completely incorrect results in this case. Well, it used to be this way when I checked. It is possible that in Vegas 15 such issues are fixed already.

You suggestion about levels in preview. I do not care about preview as I'm using scopes while tuning levels (However, it would be really-really good to have working preview in one-monitor setup. Can I vote for the feature somewhere?).

The bug is not about preview, it's about levels that are changed in rendered video.

It's very old issue between almost all editing software and video players. Quicktime shows video too gray, Media Player Home classic in default too contrasty. But there is an option in MPHC to choose levels - 16-235 or 0-255. There is also problem with color matrix - when you upload your footage to Vimeo or Youtube you can see noticeble color shift.

I do not have issues with my videos videos in any player with default settings (including MPC, QT, uploading to youtube, vimeo, etc).

It does not mean that is no such issues at all. However, if the video made correctly, such issues are minimal.

In my case everything worked fine in Vegas 11, 12, 13. But in Vegas 15 it does not work fine any longer with absolutely the same workflow if 32-bits pixel format and SonyAVC encoder is used (it works fine in other cases). For me this means that there is something not good in Vegas 15.

Yes, these (preview and floatpoint render levels) are two completely different things and while the floatpoint thing quite probably is a bug, the preview thing is just one possible (and appreciated by many Vegas users) way of internal processing of video levels.

Well, I have here a project with 10bit Hypergamma footage from my FS7. Was editing that in 32bit mode - and had to render it to AVC. The Sony Encoder failed since the levels were changed. So I took the MAGIX AVC Encoder and that worked fine.

However, If I understand correctly, we can also get slightly better results with 32-bit pixel format when we use chains in filters (as the results after the first filter is not rounded up and used as-is by second filter etc).

With 8 bit source, no one has been able to demonstrate a measurable effect. The reason is that the source is not upsampled in a 32 bit project; it's just full of air, which can't be graded.

With 8 bit source, no one has been able to demonstrate a measurable effect

- Open Vegas, create a new "32-bit video levels" project

- Add checkerboard media generator to time line, set the first colour to 0.5, 0.5, 0.5, 1 and the second colour to 0.9, 0.9, 0.9, 1

- Add to the checkerboard fragment "Levels" filter twice

- For the first instance of "Levels" filter in the chain set "Input end" to 0.5 (some colours are moving outside of 8-bits colours range)

- For the second instance of "Levels" filter in the chain set "Output end" to 0.5 (so you simply reverting everything back)

You should see squares in preview and four lines in scopes

Now switch the project properties to 8-bit pixel format. You will not see squares in preview any longer and only one line will be shown in scopes (128). Switch project back to 32-bit pixel format and you will see squares again.

While working with 32-bit pixel format the range during calculations is not ended up on white colour. So if one filter in chain moves colours "above white" the colour is not clipped before the second filter in chain.

The same thing can easily happen when you are working with normal video (not media generated as in the demo) and using a few filters in chain. You can minimize it's effect by using specific filters order. However, I prefer to set project to 32-bit video levels pixel format and do not even think about possibility of the issue.

Here is the quote from Vegas help:

When using 8-bit input/output, the 32-bit floating point (video levels) setting can prevent banding from compositing that contains fades, feathered edges, or gradients.

The issues is reported. Ticket#2018012417003314

Thank you for your message. I have tested this and gotten the same result on our end. I have sent a bug report of to our dev team so that it may be addressed in a future update/release of the software.

You should see squares in preview and four lines in scopes

Now switch the project properties to 8-bits. You will not see squares in preview any longer and only one line will be in scopes (128). Switch it back and you will see squares again.

Got renders?

@fifonik These are cases where I would also use float point processing. Sometimes.

One thing to take care of, for 8 bit outputs it would only help if your signals exceed the range from 0-1. But usually I carefully control the levels via scopes and try to avoid leaving the range from 0-1. Then there's no need for float point processing when your project would finally leave as an 8 bit video.
(And just to avoid confusing others: if the output is 8 bit or any other integer processing type, this recover of clipping only works inside this very float point project before rendering.)

The other thing to take care of is, not all of the plug-ins completely support float point processing, e.g. if you use Color Curves this would likely break the advantages mentioned above because Color Curves just cuts everything beyound 0-1, even within float point projects.
So as an example, in a float point project you could clip your signal with the contrast slider of "Brightness & Contrast" and exactly recover with a second "Brightness & Contrast" plug-in. But once you put "Color Curves" in between the two "Brightness & Contrast" plug-ins, there is no way to recover clipping even if you did not touch the curve.

I left banding out here because it is a even more complex area.

Agree.

I'm aware that not every filter supports 32-bit processing and levels are truncated by such filters (almost in the same way as in 8-bit processing, not worse).

I also aware that everything that out of range will be lost after encoding.

However, for me 32-bit processing looks better as in some cases there is no [multiple] data loss in the filter chains.

So the overall quality is never getting worse. The speed is (this can be vital for 4K editing).

In 8-bit processing, with more than two filters in chain to prevent the levels trimming I have to control levels (with scopes) after each filter applied. For example, is I already applied two filters and then I'd like to tune the first filter in the chain, I must disable the second filter before the changes because in other case the scopes will not show me correct levels.

The situation becoming worse if I have not only two filters on event, but media filter, track filter, output filter etc.

It's just harder and harder to manage the situation.

So for myself I decided to use 32-bit processing to rid of at least some trimmings.

I'm not forcing others to do the same. I'm not telling that this is the only 'right' way.

I'm just pointing on the possible issue that could be partially solved by switching to 32-bit processing.

(And just to avoid confusing others: if the output is 8 bit or any other integer processing type, this recover of clipping only works inside this very float point project before rendering.)

Thank you finally for the reality check, @Marco.

That's a pretty big if, since 8 bit is the only deliverable format to the overwhelming majority of consumers. To me, the outlying bits from grading 8 bit source in a bigger space are best described as slop. Analagous to adding a high-pass filter after the leveling step. Effect.on the histo is the same.

It is actually encouraging to see new users making independent inquiries, even if down these same well-traveled roads that were cleared over a decade ago.

It is the indifference arising from uncritical thinking and absence of any testing protocols or opportunity for independent verification, that imprison these theories in murk and speculation, since the conduit is lacking to reveal them in the light of day.

fifonic could do his fellow third-generation video hobbyists a big service by backing his preferred methods, in addition to his troubleshooting observations (nice job!) with source and render visuals, instead of revisiting common thought processes that are "almost" right. Just saying.

But then, we are playing to a different house than previously, and there's.nothing like some good old street-level hype and superstition to sell.your product in the 21st century.

The most shameful cause of consumer disinformation in this century is that critical reasoning skills and scientific methodology are not taught in the schools past ninth grade (if that), the result being that executive function and metacognitive skills in so many individuals never develop past that point. Witness the shocking tendency of intelligent 30-somethings to live with their parents, pursue gaming instead of working, and who have become emotionally stunted by the excesses of our pro-entitlement, anti-survival culture. Hatchery raised, color added.

https://www.cnn.com/2018/05/22/us/judge-rules-son-must-move-out-new-york-trnd/index.html

This is sad that the levels issue was not fixed in VP15 build 311 :(

Looks like levels issue for 32-bit pixel format projects rendered using Sony AVC encoder is fixed (tested with my test project).

Thanks.

Thanks 👍

For the first instance of "Levels" filter in the chain set "Input end" to 0.5 (some colours are moving outside of 8-bits colours range)

- For the second instance of "Levels" filter in the chain set "Output end" to 0.5 (so you simply reverting everything back)

My big deal about the scientific method is excluding the Pygmalion Effect completely (5 up), not in designing tests that appear to support my conjectures.

That all said, your test ignores the collateral impact of Vegas' dirty pattern dither, because you did not follow through and render an 8 bit lossless file from your float project. I did that too, and found it completely negated any theoretical effects of doing what you hope to accomplish. That's the conservative version.

IF I had 10 bit source in a float project with grading, I would render a 10 bit lossless intermediate and dither to 8 bit in x264/265. Using Vegas to render a downsampled file would be a course of last resort in my workflow. Again, the statement from Magix is hypothetically correct, and does not necessarily foretell real-world outcomes. You can't make a silk purse from a pig's ear. Been there.

But you've got a great mind and that's why I bother to point out possible pitfalls in methodology. By all means, keep inquiring, you've already touched on some areas I haven't revisited in some time. Unfortunately, forum software doesn't allow critical image inspection but I'll upload them anyway. Keep up the good work; a couple of other old-timers seem impressed, too. 😉