Affinity Photo changes image dpi on Copy & Paste

[McAvity]

Hi,
i'm quite new to Affinity Photo so probably i'm just to blind to see the answer or my mistake.
I opened a photo which has a resolution of 300dpi.
I selected a part of the image and used the function "New from Clipboard" (Strg + Alt + Shift + n).
When i check the document size the pasted image only has 96dpi.

Is this a desired behaviour or is it a bug?

Regards

Alex

Edited August 18, 2019 by McAvity

[R C-R]

15 hours ago, McAvity said:

Is this a desired behaviour or is it a bug?

I don't know if it is generally considered desired but it isn't a bug. It is just how the app works.

[McAvity]

Hi,

thank you for your reply.

I had been using GIMP (and Photoshop) quite a while before using Affinity Photo.
I just tested the same procedure with GIMP.
The pasted picture has a resolution of 300dpi.

I also did test to open a 300dpi image in Affinity Photo, made a selection, copied it and than pasted it into GIMP as a new picture. In GIMP the pasted picture has a resolution of 300dpi.

Does it make any sense that with Affinity Photo the resolution is dropped to 96dpi? Isn't this also a change of the "image quality"?

Regards

Alex

[mac_heibu]

35 minutes ago, McAvity said:

Does it make any sense that with Affinity Photo the resolution is dropped to 96dpi? Isn't this also a change of the "image quality"?

a) In my eyes it makes no sense at all. For a print designer the size information (per cm/inch, …) is vital and it really isn’t helpful to change the dpi setting with copy/paste.

b) Nevertheless your worries about „image quality“ are completely unnecessary:

Only the resolution (dpi) is modified, not the pixel dimensions, which (thank god!) remain the same. You can check this in the image size dialog. It you for instance use „cm“ as units (instead of pixels) and deselect the recalculation option you see, that the image size decreases/increases when you modify the dpi setting. So no quality degradation will take place, but simply a re-assignment of the amount of pixels per cm.

[McAvity]

@mac_heibu

So you would consider it as a bug?

Regards

Alex

[R C-R]

1 hour ago, McAvity said:

Does it make any sense that with Affinity Photo the resolution is dropped to 96dpi? Isn't this also a change of the "image quality"?

Whether it makes any sense is open to debate but it does not change the image quality in any way. "DPI" is not the same as pixel resolution -- DPI (dots per inch) is really just a loosely used term that refers to print resolution, but a printed "dot" can mean different things even in that context.

Likewise, "PPI" (pixels per inch) is also a loosely used term that can mean different things in different contexts, as is any term that includes a 'per' unit of physical measurement, be it inch, mm, or whatever. For example, PPI can refer to the physical pixel density (resolution) of a display device (the reciprocal of its dot or pixel pitch) or to the physical resolution of an image capture device (like a digital camera or a scanner).

Both DPI & PPI are often used to describe the resolution of a digital image file, but because the image in these files have no unique physical existence, neither use is technically correct. The only "real" resolution of these files are their pixel dimensions, & just to make things that much more confusing, pixels do not have to be square, so the width & height DPI/PPI values can be different.

Strictly speaking, in digital image files these DPI/PPI values are just metadata, which apps can use or ignore, for example when mapping the virtual pixels of a raster image to the physical pixels of a computer display.

EDIT: For more about quality vs. DPI, a good source of info is the Affinity Spotlight article "Understanding DPI." For a general discussion of the complexities, uses & misuses of the various terms, & why context matters (particularly in reference to image file formats) the Wikipedia "Pixel Density" article is a good source of info, if a bit technical.

Edited August 19, 2019 by R C-R
added more links

[mac_heibu]

Quote

So you would consider it as a bug?

No. A bug is a function, which doesn’t work as it is designed to work.

This issue works as designed, so it isn’t a bug.

Nevertheless in my eyes the „line break behaviour“ should be changed in future versions.

So, feel free, to post it in the „Feature Request“ section.