Poor quality when logo exported as PNG, SVG

[Brian_J]

To add to the previous 3 comments...

Horizontal and vertical lines will naturally look more crisp. It looks like 2 sides of the rectangle are aligned to pixels and two side are on pixel fractions, but it's not as noticeable as curved lines because the edges are horizontal/vertical... i.e., there's no stairstep anti-aliasing.

It's difficult for me to tell from the 200% screenshot how the graphic will look. I think your going to have to try nudging the entire logo, or individual elements, a fraction of a pixel to see if you can get it to look like you want. Or you may need to edit the paths of individual elements. There's probably not much you can do for the cursive text. I've had instances when dealing with small text where I put each letter on it's own layer so I could deal with kerning each letter manually by fractions of a pixel — I don't know if that's required for the sans serif font in your logo, but I'm just saying sometimes artwork needs to be tweaked differently for each size it's being saved at.

[Little Owl]

So why is my grey shape not clear when it's made with vector tools?

 

[NotMyFault]

1 minute ago, Little Owl said:

So why is my grey shape not clear when it's made with vector tools?

 

Because it is exported as raster  / bitmap format

[Little Owl]

4 minutes ago, NotMyFault said:

Because it is exported as raster  / bitmap format

But SVG export is vector, so I don't understand why my leaf elements in the design are not clear when exported as SVG?

The original reply I received was as follows - can anything mentioned here make a difference? 

" They are likely not pixel aligned.

View > View Mode > Pixels preview
You may also want to turn on pixels as document unit, Force pixel alignment snapping, use and snap to a 1-pixel subdivision grid, set Preferences > User Interface > Decimal Places > Pixels: 6 (to see the actual misaligned values in the Transform panel), etc. "

 

[Palatino]

27 minutes ago, Little Owl said:

But SVG export is vector, so I don't understand why my leaf elements in the design are not clear when exported as SVG?

What's wrong with that?

[Brian_J]

36 minutes ago, Little Owl said:

But SVG export is vector, so I don't understand why my leaf elements in the design are not clear when exported as SVG?

How are you viewing the SVG image? If it's in a web browser, anti-aliasing will occur, so you will see pixelation.

 

36 minutes ago, Little Owl said:

The original reply I received was as follows - can anything mentioned here make a difference? 

" They are likely not pixel aligned.

View > View Mode > Pixels preview
You may also want to turn on pixels as document unit, Force pixel alignment snapping, use and snap to a 1-pixel subdivision grid, set Preferences > User Interface > Decimal Places > Pixels: 6 (to see the actual misaligned values in the Transform panel), etc. "

All the things mentioned are factors to consider, but most of your logo artwork doesn't need to be pixel aligned (i.e., force pixel alignment). Pixel aligned means each edge is on a whole pixel — the text and leaves don't necessarily need to be aligned to whole pixels.

[Palatino]

Possible source of error - this selection would be wrong.

[Little Owl]

Brian - The logo is being used in email signatures & in a web site, so it has to be viewed in a web browser. SVG was designed for internet use so you would think it would be the bets option.

Palatino - at large size it looks fine - it's when used for a web logo that the client is seeing that it's pixelated - compared to an older logo she had elsewhere a few years ago -  that old one is clearer & it uses script style font & has very thin lines in the graphic component as well, so I don't see why my design isn't at least as clear as that one.

It's late night here in Australia so I have to sign off for now - I do appreciate all the advice from everyone, but it seems there is nothing I can do to fix it so I'm thinking I'll just refund the client the money & call it quits.   I don't know what else to do.

[Little Owl]

59 minutes ago, Palatino said:

Possible source of error - this selection would be wrong.

I had the export setting selected but also tried high quality but unfortunately it made no difference.

[deeds]

Anyone wanna try explaining the conversion process from vector TO bitmap?

That's what Little Owl needs. 

[Little Owl]

4 minutes ago, deeds said:

Anyone wanna try explaining the conversion process from vector TO bitmap?

That's what Little Owl needs. 

SVG is vector format so it's not converting a vector to a bitmap from my understanding when exporting as SVG, simply converting a vector to a different type of vector?

