User_783649

Here the final proof:
Mac OS Preview App renders 10 bit depth, Affinity is limited to 8 bit depth 
 

 
filed a bug report:
 

Thanks for sharing, we had the same basic idea.
This file again confirms: Affinity is unable to render more than 8 bit color depth to the display in RGB/16 mode.
 
Using MacOS Preview App, I can clearly see the difference between 8 and 10 bit gradients. So my Display and OS works correct with this regard.

I believe we shouldn't mix those things.
8bit/10bit is viewing bit depth (between your GPU and display). It tells how smooth gradients will be as there will be more colors in 10bit mode because there are no longer 256 gradation steps but 1024.
Another thing is archiving bit depth (document mode). It may be RGB/8, RGB/16, RGB32, etc. It determines how color data will be stored in file when saved.
So we may find ourselves working with RGB/8 document on a 30bit display and we also may work with RGB/16 image on a cheap 6bit+FRC display which is barely reaches 24bit with frame rate control. 
As far as I know, Photoshop does support 30bit viewing mode. At least it does on my Mac system. Gradients are much smoother in this mode.
In case of macOS everyone can check if they're currently in 30bit mode system-wide or not.
Run the following command in Terminal:
/System/Library/Extensions/AppleGraphicsControl.kext/Contents/MacOS/AGDCDiagnose -a > AGDCDiagnose.txt 2>&1  Then go to your home folder and open text file AGDCDiagnose.txt, go to the end of file and try to find following strings:
Pixel Encoding    1 (RGB444)
Bits Per Color Component    4 (10 bpc)
That will tell you that system is currently using 10bits per channel. To double check that you can go to About This Mac -> System Report -> Graphics/Displays. You need to look for this line:
Framebuffer Depth:    30-Bit Color (ARGB2101010)

Thanks everyone for replying.
I think the original question was answered so maybe it'd be better to close the topic.
For the people that was making advices I just want to point out that the life and world is not black and white. I really excited watching for professionals around the world, I have friends in many countries all over the world. Also just to point out I'm Ukrainian by father (my father was born in Ukraine and I used to live in Ukraine 1/4 of my childhood). I love Ukraine as much as I love Russia. I study reasons of this conflict for more than 10 years, I was watching it with my eyes more than you think, I saw how it escalated, saw how it did grow. My grandmother lives in Ukraine, 4 years ago my grandfather from Ukraine passed away, many relatives (cousins, uncles), friends live in Ukraine, some of my cousins are now at war from Ukrainian side and some of my friends are from Russian side.
I didn't want to tell you anything about it because I started topic for another reason... But these comments... Many of commenters don't understand what really is happening here! This is a tragedy for all our people regardless of which side of the border one is on. So before judging please... at least please check out the history.
Not to offend anyone. Just... Just please know that we are suffering from this conflict alltogether. Russia and Ukraine for many Russians and Ukrainians are united. Some of us even don't see the difference, just artificial borders made someday by the politics.
I wish everyone to live in peace and stay safe. I'm grateful for your responses.
With love

Affinity Photo currently is the only app out of the three that is able to fully utilize GPU processing power as it manipulates raster image data.
Designer and Publisher, being vector based editors, don't use GPU that much and do most of its rendering exclusively on CPU.
Hopefully, more GPU acceleration will be introduced to these apps in order to give them a performance boost as well. However, we should remember, that vector and raster data are two completely different worlds. And if raster data, by its nature, greatly suits for highly-distributed parallel computation devices (which GPUs are), vector data is a completely another story.
So, choose a good GPU option if you're mostly work in Affinity Photo. You'll get a great performance boost.
And choose a good CPU with high single and multicore speeds if you find yourself more often working in Designer or Publisher.
Anyone can see how different these apps perform on a such basic operation as applying Gaussian Blur to an object and moving it around.
Designer and Publisher use almost all of the CPU while GPU is not being used at all.
And Photo uses lots of GPU while CPU usage is actually 3-4 times lower than Designer and Publisher.
CPU and GPU graphs are available on the screenshots below, as well as process %CPU usage in Activity Monitor.
System specs: Intel Core i9-9900K, AMD Radeon RX 580.
Designer:
Photo:
Publisher:
 

