James Ritson

What Gabe said is technically correct, it just doesn't happen destructively—any embedded documents/placed images are converted to the source colour profile of the parent document for presentation. They have to be, otherwise the colours would be incorrect. Internally, though, the documents/images retain their original colour profile and format, which can be verified by using Edit Document from the context toolbar (or double-clicking the layer with the Move Tool selected). The same applies to image formats like JPEG/TIFF, etc. There's a slight difference between Affinity documents (embedded documents) and placed images: embedded documents are always converted on-the-fly, whereas with placed images a cached result is generated and stored in the document file and is updated when the image is replaced. The benefit here is that if you go through multiple colour format/profile conversions, Photo will convert from the original document/image profile and format each time rather than having it go through several conversions. So for the benefit of clarification, you might be able to technically have RGB layers (specifically, embedded documents and placed images) within a CMYK document, but you cannot avoid the colour conversion that is performed to ensure those layers display correctly. Outside of embedded/placed layers, you cannot have an RGB layer in a CMYK document and vice versa. Copy-pasting image or document data in rather than placing it will convert it to the document's colour profile.

Hi Margaret, it's been mentioned above as a bug in the current Windows Photo beta—it's pretty high priority so should be fixed soon. The two options are to go back to 1.6, or once you've developed your image just use Document>Assign ICC Profile. You're correct that you shouldn't have to do it, but it is a bug and should be temporary (perhaps even fixed in the next beta) From what I can gather her issue isn't the dreaded "white is yellow" that you get with defective display profiles—she's using the most recent Photo beta for Windows which incorrectly assigns a linear colour profile to the document rather than a non-linear gamma corrected one (causing the entire document to render incorrectly).

Thanks, didn’t catch that as I typically use the Mac betas. In that case, I would either revert to 1.6 or if you want to continue to take advantage of 1.7’s improvements just assign a non-linear version of the same profile after developing. I might still recommend a Ctrl-run up as there is mention of the Windows-specific wsRGB profile being used for the document which is a bit suspect...

Hi Jim, just to clarify this (I've replied to that thread you've linked), the "whites appearing yellow" issue is related to defective display profiles—usually profiles for specific monitors or laptop displays that are applied by default. Really, the manufacturers should stop providing these profiles because they don't work properly with colour managed applications. Affinity Photo is not duplicating Windows's own colour management.. A quick search will turn up various threads demonstrating that the issue affects Photoshop too (which is also colour managed), for example: https://forums.adobe.com/thread/2201870 https://forums.adobe.com/thread/1042198 Unfortunately, fixing the issue completely is expensive: ideally you need to purchase and use a colorimeter to profile your monitor or display. Colour managed applications can then use this to translate the document's colour values to the display accurately. Changing the display profile to the sRGB device profile is just a temporary fix for a defective display profile, but for general purpose editing it's a satisfactory solution. Hi Margaret, I've downloaded the .afphoto file you've provided and to be honest I would recommend doing a complete app settings reset. Somehow, you've managed to end up working in 16-bit but with a linear colour profile. Notice with DSC_4547.afphoto the colour profile says sRGB IEC61966-2.1 (Linear) — linear profiles should be reserved for 32-bit documents. Affinity Photo will only handle non-linear profiles with 8/16-bit documents. I'm not even sure how you managed to mix the two, since linear profiles are not usually available in 8/16-bit and vice versa. Before resetting, would it be possible to screen grab your colour settings? You can find them under Preferences>Colour. Based on this: I suspect you may have changed your default colour settings and somehow ended up mixing a linear colour profile into a non-linear document. The best thing to do would be to launch Affinity Photo then immediately hold Ctrl. You should have a dialog box pop up with a series of checkboxes. Click "Select All" at the bottom then click Clear. This should reset all your colour settings and anything else besides. Now try loading in a RAW file and developing it without any further adjustments—does the issue disappear? If you have any current images or documents affected by this, you should be able to fix them by going to Document>Assign ICC Profile and just choosing sRGB (make sure it doesn't have Linear after the profile name). Thanks and hope to hear back from you!

Yes, in theory it shouldn't be a problem—I'm just basing the answer from my experience at the time having used i1Profiler to generate v4 profiles. I'll edit my post for clarity. There shouldn't be an issue using v4 profiles, but we can't speak for other software that may use different CMS solutions.

Hi Kerwin, welcome to the murky world of display profiling and colour management Are you using i1 Profiler or something similar? (I believe the ColorMunki software might be the same, just rebranded). I don't use it any more (I use displayCal instead which only generates v2 profiles) but Affinity Photo's colour management system should handle v4 profiles just fine. Just make sure your custom profile is loaded within the Windows colour management system and that's it. The Affinity apps will automatically colour manage from your document profile to display profile. The only caveat I would mention is if you were switching between different profiles for whatever reason (perhaps comparing D65 to D55)—whereas on macOS the document view will change accurately, it's been my experience on Windows that you should restart the Affinity apps between display profile changes to ensure everything works as expected. You don't need to worry about this if you're only ever using one profile though. Yes, the Affinity apps are fully colour managed—we use our own solution to manage the document view or "canvas" as it's called, so it goes from your current document's colour profile to the display profile. The UI is also colour managed, but I believe Windows handles that area. [Edit] Here's a tldr for brevity: calibrate then profile your monitor, then make sure that profile is loaded within the Windows colour management (the profiler software should take care of this). Run the Affinity apps and everything will be colour managed without any intervention required. Hope that helps!

Hi @Jim Weigang, I’ve gone away to gather my thoughts on this and carried out some experiments. I’ll try and address everything as concisely as I can, so apologies if it becomes a wall of text. Just to qualify everything that follows, I too calibrate and profile my monitor (a Dell UP3216Q) with an i1 Display Pro and displayCal, and for this research I’ve profiled both to my usual D65 100cd/m2 setup and to the specific sRGB preset provided by displayCal. I’m not sure if any of these applications are colour managed by default. I’m aware Paint Shop Pro has optional colour management but from reading the documentation it looks like it has to be specifically enabled. FastStone Image Viewer and Irfanview have a CMS plugin but it needs to be specifically enabled and only applies to JPEG and TIFF formats with embedded ICC profiles. From reading around on forums it seems to be dubious as to whether the colour management is being applied correctly (update: I did some testing and could not get it to work correctly at all). Unfortunately, trying to measure any issues this way is flawed: I would actually expect a screen grab to have different values, since the document view undergoes a transform from document to display profile. This is compounded on Windows where it doesn’t embed the image data or resulting image file with the display profile—on macOS for example, the display profile is embedded into the resulting PNG, which allows colour managed applications to display the screen grab accurately. On Windows, when you load that screen grab image back into Photo (and indeed other software) it will assume an sRGB colour profile, which is wrong. This would indeed suggest to me that other software is not colour managed. We’ve compared Affinity Photo and Photoshop when it comes to taking a screen grab of your luminance steps image and both behave exactly the same way: the canvas or document “view” is colour managed (document profile to display profile), and so the screen grab reflects the change in values when it’s loaded back in (with an assumed sRGB colour profile) and examined with the colour picker. Just to clarify here: we produced screen grabs of the Step10.tif image you provided in both Affinity Photo and Photoshop then brought the resulting image files back in and colour picked them. If there is indeed an issue with how Affinity Photo is handling colour management, then Photoshop also appears to be doing the same thing. However, the key difference with both these apps compared to the others you’ve listed is that we know they colour manage the image/document view by default. That definitely should be happening! (Otherwise it would imply colour management is broken). However… This should not be happening, and from testing I don’t believe it’s the case (again, cross-referenced with Photoshop, we see the same results). Unless something has changed, which of course is always a possibility (not ruling that out at all), the document view should be untouched by Windows’s colour management. I believe it may colour manage the UI (which is Direct2D) but not the document view. Again, I don’t believe this is the correct approach because Windows should not be colour managing the document view: it’s up to the colour management within Affinity Photo to translate values from the document profile to the display profile so that they display correctly. That’s how I would expect to correct a screen grab when it has been incorrectly assigned an sRGB profile. You would assign the display profile, then you can convert to sRGB—I wouldn’t leave the document in that display profile and disable embedding the ICC profile on export. Always convert it to a standard document profile. Interesting fact: the Develop Persona is bounded to a linear sRGB document profile in 1.6 (it’s displayed as RAW but is actually linear sRGB)—it’s a known limitation and in the 1.7 public beta (which you can download) the document profile will always change to reflect the output profile (e.g. Adobe RGB/ROMM RGB). However, you would never be stuck with the RAW image’s profile—by that, do you mean the camera’s colour space? RAW software should always convert from the camera’s colour space to a known colour space. However, the same process applies regarding colour management: your final document view goes from the document profile (in this case, sRGB) to the display profile so that the displayed result is accurate. I don’t believe this is a viable idea: even if you profile a display to sRGB, you still need to colour manage between the document profile and the display profile because there will be corrections that need to be made. That’s the point of profiling your display as opposed to just calibrating it. If your physical calibration using the monitor’s brightness/contrast and colour settings is close enough to sRGB, and you do not want a colour managed workflow, then you may as well set your Windows display profile to sRGB. That way, when you work in sRGB documents, the numbers are going straight to the screen without any modification. As it stands, though, Affinity Photo is colour managing with your custom display profile to produce the most accurate result—which will of course look different to apps that are not colour managed. I believe this issue is more related to certain display profiles being corrupt and incompatible with the way colour management works on the Windows versions of the Affinity apps. I think it was certain Samsung and Dell profiles that would cause issues like whites rendering as an orange/cream tone, and short of having users purchase a colorimeter so they could produce accurate custom profiles, the solution was to temporarily switch to the sRGB device profile. That sounds like a really questionable idea—a major feature of a professional image editing application should be to perform accurate colour management between the document profile (especially wide colour spaces) and the display profile. My day-to-day experience is with the macOS version but I also use it on Windows, and certainly from version 1.6 I haven’t had any issues with colour management when using custom display profiles and working on wide gamut displays. I’ve noticed the phrase calibrated in a few of your paragraphs: what is your expectation of calibration versus profiling? Again, my view is contrary to the above if we’re talking about profiling: an application should transform pixel values between the source profile (e.g. the image or document) and the output profile (the display profile), even if the source profile is sRGB and the display is calibrated and profiled to sRGB chromaticity values. Physical calibration can get you so far, but profiling accounts for that last 10%—so for the most accurate on-screen result, those sRGB document values must still be transformed using the display profile. It’s possible this issue comes down to perception about what is right and wrong: we cannot rely on a screen grab to illustrate the issue because the colour values are different—they should be, because the whole point of colour management is to translate the document profile’s values to the screen correctly. So the issue is that the darkest shades appear lighter than they should—but compared to what? If you have profiled your display and the results from the colorimeter are accurate, Affinity Photo should be successfully colour managing between the document profile and your custom monitor profile to produce an accurate representation on your display. Have you tried opening Step10.tif in other apps that you know for sure are colour managed? (e.g. Photoshop)—having done so here on my Windows 10 installation, Step10.tif looks identical between both Photoshop and Affinity Photo. When I'm back in the office I can do some more research on other Windows apps that are colour managed to suggest some ideas. There’s a really easy way to tell if applications are colour managed. Go to this website: http://www.gballard.net/photoshop/pdi_download/#downloads and download the PDI Target(WhackedRGB) ZIP file. You’ll find a JPEG in that ZIP called PDI_Target_WhackedRGB.jpg — open it in various applications. If the skin tones and colours look correct, that application is colour managing from the document profile (WhackedRGB.icc) to the display profile correctly. If the image has a heavy blue cast, the application is not colour managed. I tried this with Irfanview, and enabling its CMS made no difference—I simply couldn't get it to display correctly. FastStone viewer did display it correctly because the CMS was enabled by default—it’s worth checking the Preferences on your version to see if it’s enabled? I don’t have Paint Shop Pro or the Canon software to test with unfortunately and I’m burning through my mobile broadband at the moment by tethering! The image does of course display correctly on Affinity Photo. Also, is there any way you could share your profiling workflow? I use displayCal rather than the i1 profiler software as I’ve found it to be more accurate and you have more control over how the ICC profile is generated (although nowadays software is much better at handling different profile types). I would be really interested to know what software and settings you use. I hope to hear back from you so we can try and address this, and I’m always eager to hear any more thoughts you have about the whole process. I would urge you to experiment with other colour managed applications and see if you find the same results as Affinity Photo. Thank you for reading!

Hi Assaria, as you purchased the iPad version you'll need to refund it through Apple. There's an article with a couple of different ways to do this here: https://www.imore.com/how-to-get-refund-itunes-app-store When I've had to refund apps in the past I tend to use the second approach (web-based) by going to http://reportaproblem.apple.com/ — you log in with your iTunes account details then click Report a Problem next to the app you'd like to refund. I imagine any of the methods in the article would work though. Hope that helps! Additionally, any feedback you may have as to why it wasn't suitable for your work would be gratefully received—it may be something that could be addressed in the future.

Hi Ronny, a couple of things to try if you're up for it? 1) Could you copy/paste the pixel layer from one document to the other and see if the colours are rendered differently between the two images within one version of the app (hopefully that makes sense?). And maybe the other way around, so 1.6 to 1.7, and 1.7 to 1.6? 2) This is a bit trickier, but could you try colour picking the same value across both images as they're open in 1.6 and 1.7? Perhaps try a pixel in one of the corners? (Note: don't colour pick them as two separate layers within one version of the app, it's crucial that they are evaluated in separate versions). Reason being is that we should establish whether the actual colour values in the document are different, or whether it's a change in colour management and how the values are translated from document to monitor profile. We've loaded up the document you provided across both versions and produced screen grabs (ChrisB has attached the document with the Difference blend mode to illustrate this attempt) and we couldn't see any difference between the apps. Have you profiled your display at all using a colorimeter? Or are you using the default display provided with your internal MacBook panel (usually Color LCD) or external monitor? The only other thing I've noticed from your screen grab is that in 1.6 you've opened up what looks like the original document, whereas 1.7's window reads Untitled—have you copy/pasted the pixel layer into a new document from clipboard? When we did the testing, we duplicated the original .afphoto document (since the Affinity apps will not open a document if it's already being read by another app) and opened that, then deleted all additional layers just leaving the original Billboard pixel layer. Using this approach, we couldn't see a difference at all between the two app versions. The most illustrative tests would be the two I've listed above though, especially if you were able to colour pick a particular value. Maybe you could even resize the canvas to 1x1px for both documents to ensure you were colour picking consistently between the two? (A bit OTT and analytical, I admit, but probably the most accurate approach). Thanks and hope to hear back from you!

Hopefully this can clarify the issue and also clear up the concerns that Photo is discarding or throwing away anything outside of sRGB: RAW files opened in Develop go through an image processing pipeline, during which the colour information is extracted and processed—the colour space used for these operations is ROMM RGB because it provides a suitably large resolution and enables colour values to be saturated and manipulated without clipping to white. This choice of colour space was introduced in version 1.5 where there was a marked improvement in RAW files with intense colour values (e.g. artificial lighting). However, the actual document profile is in sRGB—this means the final colour values sent to the screen are restricted to sRGB. Is this deficient? Yes, and there have been discussions about how to tackle it without risking further complication for people who don't use wide colour profiles. There is a silver lining though. RAW files are developed in an unbounded (float) colour space, which means all the values that fall outside of sRGB are not clipped or discarded. If you were to then set your output profile to a larger colour space like ROMM RGB, these out of bound values can be accommodated by the larger resolution of that colour space. Essentially, you can avoid clipping values outside of sRGB when clicking Develop, and you can get them back once you're in the Photo Persona: the issue is that you can't see these values within the Develop Persona. I've experimented with one of my photographs of some intense lighting to back this up, and have attached it to this post for people to experiment with. I've also compared the results versus Photoshop CC 2019 (where you can set the colour space and it will actually affect the view transform) and, minor processing differences aside such as sharpness and lens distortion, have been able to match the intensity of colours. For Photoshop I also used ROMM RGB and increased saturation directly in the Camera Raw module. Here's the RAW file for you to try out: _1190462.RW2 Steps for this experiment: Enable Shadows/Highlights and drag the Highlights slider to -100%. Avoid any colour or saturation adjustments, add other adjustments to taste (e.g. noise reduction). Enable the Profiles option and set the output profile to ROMM RGB. Click Develop. Once in the Photo Persona, add an HSL adjustment and increase Saturation all the way. You'll be able to dramatically saturate the image without losing resolution. If you close and re-open the RAW file and try to increase the saturation within Develop, you'll notice that the colour values are restricted to sRGB—however, even with values at the limit of sRGB, you can still set the output profile to ROMM RGB and then increase them further once in the Photo Persona. And below are two images, one still in ROMM RGB, the other converted to sRGB. I'm not sure how they will display on the forum (and whether the forum software will process and convert the colour profile—hopefully not!) but feel free to download both and view them in a colour-managed application or image viewer. If your display is capable of reproducing wide colour gamuts, you should see a noticeable difference between the two. [Edit] OK, that didn't work, the forum software converts to sRGB and ruins the comparison. Here's a Dropbox link to the JPEGs and RAW file where you can download the original files: https://www.dropbox.com/sh/aof74w94f6lm3d2/AABXE2OJMfk__kjA_jb6vwmia?dl=0 Hope that helps! James

Live filters, particularly those related to sharpening and noise reduction, will generally need to be previewed at 100% to see their actual effect on the "final" image. This is because Photo uses mipmaps (lower resolution versions of the rendered document view) at lower zoom levels to improve performance—the result of convolution filters like unsharp mask, clarity and the current implementation of noise reduction will render differently when applied to a mipmapped version of the document view as it has fewer pixels. I've not looked at recent 2018 versions of the Adobe apps, but I'm aware that the Camera Raw/Lightroom developer may still have a caveat on the Details panel advising users to preview the sharpening and noise reduction results at 100% or larger—so it is likely these apps use a similar mipmap implementation to improve performance when zoomed out. There's been some discussion about how to tackle this, but with 1.7 the majority of the filters have been rewritten to support hardware acceleration, and noise reduction in particular now has a new algorithm which is hugely more effective. It's subject to testing, but we believe the rewriting of the filters may negate or at least reduce the difference between rendering at different zoom levels. Also, as you're into astrophotography, I would personally recommend experimenting with the 1.7 public beta which is available now: Mac: https://forum.affinity.serif.com/index.php?/forum/19-photo-beta-on-mac/ Windows: https://forum.affinity.serif.com/index.php?/forum/34-photo-beta-on-windows/ See the stickied thread at the top. I wouldn't normally advocate using a public beta in anger, but the RAW development and noise reduction are vastly improved and you will probably notice a huge difference with astrophotography. I've been editing wide field astro shots at ISO 6400/12800 and the new demosaicing, noise reduction and rewritten clarity filter are a huge benefit to editing my images. With 1.6, I would previously pre-process the RAW files in other software such as Sony Imaging Edge, but 1.7 is so vastly improved that I'll happily do all the editing exclusively in Photo now. Hope that helps!

Hi RJH, it looks like you’ve got Metal compute acceleration enabled—in 1.6 this is in its infancy and may reduce performance (especially on your integrated Iris graphics). It’s worth disabling it then restarting Photo to see if performance improves. If you’re willing, you could also download and try out the 1.7 public beta, which has much wider Metal compute support, and even in Software many operations are quicker: Let us know how you get on!

Something is happening 1.6's Metal compute support is only for a limited set of integrated GPUs typically found on the MacBook range (2016 and newer). There is currently no support for eGPUs. There is no need to disable the discrete GPU—Photo can still use this for presentation to screen whilst using the integrated GPU for compute. 1.7, however, which is currently in beta, does have extensive GPU compute support and is certainly at the point where you would see improvements in several areas. You're welcome to try the public beta here: https://forum.affinity.serif.com/index.php?/forum/19-photo-beta-on-mac/ (download link is in the latest stickied thread). It will make good use of multiple GPUs in many cases and will scale to however many devices are available to the system. Hope that helps!

If you want to achieve the same effect as the old Clarity filter, just use a live Unsharp Mask, drag its radius to 100px and set the blend mode to Lighten. Alternatively, create a luminosity mask (CMD-Shift-click on a pixel layer) then add the Unsharp Mask and drag its radius to 100px. That's basically what the old Clarity was: local contrast enhancement using unsharp mask with luminosity blending. The new version is more complex and is far more effective, but if you preferred the old look you should be able to follow the above instructions. Hope that helps!

Hi, this occurs with most adjustments at the moment, it's related to an HSL dialog fix—it should be fixed for the next build. In the meantime, if you wish to keep editing with the current build, just add an HSL adjustment before you add any other adjustments. You don't have to do anything with the HSL adjustment (in fact, you can just delete it), just adding it is enough to mitigate the crash. Thanks!