[Palatino]

20 minutes ago, Little Owl said:

SVG is vector format so it's not converting a vector to a bitmap from my understanding when exporting as SVG, simply converting a vector to a different type of vector?

Yes. Weren't you going to bed? 😉

[David in Яuislip]

The attached file, extension changed to avoid mangling by this site, is a screenshot of the svg @ 500% in Chrome, I don't have the Juliette font so Arial was substituted
First part is with text exported as curves and it's fine
Second is with text as text, note the jaggies on the slope of the M and the CLI
Third is the leaf which is also fine
So it's Chrome introducing the artefacts when rendering the text

The png jaggies are something else. Since changing to a retina screen I have noticed that images in Chrome are displayed larger than they should be. I can't find anything on the www about this so perhaps it's only me in the whole wide world but the screenshot below shows it

CurvesVtext.png.bluff

[Brian_J]

4 hours ago, Little Owl said:

SVG is vector format so it's not converting a vector to a bitmap from my understanding when exporting as SVG, simply converting a vector to a different type of vector?

Although SVG images are resolution-independent and can be scaled to any size without losing quality, they do have anti-aliasing when displayed on a web page, just like PNG and JPG — the difference is anti-aliasing on SVG images is done after the size is recalculated.

Think about fonts for a moment. Virtually all fonts are vector based. If you take a screenshot of a web page, paste it into Affinity Photo, and zoom in, you'll see anti-aliasing on the text. Just like with SVG images, fonts can be set to any size without losing quality... the anti-aliasing is done after the size is calculated.

Maybe the following graphics will be helpful.

These are two 16 x 16 px SVG icons displayed in a web browser. The image shows the icons at their original 16 x 16 px size. I took a screenshot, pasted into AP and zoomed in 800% and took a screenshot. Anti-aliasing is apparent when zoomed in. Notice the difference in appearance between the anti-aliasing on the horizontal and vertical lines in the gray icon on the left, and the curved edges of the green leaf on the right. 

Here are those same two icons scaled to 1024 x 1024 px.

The laptop / mobile phone icon has anti-aliasing on the rounded corners, but no anti-aliasing on the edges that I zoomed in on because they are aligned to whole pixels. Curves can't align to whole pixels along the entire length, so there is anti-aliasing.

Here's the leaf icon. At 100% size, it looks nice and crisp. But there is anti-aliasing, as can be seen by zooming in. The anti-aliasing on the leaf is more pronounced than in the laptop / mobile phone icon above because of the angle of the edges.

Some shapes are harder to work with at small sizes. Your logo just happens to have several things that I've found can present challenges at smaller sizes: thin cursive font, small leaf shapes with short curves and small gap in the middle, and the tagline (job title) which needs to be small so it doesn't dominate the logo, but small text in a logo is difficult.

Hopefully I didn't just rehash stuff you already know.

[Medical Officer Bones]

@Little Owl Does this version respect your expectations more? (download the PNG to check)

PS Real-time anti-aliasing of a SVG in a browser generally doesn't produce the same quality as a well-prepared bitmap version that is displayed at exactly 100%. In particular the horizontal leaf and thin lettering pay the price.

A higher quality anti-aliasing is often arrived at when a double resolution image is used and then scaled down. This accommodates retina screens and responsive layouts better as well. Browsers generally do a better job at anti-aliasing scaling down a bitmap image like this rather than displaying the SVG at lower resolutions.

Of course, if the generated PNG image already introduced sub-par anti-aliasing, the above point is moot.

For sharp-edged logo work like this one I prefer to export at a high resolution (~2000px or higher), then scale down to the required lower resolution with the CatmulRom resampling interpolation method. This particular method retains details better than the common interpolation methods and edges remain crisp looking.

(It is not supported by Affinity or Adobe products, however. I use Color Quantizer to perform this step and add a touch of pre-sharpening).

All that said, low resolution can only hold that much detail. If you need better definition, there is only one ultimate solution: edit the pixels and colours by hand like a pixel art artist. The third version above I manually edited the line as well as adjusted the colour of the thin lettering below the line, because the converted version introduced a too shallow gray. Subtle, but it looks better.