@walt.farrell It may look blurry if you're looking at the image preview in the forum's popup window. Try opening image in new tab so it appears at its real size.

Another important aspect to add:
Photo renders all documents in 8 bit color depth, except RGB/32.
This is ok for RGB/8, CMYK/8, GRAY/8.
This is a problem for RGB/16, LAB/16, GRAY/16: the rendering in photo creates banding of smooth gradients.
you cannot see if there is banding in the document documents without banding are rendered wrong For documents with banding, you are unable to smooth it (e.g. by a Gaussian blur filter), as the 8 bit rendering introduces new banding, see  and  and 

Additional examples where users were irritated by different export / rendering in Photo:
 

Currently, Affinity Photo does not provide a absolute trustworthy preview of the current document.
For any zoom levels not equal to 100%, you get misleading rendering of noise and unsharp mask filters With View Mode "Bilinear", you will always get false rendering on pixel level at hard edges Even with zoom level 100%, you could get get false rendering when dealing with pixel art For zoom level below 100%, you could get completely wrong colors caused by resampling (same bug report above) Many live filters can introduce rendering artifacts at any zoom level, including 100%, leading to severe deviations from final result, especially when combined with blend mode "difference" The false color by resample issue could bite you at almost any zoom level except 400% and integer multiples of 400%  
The only way to get a reliable preview of your document is to either
Export - leaving the application The Export Preview is cumbersome to use (modal windows, not able to use navigator panel) Merge visible - introducing superfluous temporary layers, must be created on top of layer stack and deleted after use. To overcome all these issues, it would be helpful if Photo would offer an "absolute trustworthy preview" move, similar to Designers View Modes.
Requirements:
No color artifacts (false colors) by resample in case of zoom <100% (use color-correct average, not false sub-sample) utilize full display color depth (10-bit, 12-bit, …) to avoid banding in case of 16-bit documents 100% accurate rendition of result ability to zoom to any level (at least -8x to + 8x) Ultimate priority on accuracy, no priority on performance. Options to deal with non-opaque pixels (color of matting background), switching options while in preview Regular keyboard shortcuts and mouse actions to zoom / pan

You may add your vote here 
 
 

I do totally agree with you, @Alex M.
If a bug is severer than another is depending on the work you are performing. Bugs or implementation flaws should ideally be fixed, if possible. It is somewhat pointless excusing bugs with bugs.
For me I took the decision to consider Affinity Designer or Publisher more often in the future.  
Regarding exports: If I am using a graphics app it should be as accurate as possible (it was called WYSIWIG some decades ago). How can I be sure upfront that export is working perfectly, when my original work looks clumsy? 
Renate.

It is only a temporary rendering issue inside the app - not affecting exports. There are much more (and more severe) rendering issues. If you merge visible, and zoom in 400% to 1000%, the rendering is correct!
 
PS:
Have a look at this file. It shows totally false colors while zooming.
 

@NotMyFault 
Finally! Thank you very much! Do you see how uneven the whole canvas is on two last screenshots you posted?
It doesn't look like Bilinear it's even worse, way worse I must say. That's what I'm talking about.
The problem persists for non-retina displays between 100% and 200%.

Here you go. Agree that there is the 1/2 resolution issue at certain places.
But I see this only in screenshots (not in real live).

 

