Hi

I've been testing levels and colour shifts again on Vegas and to test objectively I have got a JPEG with 256 levels of grey which I drop on the timeline, this has been used for testing various render settings and the correct handling of 0-255 or 16-235 video in my workflow.

In 8 bit video mode, I can preview this image and grey levels are all correct, i.e. I can copy from the preview window and then using a colour picker in an edit package confirm that all the 256 greys are unaltered, i.e there has been no changes or loss of values. A nice flat histogram is attached. I can also render this video and play back and again confirm all greys are spot on by taking a screen grab from my media player on the PC and see there has been no shift in levels or data lost.

As soon as I switch to 32 bit mode (either full-range or video), I get lost values and shifts in greys and a screen grab and then checking the colour values shows for example that grey with RGB 111,111,111, is now 96,96,96 with all others shifted. All blacks below about RGB 12,12,12 have gone to zero. A histogram shows the changes, see attached.

Surely this is wrong, I shouldn't be losing info just because I've switch to a 32 bit timeline? I should have more values not fewer.

Can anyone shed any light to what is happening?

Regards

Phil

I should have more values not fewer.

No, not more, just the same. At least not until you adjust the colors with a filter or an effect.

Anyway, try if this fixes your problem: Click the Video Output FX button, which should be the third button from the left above the preview window. From the list of effects that will pop up, select VEGAS Color Corrector (it may say Sony Color Corrector on older versions of Vegas) by double clicking on it. Click OK. At the bottom of the Color Corrector, find the slider marked Gamma: (should be the second slider), then type in its input window 1.196 - that seems to work for me to fix the same problem.

I don’t know why it works for me, so I am not saying it will work for you, but it is worth trying.

Hi

Thanks for your reply. Yes I was meaning more values should mean the existing ones stay intact, i.e. no reason to try and squash anything in by dropping values.

I tried the filter as suggested, it just shifts the comb effect on the histogram so it's still being changed.

I've attached the Jpeg image (it may have been recompressed by this site) I've been testing with, in 8 bit video mode all the 256 values pass through unchanged, but 32 bit mode messes it up.



Regards

Phil

OK, I checked it with your image, and you are right, Vegas changes it. And, it would seem I am also right in that it changes the gamma, though the 1.195 value is not the correct one. The correct value is somewhere between 1.25 and 1.27, at least in Vegas Pro 14.

There are clearly at least two bugs at play here. The first one is that Vegas changes the gamma without being asked to. The other one is that when you try to counter it by setting the output gamma to somewhere between 1.25 and 1.27, it actually changes each channel differently, so suddenly a gray pixel, such as 250,250,250 becomes 247,248,255, which is patently wrong.

Reporting it to https://support2.magix.com/customer/en/vegas/form should, in theory, let the programmers deal with it. If you feel like it, let them know. But, historically, they have never fixed the problems we reported, so I’m not going to bother reporting it myself. I’ll just create a LUT for myself that will fix the gamma equally in all channels.

If I can make the right LUT to fix the problem, I’ll let you, and anyone, download it, if you want it. But no promises, as I’m an old guy who gets tired easily.

After extensive checking, I have settled on gamma adjustment of 1.1725, not as a solution but as a compromise. Whatever Vegas is doing is seriously buggy, so no single gamma value will fix the problem.

But, if you want my LUT and see if it is, while not perfect, at least an improvement, downloading http://www.pantarheon.org/FixVegasBug.zip will get you the LUT (and of course you will need the VisionColor plugin to use it, if you can still find it).

Can anyone shed any light to what is happening?



Phil what version of Vegas are you working with? The reason I ask is that as of v14 build 161 this issue is supposed to have been fixed. I haven't tried it to see for myself but here is an excerpt from the b161 release notes.

"Improved gamma calculations for still-image sequence renders for 32-bit floating point projects. Now levels for 32-bit floating point (video levels) and 32-bit floating point (full range) with nonlinear gamma are more consistent with 8-bit levels."

This came from:
https://www.vegascreativesoftware.info/us/forum/vegas-pro-14-0-build-161-released--103567/

Chris Young
CYV Productions
Sydney

Hi

Thank you everyone for the input.

I'm using version 13, so it may be fixed in 14 then, and by what they have written it may only affect images on the timeline.

I'm loathed to pay for version 14 just for a bug fix. I will just stick with 8 bit or accept images on the timeline go a bit funny in 32 bit mode. My aim is to look at other editors, it's just finding the time to learn something else, and sometimes better the devil you know :-)

Regards

Phil

I’m using Vegas Pro 14 Build 252 (the latest) and I see this issue.

Hi

Thanks for confirming the bug appears in 14 as well. It's ironic 32 bit mode is suppose to help stop rounding errors from changing the image yet that's the first thing it does!

With cameras now supporting 10bit 4.2.2 and the move to HDR video, using 32 bit mode will become a necessity, so hopefully Magix will fix this.

It's frustrating as Vegas has the tools to see what is going on regarding colour spaces and levels and the tools to deal with them correctly from start to finish, but then manages to fail to do it.

Magix if you are watching this forum, we could also do with some more flexible rendering options, for example being able to set full range or limited range (computer or studio in Vegas terms) when producing MP4's so they are flagged correctly. I can't do this currently as far as I know and Vegas isn't clever enough to set this based on the the 32 bit full range/limited range property setting.

Also if I drop a full range video (from GH5 0-255 that is correctly flagged as full range) onto a 32 bit full range time line, it places a Studio to Computer conversion on it. So I need to add a Computer to Studio level conversion to bring it all back, that doesn't seem correct to me and hardly intuitive.

Regards

Phil

Magix if you are watching this forum,

I doubt they are, though I did mention the problem and this thread on their own forum (https://www.vegascreativesoftware.info/us/forum/a-color-level-bug--106717/). I have not seen any Magix employee comment on it (they rarely do, though).

What surprised me was that one of their moderators said, “At "32-bit floating point (full range)" I would expect to see changed RGB values, but with different values from the original issue with 8-bit grayscale images.” He didn’t explain why he’d expect that.

I shall just continue using that LUT I made. I stayed up all last night trying to find the exact curve fit and make a LUT that would reverse everything to its original, but so far have not succeeded.

I made a chart/graph which shows the original values in blue and what Vegas does to them in red and uploaded it to http://oi67.tinypic.com/202yq0.jpg, where it shows the shape of the curve that needs to be fixed.

I’m using Vegas Pro 14 Build 252 (the latest) and I see this issue.

Yes double confirmed. Just tried it in v14 b252 as well as v13 with the uploaded grey scale and can confirm the issues are still there. I'm in the middle of a job with 10-bit 422 XAVC-I at the moment and do all my editing on an 8-bit timeline and then switch to 32 floating point video levels for the final grade and render. Interestingly I'm not seeing anywhere near the gamma shift in these video files as I am with still images. More investigation required I think.

Chris Young
CYV Productions
Sydney

Interestingly I'm not seeing anywhere near the gamma shift in these video files as I am with still images.

Yes, I see it for still images and for sequences of images (animations) only. I make tutorials for YouTube and use sequences of PNG images created with the latest version of POV-ray as animations, and the problem is there despite the most recent version of POV-ray explicitly writing the gamma of 1.000 into the PNG files.