GPU bug: Pale edges of imported Photoshop layers

NickHope wrote on 10/26/2014, 5:35 AM

When "GPU acceleration of video processing" is enabled in the Vegas Pro video preferences, the anti-aliased edges of imported Photoshop layers are paler than they should be.

The easiest way to demonstrate is with an example. Here is a zip file that contains a very simple VP10 project and associated 2-layer Photoshop file. The lower layer is a 320x240 grey rectangle. The upper layer is a centered 160x120 rectangle. The layers are added across tracks in the Vegas project. I have set the width and height of the project to 317x237 to force the edges of the smaller rectangle to not line up with pixel edges in the Vegas project so that they get anti-aliased by Vegas. With GPU acceleration on in VP12 or VP13 these anti-aliased edges appear paler than they should:

It seems to me that the GPU-anti-aliasing code is doing some unwanted "shaping" of the edges, increasing the luminance before fading out, a bit like the ringing created by sharpening. In the majority of cases of Photoshop import I would say this is unwanted.

If GPU acceleration is turned off, or in VP10, the whole area remains uniform grey, as it should.

I have tested this in VP12 and VP13, using either my Nvidia GTX 580 or my AMD HD 6970 for GPU acceleration.

Please can someone else verify this behaviour before I submit a bug report?

Comments

john_dennis wrote on 10/26/2014, 12:56 PM

I opened the test project in Vegas Pro 11 on my laptop which doesn't have a qualified GPU and did not see any signs of a lighter grey outline.

On my i7-3770 (k) machine running Vegas Pro 12, there is no outline with GPU acceleration disabled. The outline appears when I enable the on-die Intel HD Graphics 4000 GPU.

Vegas 12 - HD4000 GPU

On my Q9450 machine running Vegas 12 the grey outline is visible when acceleration with the NVidia GTS 450 is enabled but not when it is turned off.

Vegas 12 - nvidia GTS450

Sorry I can't test Vegas Pro 13 today. I only have it loaded on a Windows 10 test machine which has no acceleration at all.

NickHope wrote on 10/27/2014, 12:46 AM

Thanks John. I'll submit a report to SCS.

NickHope wrote on 11/26/2014, 12:19 AM

VP13 build 428 still has this problem.

NickHope wrote on 11/30/2014, 12:03 AM

I have noticed that this seems to be a preview-only issue. The pale edges don't render out in Sony AVC or MC AVC with GPU rendering on or off, nor in non-GPU-accelerated AVI formats. This is a good thing that gives me more confidence to leave GPU acceleration on in the video preferences.

OldSmoke wrote on 11/30/2014, 9:07 PM

Nick

Does happen in your preview window or external monitor too? I am trying to find out if it happens in a scaled preview only or full size preview too and at what preview quality setting.

NickHope wrote on 12/30/2014, 10:24 PM

OldSmoke, sorry for the slow reply. I see it in the preview window and on the external monitor. It occurs at Best only, and it appears regardless of which size or whether it is zoomed. It looks worst at Best (Quarter).

I finally had a reply from SCS that bears this out. It included this:

"Firstly, thank you for your extremely detailed description of the problem, as well as for your example files. Looking at the files you provided, I can see that I do reproduce the issue in my own software. One interesting thing I noticed was that the pale edges only seem to occur when the preview quality is set to some flavor of "Best," regardless of whether it's Best (Full) or Best (Draft). When it's set to Good (Full) instead, the pale edges disappear. I will be escalating your report to our QA team for further investigation, but you may at least be able to use this preview quality change to work around the issue while leaving GPU-acceleration of video processing enabled."

NickHope wrote on 4/7/2015, 2:26 AM

VP13 build 444 still has this problem.

VEGAS_EricD wrote on 6/14/2016, 2:08 PM

Thank you for posting this issue. This is now listed in our known issue database.

We are reproducing the issue when "full resolution rendering quality" is set to Best. When using the Good setting we are not reproducing this issue.