[v_kyr]

6 hours ago, Little Owl said:

SVG is vector format so it's not converting a vector to a bitmap from my understanding when exporting as SVG, simply converting a vector to a different type of vector?

Even SVG is first of all a plain vector format, it of course generally also offers to embbed raster image data on demand (where raster/bitmap data/images will then be embedded as a base64 data stream on such purposes).

Note that the Affinity SVG generator on certain usage workflows supports just (...aka can generate only) a limited SVG subset as output and so generates only simpler graphics types & filled shapes (like curves, lines, rects, circles, polygones, ...)  as plain SVG vector output. Other things which Affinity itself internally is dealing/keeping/applying as raster data, like for example most of the filter effects, won't be exported as plain SVG vector equivalents here, instead such graphics portions will then be exported as embedded base64 encoded raster/bitmap data into SVG files. - But here Affinity on it's SVG export panel at least (or usually) tells and shows if it can export all ( a whole doc/graphics as plain SVG via ... -> Raster DPI: (Nothing will be rasterized) ...) or not.

You can always also afterwards check the by Affinity generated SVG file contents and thus the generated SVG code inside, by using and opening it in some plain text editor, in order to see if the SVG file code portions do may contain some base64 image data stream portions or not. Aka if the SVG code contains plain vector data at all, or maybe also some embedded raster/bitmap data.

However, in your above shown logo graphics case, all should be exported as plain pure SVG vector commands here (...so there should be no embedded raster/image data at all in the generated SVG file). And thus any possible shown line jagging etc. will be more SVG preview tool based and dependend, so how any third party SVG preview tool (...like webbrowsers, SVG viewers etc.) do represent the SVG vector data then on screen themself. - Note that webbrowsers usually do have among the best SVG engines (SVG parsers) build-in and thus can show up SVG code quite well & good (Mozilla Firefox for example). Though sometimes some sort of in SVG files used/embedded fonts might not all always be ideal for all certain type of text sizes (how certain fonts scale when used in SVG code). So it often also depends on used fonts and the on websites used SVG showbox sizes here!

Your logo when previewed in FF looks Ok so far (...the fonts used here for me are Arial & Lucida Grande).

