Jump to content

James Ritson

  • Content Count

  • Joined

  • Last visited

Everything posted by James Ritson

  1. Hi @johncena, there are a couple of things to break down in this reply: Firstly, regarding your OCIO configuration not working, which configuration are you using? If you've just copied the blender OCIO configuration from the blender directory, maybe try putting it somewhere that doesn't require elevated privileges (e.g. Documents folder or somewhere other than Program Files). Regarding the actual filmic transform, there's a little caveat you need to be aware of with blender's OCIO configuration. When the configuration is successfully loaded and you open an EXR file, the 32-bit Preview Panel will actually use "None" as the initial device transform, which gives you an unmanaged linear light view. If you intend to edit your document and export back to EXR, you'll want to switch this over to sRGB and choose Filmic as the view transform. This whole process is non-destructive and only applied to the view, though—the colour values in your document are not altered. If Affinity Photo is your final destination and you intend to export to a non-linear format (e.g. JPEG/TIFF/PNG), I'd recommend switching over to ICC Display Transform instead, which will apply a non-linear view transform based on the document's colour profile. This will then ensure parity with how the exported image will look. At this point, however, everything will look too bright and washed out compared to blender's view. You'll need to add an OCIO adjustment layer going from scene linear (usually just "Linear") to Filmic sRGB. Then you'll need to add a second OCIO adjustment layer going from sRGB to Linear. A bit strange, I know, but essentially your document is still in a linear colour space—there's just a non-linear view transform being applied when it's presented to screen. If you're unsure, I did a tutorial on this here: Hope the above helps!
  2. Hi @Arifin, are you sure? Look at the Colour panel where you have the RGB sliders, they appear incorrect as well. Is there any chance you could screenshot the Colour tab under System Preferences>Displays and attach it here? (Shift+CMD+4 then tap Spacebar and click on the window to screenshot it). Affinity Photo will be colour managing based on whatever display profile you have active... are there any other details you could provide, e.g. what monitor type you're using?
  3. Hi Dziga, the option you're looking for is under Preferences>Colour, near the bottom you have several OpenEXR options. Enable "Associate OpenEXR alpha channels" to premultiply the alpha channels into the .RGB pixel layers. Hope that helps! Also, there's no need to use the flood select tool. As @firstdefence mentioned above, you can also right click any layer including the greyscale alpha layer and choose Rasterise to Mask to convert it to a usable mask.
  4. Hi @bvz, apologies as I've also been out of office. Looks like you have messaging turned off (or I'm blind and can't find the option to PM you ) so I've sent a file request to your email address, hope that's OK. Look forward to seeing the config and trying to puzzle this one out..
  5. Hey @bvz, I've just had a quick test with OCIO on Windows and it appears to be working fine with multiple OCIO configurations (blender, Nuke, ACES etc). My first suggestion would have been to check that your document was in 32-bit but you've already covered that, so we should then move onto what your configuration actually contains. Affinity Photo exposes display/view transforms in the 32-bit preview panel—these do have to be explicitly defined as view transforms and not just general colour space transforms however. Even if you don't have any view transforms, you can still apply the colour space transforms by using an OCIO Adjustment layer (under Layer>New Adjustment Layer). Do your colour space transforms show up in this list? If so, you can likely choose Linear (or whatever role is defined as scene linear) as the Source, and whichever colour space you wish to transform to as the Destination. Hope that helps—if you do have view transforms defined in the configuration and it looks like Affinity Photo isn't picking them up, are you able to attach the OCIO configuration file and relevant directories? (If privacy is required we can send you an internal file sharing link)
  6. Hi all, thanks for your feedback (it is being read!) in this thread. We're rounding off this new set of tutorials with these three: Cropping Straightening Images Procedural Texture: Tone Mapping HDR to SDR More tutorials will of course be on the way in the future—thanks again and hope you find them useful. As per usual, the first post has been updated too.
  7. R16 is a single channel format that contains red channel information—it's typically used for height maps in landscape creation software/game engines etc. Affinity Photo doesn't have any direct R16 export capabilities. However, you could try the following @davide445 : Flatten your document if you have layer work (Document>Flatten). On the Channels panel, scroll down and right click Pixel Green then choose Clear. Do the same with Pixel Blue. Note that Pixel will be whatever your layer is named (so it might be Background if you haven't flattened your document). Ignore the Composite channels at the top as they won't offer the option to clear the channel data. You should now be left with just red channel information. Go to File>Export and choose the PNG format. Click the More button and find Pixel format. Choose Greyscale 16-bit from the dropdown and then export. Your mileage may vary with this—some people have reported success importing these 16-bit greyscale PNGs into the software they're using. Alternatively, if you don't specifically need the greyscale bitmap and just wanted to export an RGB image with only the red channel data, ignore the PNG export steps and just use whatever format you wish. Hope that helps!
  8. Hey again, these new videos have been trickling out on YouTube over the past few days, so I've updated the first post with them: Pixel vs Image layers Using Matte ID render passes for masking Lock children (Masking) As always, hope you find them useful!
  9. Hey all, I've been on a roll with some new Photo tutorials this week—stay tuned daily for new videos, but I've updated the first post with three of the new ones so far: Pen tool Zoom blur Selective colour Thanks, James
  10. Hi 0Kami, I think in this instance even grey would have been misleading. A possible alternative approach which we've discussed is to represent the additive secondary colours (yellow, cyan and magenta) where the channels overlap rather than the singular blue. Regarding the waveform, it's not too dissimilar so don't be put off! Look at it vertically rather than horizontally: the bottom represents 0 IRE (pure black) and the top represents 100 IRE (pure white). You can easily see how brightness is distributed horizontally across your document/image and whether it's clipped. Thanks for your comment on the videos. It's been busy recently and production of new videos has taken a back seat, but hopefully that's going to change soon!
  11. The reason it was changed from white to blue, I believe, is because users were mistaking it for a representation of luminosity—it’s not. It’s describing the addition of the three separate red, green and blue histograms (or the overlap, if you like). If it was a luminosity histogram, the result would often look very different to the RGB histogram since it’s calculated from a weighted average of each pixel's RGB data with more precedence given to the green channel. As an alternative for the time being, I could suggest trying the intensity waveform found on the Scope panel—this gives you a plot of the luminance values independent of any colour information within the document/image.
  12. Unless I'm missing something, the reasoning behind write-back to a TIFF/PSD being so slow is because you're using multiple live filters stacked on top of one another. Live filters are expensive (slow) to render at export time on the CPU, and they have to be rasterised when writing to a format that doesn't support them. Affinity Photo supports layered TIFF/PSD write-back and will of course write its layer data into the files, but no other software supports its implementation of live filter layers, therefore it has to create a full resolution composite that can be shown and also edited in this other software. With the native .afphoto format it doesn't have to do this, it only needs to write a small resolution thumbnail for file browsing. Looking at your screen grab, you have live Clarity, Shadow and Highlights and Noise Reduction layers—Clarity and Noise Reduction are almost certainly slowing down the export time significantly because you'll likely be CPU-limited. I don't believe your GeForce GPU is supported for Affinity's Metal compute hardware acceleration, as this would reduce the save/export time dramatically—likely no more than 5 seconds on a moderate AMD GPU found in the recent MacBook Pro models (2016 and newer). As you've discovered, doing a Merge Visible operation also takes a similar amount of time, as it's essentially doing the same thing—merging a composite layer that has the filter effects baked in. If you go to File>Export and try exporting to any format, do you experience the same export time? If round-tripping is an essential part of your workflow, it's not the most elegant solution but I would recommend trying the old school non-destructive approach to filters: duplicate your image layer and apply the destructive filter to it. It's not ideal, but short of upgrading to a more recent Mac system that supports Metal compute, I'm not sure if there's an immediate solution. Live filters are great for non-destructive workflows, but are hugely taxing on the CPU with large resolution documents. I've tested and confirmed my above explanation on a 24-megapixel 16-bit TIFF file with just live Noise Reduction, Shadows & Highlights and Clarity filters. On a Core i9 (mobile) CPU, writing back as a layered TIFF takes about a minute. It appears to hang (beach ball) for 10 seconds or so, then continues with the export. Whilst this is quicker than your 4-5 minute export time, the CPU architecture is more mature and powerful, so would explain the difference here (plus I didn't have additional adjustment layers and other layer work). If you're able to, however, there is one thing to check based on the GPU you've listed in your specs. Could you go to Preferences>Performance (under the Affinity Photo menu, top left) and see what is listed under the Hardware Acceleration checkbox option? Is it greyed out, or is your GPU listed with the checkbox enabled? I'm fairly sure it won't be supported, but if it is, that GPU only has 1GB VRAM, which will be insufficient for 16-bit large resolution document work and may actually be causing a performance bottleneck. In this case, I would try disabling Metal compute and seeing if things improve. Hope the above helps—apologies as it looks like the round-tripping workflow you're wanting to use is subject to limitations. These can be worked around, but it's not ideal.
  13. Hi Geddy, we do ship what is effectively a ProPhoto RGB profile with the Affinity apps but it’s called ROMM RGB. You can safely use that in the knowledge that it’s ProPhoto. The ProPhoto profile on your HP machine will likely have been installed with other software—I gather you might not have installed that same software on your Surface? Hope that helps!
  14. The Panorama merge operation should get its document colour profile from what is mandated in the image's metadata—this is often sRGB or Adobe RGB. I've just tested with my default RGB Colour Profile option set to ROMM RGB, but the panorama stitch correctly uses sRGB instead since the images are in that colour space. This is on Mac—perhaps it's not working as intended on Windows 1.7.2?
  15. Hi John, thanks for your reply, we can hopefully do some more investigation tomorrow (it's bank holiday here at the moment). That behaviour you describe is expected for 1.7.2, it appears the non-linear view transform is only applied once the document window is restored (un-minimised), we've seen that happen on all the Windows machines here. The concern is that for yourself and others, the view transform wasn't being applied at all until you did a Ctrl-runup and cleared the user defaults. Thank you again for getting back to us about this issue—can I just confirm that everything is working for you now after clearing the defaults? Thank you for the comment about the videos too
  16. Hi Steve, no, you shouldn't need to touch that option, Affinity Photo will automatically use any valid GPU devices. The easiest way to confirm this would be to add something like a Live Motion Blur layer to an image and click-drag on the canvas to make the radius value extreme. As you add/remove GPU devices this should speed up or slow down significantly. I believe Photo supports hot-plugging devices so you can add/remove your Blackmagic eGPU whilst in-app for a more direct comparison. Hope that helps!
  17. Hi John, thanks for trying all that, it's helping to narrow it down. Looks like it may be something the developers need to know about as the same issue is occurring for another customer, albeit when developing RAW files. There are a couple of things to try, and then a final solution if those don't work. My apologies for all this, I believe there was a change in 1.7.2 to fix the 32-bit document view for people who had HDR enabled within Windows, and it may/may not be behind the issue we're seeing here. For the customer I mentioned, minimising and then bringing the app back up seems to apply the non-linear view transform as intended, maybe that would be something to try? Just open up your HDR merge or a RAW file, minimise to desktop, then click on the taskbar icon to bring the window back up and see if that corrects it. Because there are only two reports of this so far (that we know about), it's worth seeing if there's any correlation with PC specifications—I can't find yours listed anywhere, but the other customer's are: Windows 10 Processor: Intel(R) Core(TM) i5-8400 CPU @2.80GHz 2.81 GHz RAM: 16GB Graphics card: NVIDIA GeForce GTX 1050 Ti Do you have anything similar to the above setup? Another thing to try would be a factory reset of the app. If you double-click the app icon (or launch it through the start menu) then immediately hold down Ctrl after doing so, a dialog box should pop up. It will have three options checked by default—leave these checked and click Clear. This will wipe user defaults and window settings—see if this helps your issue. Finally, failing that, I believe a patch will be on its way soon to fix some smaller issues. To get things working for now, it may be worth downgrading—did you purchase through the Affinity store and activate with a serial number? If so, you can download older versions from this page: https://store.serif.com/en-gb/update/windows/photo/1/ — I would normally recommend 1.7.1 but in your first post you mentioned downgrading already. Does that mean you also get the issue with 1.7.1? If so, I would recommend trying 1.7.0 since that definitely doesn't have the HDR document view fix. Again, apologies for the issue. I've been unable to reproduce it on my work and home PCs, so at the moment am unsure of what factors into causing it. Looking forward to your reply!
  18. Hi John, thank you for replying and looking at your settings. One more thing to investigate then—if you go to the top menu and choose Document>Convert Format / ICC Profile, then from the Colour Format dropdown change from RGB/32 to RGB/16 and click Convert, I suspect your image will become brighter and look the same as when you export it. Please would you be able to try this and confirm for me? Just going on a hunch, have you tried loading and editing any RAW files directly in Affinity Photo? If so, could you try opening one, then clicking Develop and seeing if you get the same noticeable tonal shift (i.e. the image looks dark when you're editing the RAW but when you click Develop it then becomes much brighter). To explain the above: the Develop Persona also operates in 32-bit linear when developing RAW files—the same format your HDR merged document uses—so I'm trying to ascertain whether the issue is with the non-linear view transform being applied. The non-linear transform is required to make your image consistent with how it will look when exported. If it's somehow not being applied to the document view (or canvas as we also call it), that would explain the huge discrepancy you're seeing. Thanks again and hope to hear back from you.
  19. Hi, please could I advise not to touch the options on the 32-bit Preview Panel—the Display Transform should be set to ICC Display Transform and left on that option. Unmanaged is for edge cases when you need to see the scene-referred (linear) representation of the image, it doesn't apply to most photography/image editing workflows. By default (when developing to 16-bit), if you try and make edits with an Unmanaged view and then click Develop, the developed image will appear significantly brighter. This is because you are moving from Unmanaged (linear) to a non-linear view transform, and this behaviour is by design. When editing 8-bit and 16-bit documents, the non-linear view transform is accurate and will reflect how your image will look when exported. It's possible to type several paragraphs about all of this, but that wouldn't really have much relevance. In order to troubleshoot this issue, please could you ensure Display Transform is set to ICC Display Transform, perform some edits to your image, develop it, then see if the developed result looks the same? What we need to do is eliminate the 32-bit Preview Panel settings as a factor as they're only complicating the issue. As an aside, this is likely because the navigator preview still has the non-linear view transform applied—in this instance, that's actually correct and is an accurate representation of how your image will look in the main Photo Persona and when exported. Just a side note, you shouldn't change preview exposure and gamma with the expectation of them having an effect on the final image–they're non-destructive and applied at the view stage, they have no bearing on the numbers (pixel values) within the document. To be blunt, for the majority of photographic image editing cases, the 32-bit Preview panel should just be left alone it does have a valid use if you want to enable HDR and see the extended brightness values of your document/image, but until HDR adoption becomes more widespread and supported within image viewers, web browsers etc its usefulness is limited since you would still have to tone map an SDR version of your image for export.
  20. Hi, this is a little suspect since you should be seeing a difference. ICC Display Transform will be performing a non-linear gamma transform using the display profile (and thus is closest to how you will see your image when exported to an 8-bit or 16-bit image format with a non-linear profile). Unmanaged will be viewing in linear light since there is no management from the document profile to display profile. It sounds like you might have HDR enabled in Windows and possibly Affinity Photo—a couple of things to check if you'd be happy to? On your 32-bit Preview Panel within Affinity Photo, is "Enable HDR" checked? Within Windows Display Settings, is "Play HDR games and apps" enabled? (https://support.microsoft.com/en-gb/help/4040263/windows-10-hdr-advanced-color-settings) If possible, could you attach screen grabs of your 32-bit preview panel and the Windows display settings? Specifically, if you have HDR enabled, there's a text option called "Windows HD colour settings" which will open a dialog that gives you a slider to balance HDR/SDR content. If you could get a screen grab of that, it would be much appreciated. If the above doesn't apply to you at all (e.g. you don't have an HDR capable display), would it be possible to just get a screen grab of your 32-bit Preview Panel? I did also notice in Dan's screenshot that you appear to be using a custom sRGB document profile? It has "black scaled" appended to its name. Can I check if this was a conscious choice to use it? I'm not sure about XnView's colour management capabilities, so if this profile has some kind of deviation from a typical sRGB profile it may also be a factor in why your image looks different when opened in that software. Apologies for the wall of text, hope to hear back from you so we can try and narrow down this issue!
  21. Hi Don, you'll also need to be working with a 32-bit float document—typically these would originate from 3D renders (OpenEXR, Radiance HDR), merging bracketed exposures or simply creating a 32-bit document from one raw image. These tutorial videos should hopefully prove helpful: Since you're on Windows, the working terminology will be slightly different (EDR on Mac versus HDR on Windows), but all the functionality remains the same. Hopefully that will work for you—if not, please let us know! HDR on Windows is still a bit hit and miss but I've used Affinity Photo's HDR capability on several setups, and as long as you ensure Windows is compositing in HDR and you're editing a 32-bit document it should all work.
  22. Hi, are you referring to Affinity Photo? Given your specs, I wonder if the new Metal compute hardware acceleration may be more of a detriment than an improvement. Your GeForce GPU won't be supported, but the Intel HD graphics may well register as compatible—the issue is that the older generation of Intel integrated graphics are quite weak, and the compute performance is likely slower than just using CPU. If you go to Preferences>Performance and disable Metal compute at the bottom (then restart the app) does performance improve? This should at least return it to 1.6 levels of performance with additional 1.7 optimisation in some key areas. Hope that solves your issue—if not, let us know!
  23. Hi, this issue comes up quite frequently. The Affinity apps perform colour management from the document colour profile to the display/monitor profile—it's possible you have a defective display profile which was installed by default along with your monitor. You will likely come across the issue with any colour managed applications (including Adobe products, just google "Photoshop whites are yellow" and this will be corroborated). Ideally, you need to profile your monitor using a colorimeter/measurement device e.g. i1 Display Pro using either the software it comes with or displayCal. This will produce a proper display profile that works correctly with colour managed software. If this is not possible, you'll need to reset your display profile within Windows to the default sRGB device profile. Here's a thread post with a solution, look specifically at step 6 for how to assign the sRGB device profile to your monitor: https://forum.affinity.serif.com/index.php?/topic/91411-100-red-in-document-and-color-picker-looks-orange/&tab=comments#comment-485651 Note that while this should work, it's not an ideal solution. In order to ensure accurate colour representation you should really consider investing in a colourimeter device and creating a custom profile. The Affinity apps are colour managed, so they will be able to use this custom profile to accurately convert the colour values from the document to your monitor. The reason you're not seeing the issue in other apps such as Xara Designer is because they likely do not perform colour management. Hope the above is helpful to you. [Edit] Here is another thread with the same issue (which also links to the steps provided in the thread above):
  24. Hey all, just a quick update, here's another video for you about using the Infer LUT functionality: Infer LUT Stay tuned for more videos soon!
  25. Hi @Wireman, just to quickly answer this: Photo is taking parts of the wire from the left/right of the bird. It will analyse and try and replace the content in the most logical way, which means it will often "complete" lines or similar subjects. It does this with or without the non-destructive approach. I'm not on a Mac at the moment so I can't test, but I've never had this experience. I'll have a look when I'm in the office tomorrow. I would have suggested some kind of keyboard setting (perhaps accessibility?) but you say it doesn't happen in other apps, so probably not...
  • Create New...

Important Information

Please note the Annual Company Closure section in the Terms of Use. These are the Terms of Use you will be asked to agree to if you join the forum. | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.