Dear @Alex M
since you are also on 12.5 I do not have to downgrade to 12.4. 🧚‍♀️ That is the good news.
After all your detailed input I finally understood that AP Photo does not use the same text/font rendering concepts as Designer and Publisher. Your links to some other threads made it very clear to me.
I did check with integrated display only - as you recommended. Result: Basically the same issue as on the external display. But due to the very high resolution on a very small screen the rendering flaws are barely noticeable. Up to almost 300% zoom level the jagged edges are merely visible. Switching the external display to a lower resolution is not an option since the problem persists. 
Obviously it seems  that I have to live with Affinity Photo as it is right now. Anyway Photo, Designer and Publisher are very good tools being offered at a very reasonable price. 
Thanks a lot for explaining all the details. I think this thread can be closed, although we did not find an immediate solution. As you said it is the underlying concept of handling all layers as raster layers in Affinity Photo. Now I understand why you were interested in the layers I used in the document initially. It took me some more of your explanations to understand. Probably it was the same with 12.4 which I simply was not aware of. The graphics I was dealing with then had much focus on text elements.
Again thanks for your time, patience and effort - and excuse my stubbornness.
Renate.

@Being Frank 
I've inspected the document you posted here. 
The reason of the slowdown is Live Perspective filter being applied to a couple of groups in your layer stack.
These are known to be very resource consuming as they constantly re-render the canvas everytime you change anything or change the zoom level.
Once I hide those groups — zooming, panning around and all other actions are instant on my system.

@Being Frank 
I've inspected the document you posted here. 
The reason of the slowdown is Live Perspective filter being applied to a couple of groups in your layer stack.
These are known to be very resource consuming as they constantly re-render the canvas everytime you change anything or change the zoom level.
Once I hide those groups — zooming, panning around and all other actions are instant on my system.

@Being Frank 
I've inspected the document you posted here. 
The reason of the slowdown is Live Perspective filter being applied to a couple of groups in your layer stack.
These are known to be very resource consuming as they constantly re-render the canvas everytime you change anything or change the zoom level.
Once I hide those groups — zooming, panning around and all other actions are instant on my system.

@Being Frank 
I've inspected the document you posted here. 
The reason of the slowdown is Live Perspective filter being applied to a couple of groups in your layer stack.
These are known to be very resource consuming as they constantly re-render the canvas everytime you change anything or change the zoom level.
Once I hide those groups — zooming, panning around and all other actions are instant on my system.