The exported/generated SVG code is all plain vector with a SVG 500x500 px viewbox ...

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE svg PUBLIC "-//W3C//DTD SVG 1.1//EN" "http://www.w3.org/Graphics/SVG/1.1/DTD/svg11.dtd">
<svg width="100%" height="100%" viewBox="0 0 500 500" version="1.1" xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" xml:space="preserve" xmlns:serif="http://www.serif.com/" style="fill-rule:evenodd;clip-rule:evenodd;stroke-linecap:round;stroke-linejoin:round;stroke-miterlimit:1.5;">
    <g transform="matrix(0.298977,0,0,0.298977,-112.569,-280.425)">
        <g transform="matrix(1,0,0,1,3.34473,-4.34473)">
            <path d="M951.306,1842.07L1738.71,1842.52L951.306,1842.07Z" style="fill:none;stroke:rgb(12,111,99);stroke-width:14.59px;"/>
        </g>
        <g transform="matrix(0.259061,0,0,0.259061,879.391,1718.82)">
            <text x="296.628px" y="761.363px" style="font-family:'ArialMT', 'Arial', sans-serif;font-size:254.313px;fill:rgb(128,128,128);">CLINICAL<tspan x="1431.97px 1502.63px " y="761.363px 761.363px "> P</tspan>SYCHOLOGY</text>
        </g>
        <g transform="matrix(1.45727,-0.147645,0.461198,1.4255,-159.82,853.118)">
            <text x="296.628px" y="761.363px" style="font-family:'LucidaGrande', 'Lucida Grande', sans-serif;font-weight:500;font-size:312.913px;fill:rgb(102,102,102);">M</text>
        </g>
        <g transform="matrix(1.46473,0,0.315157,1.46473,309.173,683.538)">
            <path d="M392.488,718.13C392.234,718.13 391.98,718.13 391.725,718.384C371.635,736.963 339.876,750.428 312.9,754.767C300.938,756.542 294.583,751.704 297.63,741.525C303.229,746.855 310.1,746.09 314.936,743.299C327.66,735.438 343.684,722.711 348.749,708.203C352.052,698.534 343.177,689.154 334.532,689.154C333.259,689.154 331.478,689.914 329.442,690.928C311.627,699.549 291.032,718.893 285.197,738.23C280.114,754.767 296.105,765.925 310.864,765.925C333.514,765.925 383.587,742.538 392.743,719.657C393.251,718.639 392.997,718.13 392.488,718.13ZM301.447,732.384C305.774,722.711 321.298,709.221 331.987,702.604C337.586,699.295 345.71,695.745 339.367,706.676C333.514,716.094 315.699,730.602 308.573,734.42C302.72,737.723 299.411,737.47 301.447,732.384Z" style="fill:rgb(102,102,102);fill-rule:nonzero;"/>
            <path d="M530.579,530.97C531.852,523.341 527.02,512.152 518.121,512.152C505.662,512.152 493.712,523.595 485.322,532.495C454.048,566.569 431.928,608.78 413.368,652.008C400.655,681.759 383.11,722.19 388.451,753.975C391.248,771.52 415.402,783.218 430.911,776.606C453.031,767.452 481.254,739.989 492.441,719.647C492.949,718.884 492.695,718.121 492.187,718.121C491.678,718.121 491.678,718.121 491.17,718.375C474.897,733.378 442.353,765.163 420.741,769.232C407.774,771.775 399.892,764.4 399.129,746.855C398.621,735.158 402.181,717.358 405.486,705.407C445.658,664.722 523.714,579.537 530.579,530.97ZM494.221,540.632C516.849,516.221 530.579,511.643 519.138,541.395C498.797,593.014 452.777,635.988 416.165,676.673C435.996,629.377 459.896,577.757 494.221,540.632Z" style="fill:rgb(102,102,102);fill-rule:nonzero;"/>
            <path d="M558.809,719.545C559.318,718.779 559.063,718.013 558.555,718.013C558.3,718.013 558.046,718.269 557.792,718.524C548.128,727.457 524.222,744.048 507.458,751.96C500.071,755.527 494.723,756.289 495.231,749.152C495.74,737.411 509.496,704.231 516.347,694.787C518.373,692.235 515.34,687.64 512.044,685.598C506.185,682.287 504.911,686.364 502.109,692.745C493.962,709.846 478.986,736.39 480.004,755.781C480.257,762.633 491.931,769.739 498.542,769.739C511.534,769.739 553.977,732.051 558.809,719.545ZM524.985,664.231C521.171,664.231 516.598,668.3 514.837,673.132C513.063,678.218 514.837,682.287 518.373,682.287C522.188,682.287 526.765,678.218 528.546,673.132C530.326,668.3 528.8,664.231 524.985,664.231Z" style="fill:rgb(102,102,102);fill-rule:nonzero;"/>
            <path d="M643.749,718.135C643.241,718.135 642.986,718.389 642.478,718.389C633.068,722.207 613.995,729.589 602.325,730.861C607.908,720.935 613.74,705.918 612.723,694.209C611.963,685.593 602.325,685.085 596.462,688.888C593.148,691.166 590.344,693.955 587.807,697.518C584.509,694.718 582.479,694.464 579.688,695.482C562.123,702.354 540.784,735.935 543.073,754.248C544.088,762.131 552.969,769.739 562.378,769.739C571.802,769.739 584.001,757.817 593.913,744.054C596.462,744.054 598.756,743.8 601.306,743.039C610.442,739.994 637.9,727.298 643.749,719.662C644.512,718.389 644.258,718.135 643.749,718.135ZM575.114,751.7C564.67,759.849 553.73,763.907 557.793,744.563C560.085,734.667 567.217,719.662 580.196,712.281C576.642,722.207 574.095,735.428 585.016,741.77C581.972,745.328 578.673,748.896 575.114,751.7ZM593.403,729.079C589.583,726.025 589.836,719.153 591.363,713.299C593.148,705.918 598.246,697.518 603.6,693.191C602.835,707.699 600.541,716.608 593.403,729.079Z" style="fill:rgb(102,102,102);fill-rule:nonzero;"/>
            <path d="M659.04,699.045C660.312,696.245 649.63,692.686 647.596,697.518C642.255,710.754 626.488,749.649 623.436,758.549C620.639,766.942 626.742,769.739 630.048,771.011C633.354,772.282 635.643,770.502 636.66,767.705C643.527,748.631 655.316,702.609 672.863,693.954C672.863,693.954 675.4,718.136 676.415,725.009C677.938,733.384 686.564,738.713 694.448,734.904C698.517,733.131 708.181,722.972 709.707,719.663C710.216,718.645 709.707,718.136 709.198,718.136C707.927,718.136 706.91,719.154 706.147,719.663C703.603,721.7 700.552,724.754 697.754,726.536C694.194,729.079 691.651,729.585 690.125,726.791C687.582,722.463 686.819,699.3 686.31,693.447C685.295,684.825 678.952,680.253 671.083,684.318C652.01,694.718 659.04,699.045 659.04,699.045Z" style="fill:rgb(102,102,102);fill-rule:nonzero;"/>
            <g transform="matrix(1,0,5.55112e-17,1,-22.5297,0)">
                <path d="M851.014,718.125C850.76,718.125 850.506,718.379 850.252,718.634C838.299,729.575 804.984,751.967 789.979,755.783C779.044,758.831 775.23,755.274 775.738,748.15C776.501,736.954 784.639,725.249 790.997,716.598C793.794,712.527 792.014,709.982 787.436,708.965C789.725,702.349 784.384,688.391 772.693,688.391C765.843,688.391 759.236,690.419 753.38,694.221C736.323,704.893 718.804,730.847 720.075,751.712C720.582,758.579 728.193,769.739 736.068,769.739C747.525,769.739 758.981,748.404 764.32,736.954C763.052,740.516 762.29,744.333 762.037,748.15C761.782,757.562 770.917,769.739 780.315,769.739C792.268,769.739 811.596,758.831 821.768,751.203C833.976,742.043 847.454,729.575 851.269,719.652C851.777,718.888 851.523,718.125 851.014,718.125ZM745.997,751.966C737.086,760.862 731.492,759.34 733.268,746.368C736.068,727.539 751.344,704.893 769.648,699.041C776.755,696.502 781.587,698.277 780.061,703.621C778.281,711.509 754.399,743.824 745.997,751.966Z" style="fill:rgb(102,102,102);fill-rule:nonzero;"/>
            </g>
        </g>
        <g transform="matrix(0.702536,0,0,0.778898,423.732,406.314)">
            <path d="M1876.5,1848.96C1862.58,1847.03 1872.79,1833.22 1877.35,1827.6C1891.8,1809.79 1911.87,1793.18 1932.75,1783.39C1969.38,1766.23 2015.05,1778.61 2051.44,1790.21C2060.96,1793.25 2076.27,1800.09 2087.92,1801.74C2114.01,1805.43 2140.82,1803.28 2167.07,1805.55C2172.61,1806.03 2178.12,1806.92 2183.59,1807.99C2184.7,1808.2 2194.94,1810.05 2193.59,1814.41C2190.42,1824.66 2178.39,1829.14 2170.23,1833.95C2148.83,1846.56 2148.38,1848.1 2125.12,1857.07C2075.17,1876.35 2017.93,1875.65 1965.84,1867.29C1955.57,1865.65 1886.81,1850.39 1876.5,1848.96Z" style="fill:rgb(12,111,99);"/>
        </g>
        <g transform="matrix(0.291707,0.283699,0.522224,-0.536966,274.855,2301.61)">
            <path d="M1876.5,1848.96C1862.58,1847.03 1872.79,1833.22 1877.35,1827.6C1891.8,1809.79 1911.87,1793.18 1932.75,1783.39C1969.38,1766.23 2015.05,1778.61 2051.44,1790.21C2060.96,1793.25 2076.27,1800.09 2087.92,1801.74C2114.01,1805.43 2140.82,1803.28 2167.07,1805.55C2172.61,1806.03 2178.12,1806.92 2183.59,1807.99C2184.7,1808.2 2194.94,1810.05 2193.59,1814.41C2190.42,1824.66 2178.39,1829.14 2170.23,1833.95C2148.83,1846.56 2148.38,1848.1 2125.12,1857.07C2075.17,1876.35 2017.93,1875.65 1965.84,1867.29C1955.57,1865.65 1886.81,1850.39 1876.5,1848.96Z" style="fill:rgb(12,111,99);"/>
        </g>
    </g>
    <g transform="matrix(0.285529,-0.0886604,-0.0886604,-0.285529,-7.37032,679.107)">
        <path d="M1741.99,892.311C1768.12,898.764 1795.91,899.063 1821.07,888.568C1840.56,880.438 1859.2,868.41 1879.59,862.282C1899.23,856.382 1914.75,852.721 1934.73,850.096C1940.07,849.394 1945.47,848.976 1950.86,848.923C1952.73,848.905 1958.19,849.442 1956.38,849.886C1948.98,851.696 1941.25,851.809 1933.74,853.109C1917.66,855.891 1902.39,859.459 1886.89,864.685C1858.05,874.403 1833.14,894.321 1803.74,901.924C1784.03,907.02 1763.72,904.3 1744.16,899.313C1741.26,898.573 1737.31,897.167 1737.77,893.621C1738.03,891.549 1741.99,892.311 1741.99,892.311Z" style="fill:white;"/>
    </g>
    <g transform="matrix(0.0407817,0.137001,-0.218301,0.0649825,548.653,-20.8896)">
        <path d="M1740.96,885.272C1767.09,891.724 1797.7,895.289 1822.86,884.794C1842.35,876.664 1861.59,863.377 1881.98,857.249C1901.61,851.349 1923.44,843.801 1950.86,848.923C1952.65,849.258 1958.19,849.442 1956.38,849.886C1948.98,851.696 1932.27,845.381 1889.27,859.653C1860.34,869.256 1834.93,890.547 1805.53,898.15C1785.82,903.246 1754.36,896.859 1734.8,891.872C1731.9,891.133 1740.96,885.272 1740.96,885.272Z" style="fill:white;"/>
    </g>