From our documentation: Good uses bilinear scaling without integration, while Best uses bicubic scaling with integration. If you're using high-resolution stills (or video) that will be scaled down to the final output size, choosing Best can prevent artifacts.

Keep in mind choosing Best can dramatically increase rendering times.

Hope this helps.

VEGAS_EricD wrote on 6/15/2016, 3:15 PM

Just got some information back from the devs on this...

We recommend rendering using the "good" setting under these circumstances. As Best uses bicubic scaling, and attempts to make the edges appear crisp after resizing, even when no resizing is happening, as better interpolation when resizing is what bicubic scaling was intended to accomplish. As this is working as intended, it is not being identified as a bug.

winrockpost wrote on 6/15/2016, 4:11 PM

But what if it is a small section of the video ? The entire video would have to be rendered as good, I have always used best on all videos, should I use good , results will be as "good" as best ?
Oh and so nice to have a company guy actually on the forum ..thank you!

VEGAS_EricD wrote on 6/17/2016, 2:29 PM

In most cases good will be as high quality as best.

We recommend using the "best" setting in cases where you want to resize the video when rendering if you experience issues when rendering using the "good" setting, as the bicubic scaling + integration helps keep the image crisp and sharp.

farss wrote on 6/17/2016, 4:48 PM

[I]" As Best uses bicubic scaling, and attempts to make the edges appear crisp after resizing, even when no resizing is happening, as better interpolation when resizing is what bicubic scaling was intended to accomplish."[/I]

Except there is no edge in the final composite.

[I]"As this is working as intended, it is not being identified as a bug." [/I]

Perhaps it is working as someone writing code intended but it's not working as the user intended. To be blunt this "working as intended" excuse is pathetic and shouldn't be accepted by anyone.
Perhaps the developer writing the code did the best that could be done but if that's giving an outcome that the user did not intend then the issue needs to be escalated and seen as an architecture problem and fixed.
This is not the only problem noted with how Vegas does compositing, a rethink and redesign is probably in order.

Bob.

NickHope wrote on 6/18/2016, 9:27 AM

Thanks very much for your involvement and your reply Eric, however I'm rather confused by the conclusion that it's working as intended. Surely everything is intended to work the same with GPU acceleration on as it does with it off, except for the speed? The pale edges really don't make sense to me in this scenario at all. Basically Vegas is WYSIWYG with GPU off, but not with it on.

Grazie wrote on 6/18/2016, 10:59 AM

Nick, I've been here before with the User experience "experience" being offered by then, S Foundry, and then SCS. It's a journey by all parties concerned. When software is becoming unworkable, unwieldy, unimportant, irritating and non-responsive then it is already far too late for the s/w engineers to get involved. The accountants wouldn't allow it.

One of the starting points is to bring it front and centre here, exactly what you are doing here. It's what I've been doing for 14 years. So, keep the faith, and, respectfully, as you always are, keep questioning. And the cute thing is - it will keep VP alive and relevant for those engineers at MAGIX engaged.

G

OldSmoke wrote on 6/18/2016, 11:20 AM

I have two annoying issues with GPU acceleration too, especially with regards to AMD cards and VP13 build 453. Surprisingly, these don't appear in build 428 and not in the latest VP12 build 770.
One is track motion combined with Pan/Crop where the top track shows half video on one side, 960x1080 and the below track the full video, also 1920x1080 and when you play the video you will see the top track flickering. The workaround is the use a slightly different dimension, like 960x1080.01 and then it works.
Similar is the Bypass preview when selecting let or right half, the side that show the bypassed half will flicker.

NickHope wrote on 9/20/2016, 3:12 AM

This bug still exists in VEGAS Pro 14.0 (Build 161). I guess we will have to wait for an overhaul of the old GPU acceleration code before it will be addressed.

NickHope wrote on 3/29/2017, 10:33 AM

This is fixed in VP14 build 244. The release notes are here and I've tested it. Thanks Magix!