PNG/JPG Export Quality

[Ali1]

Hi

I am trying to export a png file from Designer, but unfortunately I am not getting the image quality to be what I expected. I am trying to create a sharp logo which can be used on website, social media etc.

I have set the resolution of the file to 300dpi and exported this by going to File>> Export....

I have kept the default settings before exporting this. However after exporting this the image just doesn't look as sharp and crisp as expected. I have attempted this with JPEG export also and ensured that the quality setting is set to 'Best Quality'. I have attached a screenshot of the export and also the resulting files in both PNG and JPEG. I have also attached a PDF version to compare.

When I compare this to PDF the PNG and JPG files are just not as sharp.

Can someone tell me if there is something I'm missing here to make the images sharper and look more like pdf ?

Thanks

Ali

 

 

Test Logo PDF.pdf

[Lee D]

When you're previewing the exported files, are you viewing them at 100% so they appear as designed?

[wonderings]

To get a clean png file I had to export it at 1200dpi. I did this from Illustrator. I then tried from Designer, I started with my document size and did not change the DPI, it was default set to 300. I placed the file and then went back and changed to 1200dpi, results were not go and did not match my Illustrator export with same document specs. I went back to Designer and started off correct this time with document size (which was the same as before) and changed from 300 DPI to 1200 DPI. This gave me results matching Illustrator, as it should. I find if you have to have text and convert to png, jpeg or any other like format you really need to boost the DPI to get clean results. 

[Pšenda]

On 4/20/2020 at 4:51 PM, Ali1 said:

When I compare this to PDF the PNG and JPG files are just not as sharp.

Yes, PDF text is still vector. 

[Lee D]

As @Pšenda indicates when exporting to PDF or SVG the text will most likely remain as vector, unless an effect has been applied. When previewed and zoom in it will look crisp, exporting to other formats such as JPEG or PNG will rasterise the text on export.

Can you confirm that you have setup your document size correctly so when exported and viewed at 100% this is the size you want to display it at. I would like to make sure as your project is 600x100px (pixels) this is the same as 5.08x0.85cm (centimetres). This is 100% and the size you should be viewing the file at and not zooming in at all, as this will distort the image.

I've attached a screenshot, I've set my document up in Designer at 600x100px inserted some text and then exported to PNG. The two previews below are the PNG file opened and viewed at 100%, the left is 300DPI the right is 96DPI.

[Ali1]

Hi Lee

Thanks for getting back to me.

I can confirm I have I have not zoomed in and I am viewing the file in its actual size (i.e. 100%). I have attached screenshot of how I have setup the document and the steps followed. Please see attached.

The screenshots attached are as follows:

1) How the file was setup - i.e. 600x100px at 300dpi

2)  How the file was exported in PNG format

3)  The result (in Mac Preview) as the actual size

4) I have attached the exported file also

As you can see in the exported PNG file (attached) - the edges of the text are a little bit rough and jagged.

I am assuming I have followed the steps you have suggested.

However the text in the exported file still dose not look as sharp as it should be.

Should I be trying something different?

Thanks

Ali

 

 

 

 

 

[R C-R]

5 hours ago, Ali1 said:

Should I be trying something different?

As long as you are exporting to JPEG or PNG (both raster image formats) at 600x100 px (which is the size including the white space around the rasterized text) & at any reasonable DPI, it won't matter much what you try -- there are just not going to be enough pixels in the rasterized image to display every letter crisply.

[Medical Officer Bones]

Some confusion regarding web resolution, PPI/DPI, how to prepare for the web, and such.

• DPI is completely irrelevant for web and screen (mobile/tablet/desktop) work. Forget about DPI or PPI. It tells nothing about the actual resolution of a file. 1 pixel can be saved at 50000ppi, and a million pixels at 1ppi. It is merely a parameter that tells print software at what relative size it should be printed.
   
• Technically DPI is the wrong term in Affinity's dialogs. PPI (Pixels Per Inch) is the correct term.
   
• For web/screen export, think PIXELS. When designing for screen output only pixels count. Forget PPI! Screen tech and software ignores that parameter.
   
• In the early BFP (Before Flat Panels) resolution of screens was more or less related to the size of those screens. The larger the CRT screen, the higher the possible resolution. 1 pixel equated to 1 pixel. I was very simple to calculate the required resolution/pixel dimensions of an asset for a web page: just export at the exact pixel size required.
  For example, if a logo had to be placed at 600px by 100px, that is what you exported and prepared it at. PPI was (and still is) entirely irrelevant.
   
• Things changed quite a bit AFP (After the introduction of flat screen technology). No longer can we relate the physical size of a screen to its physical pixel resolution.
  The first iPad had a 1024x768 resolution. The iPad 3 introduced the retina screen, which offers double that: 2048x1536. The screen size did, however, not change.
  Nowadays much smaller screens than an iPad screen are capable of displaying higher resolutions than that.
   
• Desktop screens display 4K or even 8K now, but the actual physical dimensions of those screens are similar or the same as the previous generations.
   
• This poses a problem to screen/web designers: at what pixel dimensions should assets be produced?
  To solve this problem the concept of MULTIPLIERS was introduced by screen designers.
   