</svg>

 

[Little Owl]

4 hours ago, Medical Officer Bones said:

@Little Owl Does this version respect your expectations more? (download the PNG to check)

PS Real-time anti-aliasing of a SVG in a browser generally doesn't produce the same quality as a well-prepared bitmap version that is displayed at exactly 100%. In particular the horizontal leaf and thin lettering pay the price.

A higher quality anti-aliasing is often arrived at when a double resolution image is used and then scaled down. This accommodates retina screens and responsive layouts better as well. Browsers generally do a better job at anti-aliasing scaling down a bitmap image like this rather than displaying the SVG at lower resolutions.

Of course, if the generated PNG image already introduced sub-par anti-aliasing, the above point is moot.

For sharp-edged logo work like this one I prefer to export at a high resolution (~2000px or higher), then scale down to the required lower resolution with the CatmulRom resampling interpolation method. This particular method retains details better than the common interpolation methods and edges remain crisp looking.

(It is not supported by Affinity or Adobe products, however. I use Color Quantizer to perform this step and add a touch of pre-sharpening).

All that said, low resolution can only hold that much detail. If you need better definition, there is only one ultimate solution: edit the pixels and colours by hand like a pixel art artist. The third version above I manually edited the line as well as adjusted the colour of the thin lettering below the line, because the converted version introduced a too shallow gray. Subtle, but it looks better.

