James Ritson

Hey SrPx, the shimmering you describe sounds like the initial low quality draw pass followed by the higher quality pass. Under certain circumstances, like if you have a complex layer stack and you're doing brush work, Photo will only redraw with a high quality pass on the canvas tiles that are affected, and will use a render cache for the other tiles so as to avoid redrawing the entire layer stack. As I understand, this performance-saving technique was disabled for a while (including build 293), but has actually been re-enabled since it was slowing down more complex documents. Have you tried a more recent beta (e.g. 331) to see if the shimmering now appears again? Of course, you might not be seeing the shimmering regardless because there have been some huge performance improvements for 1.7 on Windows—big improvements in threading and memory management—that might mean the redrawing is fast enough for you not to notice any shimmering. If that's the case, great! Build 293 is quite old now, so it's worth trying out the latest beta and seeing if your experience is the same. Hope that helps.

Hi Crimmy, nice shot, is that in the Peak District? I've shot plenty of HDR bracketed exposures pointing straight at the sun and Affinity Photo is definitely capable of merging them and producing good results. Not sure what's happened with merging your bracketed set, have you tried merging both the RAW files and the JPEGs? As an aside, I wouldn't merge RAW files at the moment—either use JPEGs or preprocessed TIFFs from the RAWs. Affinity Photo doesn't currently use its more advanced RAW pipeline for merge operations like HDR/Panorama so you won't be getting the most out of its conversion (we're aware of this limitation). Does the white halo effect go away if you reduce compression to 0% when tone mapping? What happens if you only increase local contrast? If you wouldn't mind providing your sample images privately, you could upload them to https://www.dropbox.com/request/6BFpR1crs5jTGb5BcXsx so we can take a look and see if we can suggest a solution—in this case, both JPEGs and RAWs would be ideal to compare them as well. The images are only used for support purposes and then deleted when no longer required.

At the moment, the Colour panel will reflect both the transform and document colour profile—so linear values will look different to non-linear, and the values will also change depending on the colour profile. Currently, however, there's no interaction with OCIO integration, so what you're seeing on the Colour panel isn't guaranteed to represent the device and view transforms you're using. It's something we're aware of, but I'm not sure when it might be addressed...

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.

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 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!

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!

To clarify, the general Develop process is done in sRGB float—this includes the initial conversion from the camera's colour matrix to a designated colour space. However, the colour data is processed in ROMM RGB which produces enormous benefits for some type of imagery, particularly low light images with lots of artificial lighting sources. Despite this, the document is in sRGB and so this is the colour profile used when converting to the display profile. As the pipeline is in float, this does mean that you can convert to a wider colour profile on output and avoid clipping to sRGB, which is the recommended course of action for now. Do you mean the final developed image? This isn't my experience—choosing an output profile of ROMM RGB and then using adjustments and tools within the Photo Persona allows me to push colours right up to the limit of P3.

Hi Beau, by the time you start editing your image in the Develop persona, it's already been demosaiced. Anything done in Develop offers two technical advantages: The development is done in 32-bit float, meaning pixel values aren't clipped until you click Develop and move to the Photo persona. It uses a wide colour space for development called ROMM RGB (essentially ProPhoto), meaning you can intensity colours without clipping them—very useful for imagery with lots of artificial lighting like night time/low light shots. Both of these can be carried over to the Photo persona, however. 32-bit processing can be specified in the Develop assistant (the little suit icon on the top toolbar), and you can also click the Profile option and change the final colour space from sRGB to ROMM RGB. Also, in Preferences>Colour, you can set the default colour profile to ROMM RGB so that processed images will always default to that colour space. Be careful with this if you bring in images that aren't tagged with a colour space (e.g. screenshots) as they will automatically be assigned the default profile. Honestly, I wouldn't recommend touching 32-bit unless you're doing something that demands precision above what 16-bit offers, e.g. close-ups of clouds or skies, HDR, subjects with very fine tonal gradations etc, but it brings about other issues into your typical image editing workflow. For 99% of imagery, 16-bit is more than sufficient. Editing in a wider colour profile I would recommend though, as you get benefits even if your final output is going to be sRGB. Check out the video I did for more info on this: Just as an insight, my typical workflow involves opening a RAW file, removing the tone curve (you can do this through the assistant menu) then using basic adjustments to create a flat image that makes the most of the available dynamic range. I'll then develop that so it becomes a 16-bit image with a ROMM RGB colour profile and do most of the editing in the main Photo persona. To that effect, I only use Develop to create a flat image, and sometimes add initial noise reduction depending on the image. Hope that helps!

Hi, Photo doesn't use the preview JPEG in any capacity so that shouldn't be the issue. When you say 'a minute later' do you mean when you click Develop? If so, have you somehow changed the default colour profile to use your soft proofing profile instead? (through Preferences>Colour) This is inadvisable, I'd recommend just sticking to sRGB or a wider profile like Adobe RGB/ROMM RGB. You soft proof via an adjustment layer which you then disable before sending to print—it's a different method but the results are the same. By all means, you should be able to contact Apple for a refund—if you still have the app installed however, it would be really useful to see a couple of screenshots and get an idea of what's happening. Would you be able to take a screenshot of your main workspace with the document's colour profile listed in the top right? And additionally maybe a shot of the Preferences>Colour dialog? Thanks, James

Hi, that's odd, have you got an example? What renderer do you use? I've rendered out plenty of EXRs and Photo correctly imports the channel data. Have you got alpha association enabled at all? (Instead of importing the alpha channel as a separate layer, it will merge it into the RGB layer's alpha channel) Hope to hear back from you!