@Hangman, I'll have a closer look on your post later, but here are some quick comments:
All the InDesign created PDFs that I had included were created in InDesign CS6. I use later versions only periodically and do not have currently subscription for ID on so I cannot check what kinds of changes there are in the latest version. But my point was in creating default PDF/X-based documents according to standards that CS6 version used (so I did not change the version numbers offered). InDesign supports PDF 1.3 (which Affinity apps do not), and PDF/X-standards with lower version numbers than Affinity apps (or pdfLib), e.g. PDF/X-1a:2001 and PDF/X3:2002, but I do not think that this is crucial. [EDIT: Sorry, my reply was more in general lines but, yes, you are correct, the default Press Quality in ID CS6 was for PDF 1.4, I wanted to use 1.3, instead to produce as basic plain CMYK as possible.]
It seems that Affinity apps fail a) with any non-PDF/X-based placed PDF that are exported using any PDF/X-based methods, and b) any placed PDFs that use version number later than the export file will be using.
This means that InDesign-created PDF v 1.3 device-CMYK PDFs (which should be the most fool-proof, basic print PDFs there can be, and should pass any old RIP software that exists in the world) fail with any PDF/X-based export methods (which are all post PDF 1.3, and therefore should not fail, according to Affinity "compatibility rules"). So the version number is not the issue here. Any Affinity created non-PDF/X-based PDFs, whether created in version 1.4 (lowest that Affinity apps support), or version 1.7 (latest that they support), will fail with PDF/X based Affinity created exports, as well.
These kinds of issues do not exist with Adobe apps or QuarkXPress. The mentioned "compatibility rules" only apply when using Affinity apps, and they make professional production quite complex if not impossible. As mentioned, InDesign and QuarkXPress can place any PDFs of any version in the document, and export them using any PDF export method, including ones that use lower version. In Affinity apps placed PDFs (to be passed through), are not converted nor are their features retained (e.g. embedded fonts are lost and rasterized). If they "conflict", the whole file is simply rasterized, which also means that colors will change. EDIT: The non-rasterizing alternative is to allow Affinity app to interpret the conflicting PDFs, which then introduces several other problems (the most serious being that embedded CMYK color profiles are not discarded, as they by default are e.g. when using InDesign, which results in translation of color values if the color profiles conflict -- again something that is typically not wanted when placing CMYK content: it is wanted to be passed through as it is).
I am not at all "against" using later PDF versions, or advocating device CMYK -- I responded only because there are known problems with Affinity apps in handling placed PDFs. PDF/X-based methods have initially been created to make production for press easier, but in context of Affinity apps they require knowledge of several pitfalls, something that most users do not have, and can seriously backfire.
In addition, I do not think that there is basically anything "old-fashioned" in keeping production methods simple, and in a way, in one's "own hands". In this respect, producing device-CMYK is fool-proof as it does not leave anything to be resolved on RIP. When working with InDesign, flattening of transparencies e.g. does not result in rasterization (as it always does when using Affinity apps), so there is no quality loss. It just saves time because you do not need to check these things from the ripped PDFs. It is also more or less fool-proof to produce along sRGB based workflow, as many big publishers marketing their services for general public do.
In this respect, producing using PDF/X-3 or PDF/X-4 (with embedded profiles and mixed color spaces) makes things more complex, especially in situations where apps (like Affinity apps) unnecessarily convert color spaces on export, and do not allow the user e.g. to specify whether transparencies should be resolved in RGB or CMYK color space. Things like these, in context of Affinity apps that allow creating complex non-destructive designs with stacked adjustments -- something that are supposed to be a forte -- are very error prone and likely to cause problems at least if they are left to be resolved at print time (on RIP).
As for the OP's problem, it might well be something that can be resolved by changing the export method. On the other hand, I have seen many posts where these kinds of issues could be resolved only by rasterizing on canvas or flattening at export time, i.e., making sure that all interacting layers use the same color space and leave nothing to be resolved at print time.
Here is a clip that demonstrates the compatibility "conflict". You should be able to reproduce this with any Affinity app. I think that compatibility rules are explained to some extent in the documentation, and also flagged in the internal preflight check (unless you have disabled the feature).

doyoufeelconfused.mp4  

Hi @lacerto, just to clarify a couple of things, does PDF (Press Quality) in Indesign not export PDF 1.4 files or has the standard changed with new releases of InDesign (I don't have access to InDesign so I can't check). I'm also assuming that you referring to PDF X-3:2002 rather than PDF X-3:2003 since I was of the impression the former exports PDF 1.3, the latter PDF 1.4 files? Just wanted to clarify supported features for each standard since there are subtle differences between PDF 1.3 and PDF 1.4 in terms of what is supported, not that this has any real impact with regards to the way the Affinity Apps are handling or rather appear to be incorrectly handling PDF Passthrough.
The Affinity suite appears to experience conflicts between different PDF versions, including different PDF/X versions which seem to emenate from the implementation of PDF Passthrough. My assumption (rightly or wrongly) is that these conflicts shouldn't exist and while the PDF formats themselves appear to export correctly individually, i.e., when not combined within the same document, the indications are that PDF 1.3 and 1.4 (no PDF/X standard files) are not compatible with PDF/X-4 files when using PDF Passthrough and likewise there appear to be compatibility issues between PDF/X-4 and PDF/X-3:2003 in Affinity apps, Publisher highlights these conflicts.

Is this PDF/X specific or an issue with Affinity App Passthrough? For example I can create a document (RGB or CMYK, it makes no difference) using both Spot and non Spot colour, both with Overprint set which when exported as individual PDF files from Affinity Designer or Publisher result in the correct output but when combined in a single document by placing the respective PDF files using PDF passthrough and then exporting to PDF using PDF 1.4 (No PDF/X standard), PDF/X-1a:2003, PDF/X-3:2003 and PDF/X-4) give differing results depending on which combination of PDF versions appear on the same PDF export...
Individual PDF Exports

Note how each PDF Export version exports the file correctly and shows the simulated Overprint in Acrobat Reader.
This I 100% agree with, any print job has to be produced in conjuction with the company printing the job and to their specific requirments or you're asking for trouble.
 
Individual Documents Above Combined in a Single Document Using PDF Passthrough

Note here the conflict between the Left and Right images and how the PDF 1.4 file conflicts with the PDF/X-4 file in both cases and how the CMYK (non-spot) versions in the bottom row of each file conflct between versions and how the PDF/X-1a:2003 export fails to show any CMYK or Spot Colour simulated Overprint regardless of the PDF version.
Then compare the image above with the same files exported while only showing one of the four placed PDF files and exported using the same four different PDF settings, the only difference here is the PDF 1.4 Export (No PDF/X) now shows the non-spot simulated colour Overprint but again the PDF/X-1a:2003 fails to exhibit the simulated Overprint when PDF Passthrough is applied despite the Overprint being shown for both Spot and Non-Spot colours when the file is exported without PDF Passthough as shown in the first image...

Agreed...
I've not experienced this, can you elaborate on the specific corruption you've experienced and what you mean by "the placed PDFs need to be produced in version lower or the same than the host document"?
Attached are the PDF files used in the images above. I don't currently have access to Acrobat Pro so I'd be interested to see whether the simulations shown in Acrobat Reader actually reflect the images shown above when the separations are viewed in Acrobat Pro?
Reading numerous posts dating back several years I get the impression that the Affinity App handling of PDF Passthrough is somewhat lacking, acknowleged by the Serif Team but yet to be fixed, I don't know if that is a fair assessment?
Source PDF Files
Circles CMYK X-4.pdfCircles CMYK X-3.pdfCircles CMYK X-1a.pdfCircles CMYK 1.4.pdf
 
Combined PDF Files
Circles PDF:X-4 Export.pdfCircles PDF:X-3 2003 Export.pdfCircles PDF:X-1a 2003 Export.pdfCircles PDF 1.4 Export.pdf
 
Individually Exported PDF Files from a Combined Placed PDF Document
Circles PDF:X-4 Only PT Export.pdfCircles PDF:X-3 2003 Only PT Export.pdfCircles PDF:X-1a 2003 Only PT Export.pdfCircles PDF 1.4 Only PT Export.pdf
 