Yes, it looks sharper - thank you.  Did you achieve that in Affinity or with Color Quantizer?
I tried editing pixels but it didn't work - I ended up with blocky edges instead. If you could share your process I'd appreciate it.

 

[Little Owl]

Medical Officer Bones - hope you can reply as per my question above?   

[Medical Officer Bones]

Apologies - I was busy finishing up a client project. No forum time!

The steps are quite simple:

(1) export the logo as a 2000px PNG with transparency from Affinity Photo or Designer.

(2) drag and drop the PNG file on Color Quantizer
http://x128.ho.ua/color-quantizer.html (no installation required: just unzip the executable to your desktop, and drag files on the icon or in the window).

(3) Trim the transparent background (optional step, but it is generally preferable to adjust image margins or padding in code)

(4) Zoom in a few times in order to check the result on a pixel level. Scale down to the required size. Choose Catrom for the resampling method. Applying a degree of presharpening and postsharpening may help introduce more perceptible sharpness in the edges (do not overdo this: in particular an overdone post sharpening looks quite horrid).

(5) Save the result as a PNG (click the floppy disk icon).

(6) Open in Affinity Photo. Delete one or two of the soft anti-aliased pixel rows with a rectangular marquee selection.

Next, select the thin lettering with a rectangular marquee and apply a curve adjustment to increase the contrast of the too shallow grey lettering:

