Jump to content

James Ritson

  • Content Count

  • Joined

  • Last visited

Everything posted by James Ritson

  1. Hi, all the videos are on YouTube—they're linked in the first post... alternatively, you can get to the channel here: http://youtube.com/c/AffinityPhotoOfficial/ Just a quick update to make you aware of a new video I've uploaded. It still needs subtitling/localisation before appearing on the Affinity website but you can watch it on YouTube in advance: Changing DPI It was created to address some of the confusion around using the Document Resize feature, so hopefully it will clear things up a bit! As usual, the first post has been updated.
  2. Hello all, apologies as the online help had been updated since Thursday but I didn't get around to updating this thread. Affinity Publisher has now been added to https://affinity.help and there have been a couple of new features added: Search: we've implemented our own bespoke search for the online help which is fast and accurate. Access it via the tab system along the top left. Favourites: you can add topics to your favourites list to easily access them during future browser sessions. Simply click the + (plus) icon next to the "Favourites" tab to add the current topic.
  3. Hi csj, don't worry, I've got more videos planned soon including perspective-related tutorials. It won't be this following week as I'm taking a (hopefully well-deserved) holiday break, but when I'm back the plan is to start gradually building up the library of tutorials. Watch this space
  4. Hey all, just a quick update to say there are three new videos available to watch: Canvas resizing Metal compute Blend ranges Blend ranges in particular should be quite helpful to people. As always, hope you find them useful!
  5. Hey all, just updating you with a new tutorial: HDR from one exposure The list in the first post has been updated too. This video looks at taking advantage of Photo's 32-bit unbounded colour format to tone map a single RAW image and make the most of its dynamic range. Hope you find it useful! Hi Dave, I can definitely say that it makes a big difference. I think people naturally engage more if they see the person presenting, but I believe it benefits the presenter equally. When you're constantly on camera, it becomes more of a performance and you have to engage with what you're saying. It makes the speech and flow more natural because it's as if you are presenting to someone rather than at them—that's what I've found anyway It also encourages a single take process, as opposed to having the crutch of being able to edit the video afterwards. With the exception of a couple of videos (e.g. noise reduction stacking where creating the stack takes some time) the Photo videos are all done live (including the fade in/out) and it's something I'm keen to continue. It is quite challenging however! The whole one take, live studio concept is still relatively fresh so I'm evolving things as I go. Thank you for your suggestion of cropping, I may well give that a go. Regarding swapping the iMac direction, some videos actually put the picture-in-picture in the Navigator panel area so there would always be an issue of which way the presenter is facing. I'm aware of Unmesh, he's great. The whole studio concept came about from watching a variety of teaching channels. There are some consistent themes between them all like having a studio "set" and using picture-in-picture. We wanted a live environment where the presenter could mix on-the-go and have a video file at the end which can be uploaded straight away, so everything is tailored around that approach. Colour grading for the camera, audio EQ and compression, fading in and fading out—these are all applied in real time as opposed to part of an editing process. In terms of presentation style, I believe I'm a bit dry compared to Unmesh, he's a very lively character
  6. Hi all, thanks for the feedback so far! (Pinpointing has been renamed ) I'm aiming to get a few more videos done over the next 2-3 weeks (there is of course the Publisher launch to think about as well...). For now, here's a new one that covers how to use the new HDR/EDR display support. EDR support on macOS is limited to the newer MacBook Pro and iMac Pro panels (other models may be supported but I'm not sure), plus the new XDR display that was announced at WWDC. If you have a Windows machine you stand a better chance of using this feature since you just need an HDR-capable display and suitable graphics card. For example, I used my HDR TV at home to get the clips in this video! The video has also been added to the list above. Hope you find it interesting!
  7. Official Affinity Photo Desktop Tutorials We've got a brand new set of tutorials that follow a more structured approach and are sorted into logical categories. You can access them by following this link: https://affinity.serif.com/tutorials/photo/desktop Please note that the previous thread is now considered legacy and has been unpinned. The videos linked in the thread are also considered legacy—they will remain accessible (albeit unlisted) but ultimately my goal is to produce suitable replacements over time using the new studio setup with live mixing and picture-in-picture. There's been a clear increase in quality of teaching and production values since Affinity Photo was first released back in 2015, and we hope to continue this moving forward. The videos listed at the above link are hosted on Vimeo. Alternatively, please find a list below with YouTube links: Basics UI overview Light UI Open and save Placing images Pixel vs Image layers Moving, scaling and rotating Layers Advanced layer options Selecting layers Mask layers Undo, redo and history Exporting Resizing & resampling Canvas resizing RAW development Metal compute Advanced Adding lens profiles Manual lens corrections (New: 28/02/2020) Brush modifier (keyboard and mouse) (New: 03/03/2020) Colour management Compression efficiency Channels Channels: Selections HDR merging HDR ghosts removal HDR from one exposure Liquify Stacking: Object removal Stacking: Noise reduction Stacking: Exposure blending Focus merging Panoramas RAW advanced development HDR/EDR workflow Macros 360 live editing OpenColorIO setup OpenColorIO baking colour space transforms Blend modes Blend ranges LAB Infer LUT Luminosity masks from layers Masking vs clipping layers Paste/move inside Isolating layers Corrective & Retouching Cropping Straightening Images Inpainting Haze removal Dodge, burn and sponge brush tools Clone brush tool Sky replacement Creative Tools Colour picker tool Gradient tool Paint mixer brush Selection refinement Fill layers Pen tool Filters & Adjustments Curves Levels Masking adjustment layers Filters Live filter layers Displace filter Shadows/highlights Gradient map Denoising/Noise reduction Radial blur Clarity Channel mixer White balance Black & white adjustment Zoom blur Selective colour Procedural Texture: Tone Mapping HDR to SDR Export Persona Exporting slices Workflows & Techniques PSD write-back and PSB import (New: 03/03/2020) PSD smart object import (New: 27/02/2020) Editing infrared photography Relighting 3D renders Using Matte ID render passes for masking Lock children (Masking) Hope you find them useful! James
  8. I appreciate it's from last year but I've only just seen this post because of the thread bump. Based on your more recent posts I've read, however, I would ask you to reign in your combative attitude: it's counterproductive and contributes nothing to the overall goal of this forum. The assumption that the purpose of my response was to somehow undermine and contradict you is incorrect. I was stating that you cannot create initial out-of-bound colour values in the Windows version because of a UI bug. Whilst I would ordinarily agree that the statement was wrong, I had to point out this inconsistency for the benefit of the user, and also cover how you would go about creating out-of-bound values within the user interface, since that was not actually explained.
  9. They're not set by default, but you can assign them by going to Preferences>Keyboard Shortcuts. You should see them straight away if you're on Mac. If you're on Windows, scroll down slightly to see them. Worth noting that you'll need to switch to another persona category at the top (e.g. Liquify) to set a shortcut for the main Persona (Photo, Draw, depending on the app). Hope that helps!
  10. Hey again, the issue appears to be specifically with how the RAW images are aligned and merged in Photo 1.6—notice on your screen grab (and mine) that there is a column of black pixels to the right of the image. If I merge the JPEGs I don't get any issues and can effectively tone map the image. Out of interest, I tried both the RAWs and JPEGs in our current 1.7 public beta and both were fine. I believe 1.7 includes some improved handling of RAF files. I would still either use JPEGs or pre-process the RAWs to TIFFs, since merging the RAW files directly results in some discolouration around the sun—plus you don't get automatic lens distortion correction. Can I just double check that you've tried merging JPEGs in Photo 1.6 as well? As mentioned above, I had no issues when doing so, and I'd recommend trying that if you haven't already. Another option is to download the latest 1.7 beta (https://forum.affinity.serif.com/index.php?/forum/34-photo-beta-on-windows/ - look for the stickied thread at the top). It sits alongside the release build and doesn't interfere, but I think you'd be pleasantly surprised at the improvements, particularly with the speed of tone mapping. I've attached some screen grabs to this post to illustrate the results I'm getting. Hope they're of some help! In order, they are: 1.6 RAW files tone mapped 1.6 JPEG files tone mapped 1.7 RAW files tone mapped
  11. 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.
  12. 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.
  13. 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!
  14. 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!
  15. 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
  16. 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!
  17. 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.
  18. 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).
  19. 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...
  20. 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!
  21. 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.
  22. 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!
  23. 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!
  24. 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.
  25. 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
  • 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.