VP14 BUG - Minimum VEGAS Sharpen (0.001) gives way too much sharpening

NickHope wrote on 10/4/2016, 3:41 AM

Although the previous VP13 sharpening bug has been fixed (whereby sharpening behaviour was different with GPU-acceleration on), there is a new one in VEGAS Pro 14 (Build 161).

The minimum value of 0.001 gives WAY too much sharpening, both with and without GPU-acceleration on. It's about the equivalent of 0.600 in Sony Sharpen in VP13, and hence there's a huge leap between 0.000 (which doesn't sharpen) and 0.001. It's therefore not possible to apply a little subtle sharpening.

Can anyone else confirm this?

Support request: [Ticket#2016100517007897]

Comments

VidMus wrote on 10/4/2016, 4:55 AM

As usual, it looks like they used a bug to fix a bug.

Marco. wrote on 10/4/2016, 7:21 AM

Even at 0.00001 it triggers that exaggerated result. Actually even at 0.000002 and at 0.000001 it down to being turned off.

malowz wrote on 10/4/2016, 8:46 AM

mine seems to work properly (results looks the same as v13)

in what exact settings you are using?

Marco. wrote on 10/4/2016, 9:17 AM

In Sharpen FX there is only one setting and this one set to 0.001 for a quick test. You'll probably only see what happens if preview is set to "Best (Full)" without any scaling. Maybe it is best seen when used with 4k media.

I didn't compare with VP13, because even if it's same there, it should be optimized.

malowz wrote on 10/4/2016, 9:34 AM

Ow, the bug was me. i was testing unsharp mask :(

but testing sharpen, i got a linear sharpening curve... the result in v14 are identical to v13. no jump equivalent to 0.600

Marco. wrote on 10/4/2016, 9:37 AM

I also didn't test a jump from 0.001 to 0.6. All I see is there is way to much sharpening even with a value of 0.000002.

NickHope wrote on 10/4/2016, 10:17 AM

I also didn't test a jump from 0.001 to 0.6. All I see is there is way to much sharpening even with a value of 0.000002.

What I meant was that 0.001 in VP14 roughly equates to about 0.600 in VP14. The histogram helps illustrate this.

Apart from not being able to do a mild sharpen, this bug will affect projects brought to VP14 from older versions. It could really catch people out as it's the sort of thing editors might not notice.

Marco. wrote on 10/4/2016, 1:05 PM

I also have a test project with a 4k media sample in it for download. Sharpen already applied (as Video Output FX) there with a value of only 0.000002. If you take a look into the FX window it will display 0.001 though it is 0.000002.

If you bypass the fx you'll see pretty clear how much this minimum adjustment affects the output. And the least reduction from here will turn off the fx (in the meaning it doesn't affect the output no more at all).

If testing be sure you set the preview window to "Best (Full)" without any scaling.

NickHope wrote on 10/11/2016, 12:21 PM

I had a reply from Support to say that this issue has been escalated to QA/Dev to get entered into their bug tracker.

NickHope wrote on 10/23/2016, 8:22 AM

I now can't reproduce this bug in either VP14 build 161 on my laptop or build 178 on my desktop with various types of footage including the .MTS clip linked to above. The amount of sharpening at amount 0.001 is, in my opinion, excessive, but at least it is consistent between VP14, VP13, VP12 etc.. I don't know why this is. Perhaps my error in the previous testing.

NickHope wrote on 11/19/2016, 5:20 AM

In VP14 build 201 the low-end range now gives much less sharpening, and the degree of sharpening is still consistent whether GPU is on or off. So in that respect it's fixed. Users should beware that if they open a project from an older version in VP14, the sharpening level is likely to be different. In particular a VP12/13 project that had a low sharpening value (0 to 0.2) will have less sharpening effect in VP14 (but still the same numerical value).

However the sharpening algorithm itself appears to have changed. I'm not sure when. The VP14 sharpening is grainier and perhaps magnifies noise more than VP13. It's a subtle difference but the VP13 algorithm is kinder to skin tones based on my test here. I suppose it's possible that the difference is caused by the underlying decoding of the file, which is slightly different between the 2 versions according to the histogram shape.