PS when adjusting pixels always ALWAYS open a second view to preview the work at true scale. (A throwback to Deluxe Paint times on the Amiga   )

(7) if anything else seems out of order, edit the pixels as required.

(8) export as PNG. Consider saving as an indexed 256 colour version which will save a few kilobytes.*
But I am a purist and pixel heckler, so you may not want to go that far.

(Indeed, I reopened the result in Color Quantizer and performed this last optimization step there. It does a better job than a typical image editor like Affinity Photo.)

That's it.

* I encountered a bug(?) in Photo 2: when I activate "Palettised" the result is... empty! Also, why on Earth does the export insist on scaling the preview to the full window size? Worse, why is bilinear filtering applied to the preview? That filtering renders the preview useless for its intended job! That export window is not ready for production - not even at MVP1 level, in my opinion.

 

PPS I also tested this just now in PhotoLine (which also support CatmulRom downsampling). I get an even better result without the need to adjust the horizontal line and the thin lettering looks quite a bit crisper and defined. PhotoLine seems to respect the pixels better. And surprisingly no need for Color Quantizer in this particular case.

Huh. I did not expect this result.

[Little Owl]

Thanks heaps - I'll give that a go tomorrow as end of the day here in Australia.

 

[Medical Officer Bones]

Yes, here on the West Coast of Canada it's after midnight. Time to catch some Zs.

[NotMyFault]

You can improve the readability of small fonts dramatically by adding a simple curves adjustment on alpha.

The issue has one symptom: alpha is reduced for small letters / thin lines, does not reach 100%. This leads to very low contrast.

The curves adjustment must be put in masking position to affect the alpha channel.

Another method is to tweak anti-aliasing / coverage map. Unfortunately this is unavailable on iPad, and buggy on Desktop (adding nodes on curve will impact curve output)

changes curve 

[loukash]

Also:

• When working and thus exporting into the pixel domain, use strictly pixel units for all objects, incl. font size and stroke width. Unless @72 DPI working document resolution where 1pt = 1px anyway.
• Set Preferences > User Interface > Decimal Places > Pixel to "6". So that you always see in the panels if an object is misaligned or has a non-integer width or height. (Common misunderstanding: This setting only affects the display of decimal places, in does not round values up or down!)
• Always work with View > View Mode > Pixels on.
• Set up a pixel grid and snap to it. My ideal setting: Basic mode, Spacing 8 px, Divisions 8. (In the digital domain, the math is based on the hexadecimal system, not the decimal system. So you definitely want to prefer basic grid values like 4, 8, 16, 32, 64 etc., anything that you can always divide by 2.)

[debraspicher]

Without any manual hinting, Coverage Map in Layer Options can be used to adjust anti-aliasing so it reads thicker for thin weight typefaces. Just a thought. Others posted adjustment of curves which would help also, but Coverage Map is likely designed with this purpose in mind.

 

There's no target size in the thread so I just used the original file and moved to a new art board (460px x 180px). It is critical to know dimensions before working.

Original:

1. Change Arial to 20px (whole pixels) and nudge to grid... Arial was initially set to 19.7px. For screen, text must be set to whole pixels to allow the fonts to hint to screen as it was intended by the person who designed the font. A decimal really throws that off.

2.  Add Blend Options>Coverage map to 'eliora' and the "Clinical psychology" type to help them read clearer/thicker. I did a quick adjustment, but I suggest to play with it to get the results you prefer. I adjusted Arial as well though with a different setting than the 'eliora'. Save these profiles after setting if you want to test the same curves across the document.

 

Result:

3. Fixed the green stroke. It was actually dipping by .1px on the right downard which caused an anti-aliasing band along the entire line. Very sad. Changed it from 4.4px width to 4px. Then I aligned this to pixel grid so no more anti-aliasing. Result:

4. Manual hinting of type in the 'eliora' by nudging points (set to .1px with arrow keys in preferences in this case). This is just a demonstration. I explain in the end what is involved, but this is very much a person-to-person matter of how things should be changed. (I might've readjusted Arial Coverage Map again after adjustment, I don't remember...)

5. Hinting of the leaf. Same method as above.

6.  Adjusted leaf highlights (a little). Same method.

Notes: Thin weight fonts and cursives DO NOT hint well at small sizes. It doesn't mean don't use them, just be aware of this. Some fonts are not hinted for paragraph text either, so try to keep in mind the intentions of the person who designed it. Also, sometimes the font ITSELF is "flawed" or poorly done and the designer did not correct for hinting at certain sizes. You'll notice it after a while when you make adjustments to different scales and it drives you nuts on export. It is helpful to have a set of fonts you prefer with various weights of high quality when working small scale. That way when making really small graphics in this case, it's possible to replace the weight with the next up (not much heavier) to help with legibility on screens. Also, being able to change the weight helps a lot when your background is black, for instance. That can help avoid a lot of headache with good planning.

The workaround when we are working with difficult type at small sizes is to use Coverage map to give the illusion of extra clarity. My examples could probably be adjusted to however you prefer, but it's not always necessary to do copious amounts of manual hinting work. What's important is to set your grid up in advance, know your dimensions and set your artwork approximately where it needs to be. It's not necessary to move every point to whole pixels, but I try to setup grid lines where lines match up (vertically) and then along the baseline of the type, the x-height, ascenders, descenders, etc... That way, there's a common horizontal element that helps with legibility and consistency. Like so...

 

 

When hinting artwork such as the leaf, I hold "Alt" with the node tool to avoid snapping behavior when adjusting points, and hold "Shift" when adjusting curve/handles to maintain the integrity of the original piece. If the point is slightly off of a whole pixel on the very ends of things (like very bottom of the leaf), move it to the next relevant pixel so that it creates a baseline. That will clarify. If it's disrupting the artwork, then just nudge. It's not an exact science, it's more of an art.

Edit: Another important note, make sure your artboards are pixel aligned. Yes. Edit2: Never use odd number dimensions for artboards/images unless specifically asked. Try to use numbers that round well up and down in the event your work should need to be scaled again in a browser, for instance, it'll have an easier time with it.

I wish Affinity had something like this in PS, but we seem to be able to mimic it fine with Coverage Map. This guy here:

More details regarding Coverage Map & Anti-aliasing (timestamped)

 

[NotMyFault]

10 hours ago, debraspicher said:

Others posted adjustment of curves which would help also, but Coverage Map is likely designed with this purpose in mind.

Well, i proposed both options in one post and gave the constraints:

https://forum.affinity.serif.com/index.php?/topic/175883-poor-quality-when-logo-exported-as-png-svg/&do=findComment&comment=1015025

1. coverage maps are unavailable on iPad
2. Coverage maps have an unfixed bug which is even visible in the tutorial video you linked at timecode 09:03-09:04. play starting about 09:00. The instant second James is adding a node at the coverage map, the anti-aliasing rendering changes - even if the node stays at the default position. It is expected that the rendering changes if the node is moved to a different place. But if the node is just created on the existing linear curve, it is a bug. I assume it is wrong / superfluous gamma correction. The coverage map UI is “re-used” from brush pressure profile (saved profiles even showed up there), and there it works on RGB channels, not on alpha specifically.