Skip to main content
E
Evilmurray
Participant
October 5, 2017
Answered

Artifact on export, black halo fringe along objects

  • October 5, 2017
  • 2 replies
  • 1539 views

I am editing a short clip featuring white text on red background. Exporting as mp4 (h.264) and some fake sharpening artifact appears in the finished file. Does not exist in the viewport. Background color in comp is set to red.

Any ideas? Tried all render-engines.

Se attatched screenshot. Top is text in viewport, bottom is text in exported clip. Looks like a fake-sharpening. No effects added in timeline or preprocessing added in export.

    This topic has been closed for replies.
    Correct answer Mylenium

    Well, bad news for you: You do everything wrong one possibly can. Using bright red backgrounds with compressed formats (and bright white text on top) is an absolute no-go simply because it constitutes the most unfavorable combination imaginable. The alleged shadow is a chroma-undersampling artifact inherent to most compressed formats plus the actual compression blocks makae it look even more pronounced plus the difference between white and red represents the steepest possible "knee", i.e. contrast threshold. That being the case you can try all the render engines in the world - it won't go away. Therefore the answer lies in adapting your design - use gradients instead of plain solid colors, use a desaturated red, possibly use fonts that result in a better distribution of the antialaising and compression artifacts. No magic answers here. You have to experiment and figure these things out.

    Mylenium

    2 replies

    M
    Mikey1001
    Participant
    October 21, 2021

    I opened a photoshop file I was having the same problem exporting with Affinity Designer 1.8.

    Photoshop export there is slight 1px halo around the whole thing.

    Affinity export using the same photoshop file. So, it's possible. Not sure why Adobe can't do it despite the compression artifacts mentioned in the other posts.

    Mylenium
    MyleniumCorrect answer
    Legend
    October 5, 2017

    Well, bad news for you: You do everything wrong one possibly can. Using bright red backgrounds with compressed formats (and bright white text on top) is an absolute no-go simply because it constitutes the most unfavorable combination imaginable. The alleged shadow is a chroma-undersampling artifact inherent to most compressed formats plus the actual compression blocks makae it look even more pronounced plus the difference between white and red represents the steepest possible "knee", i.e. contrast threshold. That being the case you can try all the render engines in the world - it won't go away. Therefore the answer lies in adapting your design - use gradients instead of plain solid colors, use a desaturated red, possibly use fonts that result in a better distribution of the antialaising and compression artifacts. No magic answers here. You have to experiment and figure these things out.

    Mylenium

    E
    EvilmurrayAuthor
    Participant
    October 5, 2017

    Thank you so much for your detailed explanation. BTW... Any ideas why it is more severe on the left side than the right side? If it’s a color contrast-thing, one is tempted to think the artifact would be similiar on both sides?

    R
    Community Expert
    Rick GerardCommunity Expert
    Community Expert
    October 5, 2017

    I wouldn't put too much stock on specific differences. Curvature of edges/ lines, small position shifts in antialiasing and a million factors contribute to this. Typically image data is left-aligned, anyway, meaning in a chroma-undersampled format such as JPEG or MPEG video the odds of one side falling into the undersampled "gaps" is always bigger than for the other, especially with comparably thin fonts such as you use it. You could shift your text by a fraction of a pixel to one side and the dark fringes suddenly appear stronger on the right side. Again, this is an inherent limitation of the formats and the only way to improve the outcome is to learn and practice things. The more often you do this, the better your gut feeling will work eventually.

    Mylenium


    Compression happens in blocks of 4, 8, 16 and 32 pixels. If a vertical line ends up in column 13 row 9 it's going to have different compression artifacts than a vertical line that starts in row 12 and 32. The ends will be different and the entire line will be different because one is lined up with the compression formula and the other is not. If you want to get real picky you'll design so everything that is a horizontal or vertical line lines up perfectly not only with the pixel grid but lines up in perfect multiples of 4. You'll also keep thin lines to a minimum thickness of 4 pixels. Diagonal lines and curves don't matter much, they are always going to look a little different when compressed. If you are not going to design to those specifications then the minimum line thickness for video should probably be 2 pixels. This will at least give you a fighting chance of having thin vertical detail against solid colors looking pretty good when the lines are animated.

    Fully saturated colors with the values spiked also do not give color compression much of a chance to work perfectly. If your values are 0 or 256 and the neighboring column or row is also all the way to 0 or 256 then there's no place to calculate an in-between. Red at 256 and white, which also has red at 256 leaves no room to average the colors between the lines. It's the same with Red against black. Red at 200 and white with Red Green and Blue at 200 gives the color compression algorithm much better chance to find a subtle color to fill the compression block with and edges and overall color will look much better.

      Terms & ConditionsAccessibility statement
      Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices