James Ritson

Hi Aardo, welcome to the forums. Hopefully these answers will be OK for you: RGB/16 is integer, we only support float in 32-bit. 16-bit and 8-bit are gamma corrected, whereas 32-bit is linear. By default, however, 32-bit uses an ICC display transform (i.e your monitor profile) for a non-linear transform to screen. You can configure this through View>Studio>32-bit Preview where you can choose between display transform, unmanaged (linear) and OpenColorIO transforms if you have a valid OCIO configuration set up. To create colour values below 0 and above 1, you can double-click on the current colour within the Colour panel and it will open up a colour dialog. At the bottom you'll have 32-bit options including an Intensity slider and interactive dialog where you can add/reduce the values in intervals. You can also colour pick values from your document that are out of range. Additionally, if you click the circular icon where it says Opacity on the Colour panel (beneath the HSL wheel/colour sliders) it will cycle between Opacity, Noise and Intensity—the latter of which again allow you to create out of range values. For OpenEXR export, both 32-bit and 16-bit options are float (or half-float as it were for 16-bit). Regarding your HDR and EXR documents, I believe the Info panel is always constrained to 0-256 values. You should be able to colour pick out of range values (as mentioned above) however. Bear in mind that there is a bug with the Windows version that clamps the colour picker and the colour dialog to 0-1. We're currently aware and this is being addressed for 1.7's release. If you're on macOS, everything will work as expected. The next Windows public beta of 1.7 (https://forum.affinity.serif.com/index.php?/forum/34-photo-beta-on-windows/) will hopefully fix the clamping issue. Hope that helps!

Hi Chris, it sounds like your issues will be vastly improved by version 1.7 when it's released. It has a number of threading/general performance improvements that dramatically speed things up for high-end processors—I think your Xeon is an 8-core/16-thread? I've just tried editing a 16k HDRI using live projection, inpainting and cloning and it runs really well (this is on an i7 4-core/8-thread). With a 35k HDRI in version 1.7 I would now expect good performance with your Xeon. You can actually download and use the 1.7 public beta (stickied thread at the top of https://forum.affinity.serif.com/index.php?/forum/34-photo-beta-on-windows/) but it requires a valid license key to be activated, meaning the software needs to be purchased. There are two potential options: you could wait until 1.7 is released, download the trial and see if performance is improved for you. Alternatively, if you were eager to try it now, you could purchase 1.6, then download and install the 1.7 beta (it sits alongside the current release build and does not interfere). If you aren't satisfied, you could then request a refund citing performance issues—it's a 14-day return window if you purchase through the Affinity store (see https://store.serif.com/en-gb/help/). If you purchased through the Microsoft Store you would have to request a refund through their system instead. Apologies, as I realise there is no immediate solution for version 1.6—although you could tweak the performance options, they are unlikely to produce any significant improvements. 1.7 should present a huge leap in performance for the majority of higher-end PCs like yours. Hope that helps!

No worries, this was identified as soon as build .116 released and has been corrected for the next upcoming build.

Are you sure this isn't related to OpenColorIO with Metal compute? (I'm going to assume you use OCIO) The whole OCIO pipeline is currently broken with Metal compute—if you disable Metal compute and switch back to software under the Performance preferences section everything should work fine. I've been opening EXRs produced from various software (with OCIO configured) and haven't had any issues. The developers are aware of this and it should be fixed soon. If that's not the solution to your issue, it would be great if you could provide samples as Gabe suggested so we can have a look. Thanks!

Hi @TestTools, I'm hoping to take a more detailed look at the issue, but you can work around this for now by copying all your layers and pasting them into a new document with the same dimensions and colour profile. I've attached a video to demonstrate what I mean. If you look at the thumbnails of your original document, you can see all the greyscale layers are tinted blue. Can I ask how you originally created the document, did you start in the same Rec.2020 colour space? I noticed you had a bizarrely high DPI value but that shouldn't have any implication here. Although it should only affect the final view transform, I must also ask how you've profiled your screen—are you choosing between the existing profiles that ship with macOS or have you used a hardware device like an i1 Display Pro? Thanks and hope to hear back from you. p3_rec2020.mov

Watch this space...

Hi srg, this is most likely the Selective Colour adjustment. In particular, check your Yellows/Reds contribution as that has undergone a change for 1.7—I believe it was altered to better match the equivalent adjustment with imported PSD documents. This is a positive long-term change, but it does mean that selective colour adjustments made in 1.6 will look different. Generally speaking, you will find the sliders under the Yellows and Reds categories are more sensitive. E.g. if you had the Magenta slider set to 100% you should be able to achieve the 1.6 result by scaling it back a bit to around 50/60%. Hope that helps.

Hey there. Photo doesn't perform destructive gamma correction on 32-bit documents—it's a non-linear view transform mandated by the ICC display profile. This is the default view because the majority of users will be merging bracketed exposures for HDR imagery, and they will need to see an accurate rendition of what happens when they export to an exchange format with a non-linear profile (e.g. JPEG/TIFF sRGB). All of the compositing is done in linear space (and so all of the tools/adjustments/filters work in linear space). When you export back to EXR it should be linear, regardless of the ICC display transform—have you tried exporting back to other software yet? You can switch to a linear view through the 32-bit Preview panel (found under View>Studio)—choose Unmanaged. The image should then look consistent with Nuke's rendering. A good way of confirming that the document itself is still linear is to use the colour picker: colour pick a value and look at the RGB values. Now switch the view transform (e.g. from ICC Display Transform to Unmanaged) and colour pick again—the value will stay consistent. The colour picker only reports linear values, it's not influenced by the view transform. For your workflow, it sounds like you may want to use an OpenColorIO configuration. You could use an OCIO view transform on the 32-bit Preview panel which matches your requirements. The other consideration is colour space conversion during EXR import/export. Photo always converts to scene linear upon import. You said you're working in ACEScg—if you use that ACES configuration from the official OpenColorIO.org website, you can append your EXR filenames with "acescg". Photo will then convert from ACEScg to scene linear ensuring your colour values are accurate (you'll get an on-screen toast to confirm this). When you export, if you intend to maintain that colour space, append "acescg" to the filename and Photo will convert back from scene linear to ACEScg. Apologies as that's a wall of text, but hopefully it addresses your issue? Look forward to hearing from you!

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!