There are other aspects than simplistic "the most recent is the best".
I have included here a PDF/X-4 export of a CMYK document where the underlying RGB color space of the document is sRGB and the CMYK target PSO Coated V3, and where four PDFs have been placed (that is, to be passed through), all produced in InDesign having Adobe RGB as the RGB color space and ISO Coated V2 as the CMYK color space. They were exported as PDF (Press Quality) = PDF 1.3 (no PDF/X standard), PDF X-1a:2001 (PDF 1.3), PDF X-3 (1.3), and PDF X-4 (1.6).
The correct behavior is shown in the attached InDesign exported PDF/X-4 document. However, when this job is exported from Affinity Publisher, it can be seen that a PDF that is not PDF/X-based (but plain and simple PDF 1.3 based device-CMYK document), has been rasterized (texts included), its overprint status of Y100 lost, and PANTONE color lost. This happens with all PDF/X-based production exports in Affinity apps, so it is clear that PDF/X-based export methods cannot be recommended without serious reservations. E.g. in professional use it is common to have third party ads and other documents (logos etc.) placed, and they often come produced in varied ways. Requiring that these kinds of documents need to be produced using a specific standard is absurd. Affinity apps have a unique PDF compatibility rule according to which the placed PDFs need to be produced in version lower than or the same as the host document will be exported (and not just PDF version number but also PDF-X version number; this means e.g. that if the host PDF needs to be exported using PDF/X-3 on printshop's requirement, not only non-PDF-X based but also all placed PDF/X-4 documents will be corrupt). This does not have anything to do with the producer of the PDFs so this happens also with Affinity-produced PDFs.
In practice the most robust export method when using Affinity apps is using PDF (for press) with PDF 1.7 (highest version available) and then uncheck profile embedding (embedding the profile will confuse e.g. Acrobat Pro and hide an overprint status of objects even if they have them; embedding a profile makes the document ICC-dependent and also requires selecting the correct simulation target in Acrobat Pro, another thing that confuses users, including those working at printshops, and causes color values to be shown incorrectly in PDF Output preview).
Affinity apps also always convert native objects (text and shapes) to CMYK color mode when exporting for press, even when using PDF/X-3 or PDF/X-4, which do not require conversion. Placed images in RGB color mode, however, are not converted unless forced. Effects not flattened might have RGB-based calculations applied. These kinds of factors are a reason for all kinds of confusions and problems, especially in context of objects with transparencies being in mixed color spaces and showing artifacts in diverse production stages (in exported PDFs, local prints, print proofs, etc.). 
Professional preflight software is often needed to be able to check that final print exports from Affinity apps are produced as required and behave as expected. This may become as a surprise for many who have previously been using Adobe apps or QuarkXPress, or other professional color managed software.
Another problem is that many large publishers that offer print services to general public, e.g. Amazon, may have strict specs for production. The instructions have often been created just for Adobe InDesign or QuarkXPress, or even for Word and Pages, and in this case be sRGB based. In practice many such big publishers simply just discard any embedded color profiles. In such situations it is clear that the best solution is to deliver a PDF that only has one color space, which means sRGB in RGB based workflow, and device-CMYK color space (normally produced for coated stock with around 300% TAC with profiles like US Web Coated, which is also the default in Affinity apps). Having ICC profiles embedded will not cause the desired effect in such production environment. In practice it is then often safest to produce a device-CMYK production file using a generic profile for the kind of stock that will be used on print.
Things like these explain why recommendations on creating device-CMYK production files keep on be given on this forum. Giving a generic recipe like "just use most advanced technology PDF/X-4", without consulting the printshop (or even against their recommendations), and without realizing or understanding the inherent problems with Affinity apps, is silly. It would be that also in context of Adobe apps and QuarkXPress, which can handle PDF production well no matter what kinds of placed documents are involved and what is required by the printer.
It does not much help that frustrated users blame such big operators as Amazon for bad co-operation and require them to change their production specs. Their workflows, preflight checks etc. may be old-fashioned and their technical support ignorant and naive, but if the users want their jobs be printed without surprises, it is best to adapt, or look for another printer.
pdf16_pdfx4_psocoated3_id.pdf
pdf16_pdfx4_psocoated3_apub.pdf
pdf17_pso3coated_apub.pdf
 

If I used iCloud and had a problem which took several hours to fix then I would stop using iCloud. For the record I use it for nothing. And I continuously check every few weeks to make sure that it hasn't turned on with various OS updates. I don't trust any of the various cloud services.

It seems like a lack of resampling after using the move tool is a critical feature to be missing?  After upscaling images, the result is very pixelated and should be resampled.  Leaving that step to the end when exporting doesn't give a very good impression of what the image will look like while working on it.

I considered the method of putting a layer into another document and resizing there, but that leads to horrible workflow + doesn't give reference to what size it should be, in relation to other objects.

And to the question of this whole topic. Is Affinity Designer even developed anymore?
My answer is yes. It definitely is.

And honestly, for the last years they’ve done inifinitely better job than Adobe.
With far less resources and marketing but with way more passion and dedication.
I see it and I feel it in their apps.

Serif took courage and had rewritten their apps from the ground up in order to make them better and faster.
I believe in this company. I believe in their team.