• The multiplier tells the designer at what pixel dimensions a bitmap asset should be exported. The goal is to hit the native pixel resolution/dimensions for each targeted platform/screen (or close to that resolution).
  Example iPad 1: assets are exported at the native resolution (related to 1024x768 pixel screen). We prepare @1x: 600px by 100px.
  Example iPad >3: this is a device for which we prepare @2x assets: 1200px by 200px
  Result: we deliver two assets when our target platform is the regular iPad.
   
• For web export, at least @1x and @2x assets are required. When using the correct responsive <img> tag code, a browser will load up the correct version depending on whether the screen it is viewed at is retina or not.
  At this point the screen designer must realize that only providing a @1x asset will result in fuzzy looking bitmap graphics on a retina screen.
   
• But many handheld devices have far higher PPI resolutions (recall that PPI tells us about the relationship between the screen size and the native screen resolution). Very small screens at incredible high resolutions. @3x, @4x, and even @5x.
  How do we figure out the multipliers?
  Answer: we check the configurations, and calculate the multiplier. Luckily, someone already did this for us:
  https://material.io/resources/devices/
   
• This means that BEFORE designing any bitmap screen asset, the designer MUST decide what the highest target multiplier must be.
  And create the bitmap asset at that highest resolution.
   
• At this point a "pixel" as a unit is unsuitable as a base unit when discussing the dimensions of a bitmap asset. Therefore, DP and PT units were introduced. DP ("dip"(s)) is a Google coined 'unit'. PT (point(s)) is Apple's preferred 'unit'.
   
• Example: We need to prepare a 600px *100px bitmap asset. When we communicate this to our fellow designers and developers, we no longer use pixels, but either dips or points. 600dp/pt by 100dp/pt.
  Next, we must decide on the highest multiplier: with @3x we target most devices right now.
  We then define the highest resolution with the formula 3x600 and 3x100.
  We create a new document at 1800px by 300px, and work at this base resolution.
  This is required for all our assets in this project.
   
• When the final asset is to be delivered, export all multiplier versions with a standardized prefix or suffix which indicates the multiplier.
  In our example above, that means three bitmap assets: logo.png, logo@2x.png, logo@3x.png
  
   

 

[Medical Officer Bones]

Other recommendations:

• if possible, export as vector SVG files. In this case there is no need to worry about multipliers. Do make sure the SVG code is responsive, and automatically scales up and down in a HTML tag container.
   
• Even better, if you deal with GUI elements, work with the built-in framework GUI options. For example, instead of exporting that flat button design as a bitmap, use SVG. But if that same button design can be replicated using HTML and CSS styling code, definitely run with that last option.
  Built-in GUI components tops SVG which tops bitmaps.
   
• If it can be helped, never use JPG for sharp looking text, line art, logos, vector work, etc. JPG works well for photos and multi-tone images, but visibly degrades those aforementioned types of graphics due to the lossy compression algorithm
   
• Instead, use PNG. If your work consists of less than ~256 colours and tints, indexed PNG files are preferable and save file space. The best way to compress a PNG is worth an entire post by itself. Suffice to say, to best compress and optimize PNG files dedicated tools are required. Image editors are not that great at it. I use ColorQuantizer, which is (in my opinion) the best PNG optimization tool currently available. Only for Windows, though. But worth it and free! http://x128.ho.ua/color-quantizer.html
   
• WebP is also excellent for both photos as well as sharp non-lossy assets (WebP support both lossy and non-lossy), and supported by all major browsers now. Except, of course, Apple. Safari does not support it. 😞 Neither does Affinity, which only opens these files, but does not export to webp.

 

@Ali1 Your original issue has to do with attempting to export a 600x100 px asset "as is" from a vector package. In my experience there is just NO chance to get a good quality acceptable result, even in Illustrator. This is caused by a couple of things, such as non-decimal positioning, which adds unwanted soft anti-aliasing to the edges.

What works well to maintain high-quality sharp looking anti-aliased low resolution assets are the following steps:

1. work at a 3 to 4 times higher resolution.
2. export at that bitmap resolution.
3. Optional: perform some pre-downscale sharpening.
4. open the result in an image editor like Affinity Photo, and scale down to the required lower resolution.
5. Optional: perform some post-downscale sharpening.
6. the result will be much better looking.

Ideally use a downsampling algorithm such as Catmull-Rom. This works extremely well to maintain sharp details. Unfortunately, most image editors do not support this.

Of course, if you are already working at a @3x or @4x multiplier, the above steps generally are not required, because your base resolution is already very high. But it depends a bit on the image editor: the only way to check for quality is to go though the above steps at least one time, and compare your manually exported version with the automatic ones.

[Designer1]

@Lee DThe problem that Affinity Designer can not export sharp and especially smooth text to PNG, known for more than a year. Even free Inkscape exports significantly better PNG. It is simply incomprehensible why Affinity development team does not improve this. It is a basic requirement that PNG files are sharp and smooth!

[Pšenda]

https://forum.affinity.serif.com/index.php?/forum/52-feature-requests-suggestions/

[Fixx]

Can you tell which one is from Designer and which from AI?
 

 

 

[Designer1]

39 minutes ago, Fixx said:

Can you tell which one is from Designer and which from AI?
 

 

 

I think, the first is from Adobe and the second is from Affinity. Do you use Illustrator CC? On Windows 10, exported PNG from Designer are not good. Especially with blue colors.

[Suchjy]

1 year after and they still made anything with this