Jump to content


  • Content count

  • Joined

  • Last visited

About CarrotMan

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Thanks for this, it does look as though this is the source of the problem. I’ll get onto DxO again. It seems very odd that the sRGB profile is presumably attached to the TIFF which PL2 launches into Affinity, but somehow missing from the TIFF which PL2 exports to the Pictures folder. At least I know now that this is not an Affinity issue, and that AP is correctly applying the set profile to a profile-less TIFF when opening the file from Pictures, but presumably finding a profile when the program is opened from inside PL2! Does this mean that PL2 creates two TIFFs, I wonder? I don’t tend to use PL2 and Affinity together much because of the known problems with Viveza, which means I tend to use PSE to apply Nik edits. I initially thought it was just another DxO - Affinity tiff (apologies for the awful pun!), so good to know that Affinity is “not guilty”.
  2. (I have already sort of asked this question here, but not got a reply yet, so I’m revising it). I inadvertently had ROMM RGB set instead of sRGB in AP colour setting preferences (sorry, haven’t got AP open at present, but I mean in the setting near the top of the menu). When opening a TIFF in AP, which had been converted from a Canon .Cr2 in Canon DPP, or from a Fuji .RAF in Silkypix (these TIFFs being 8 bit sRGB), the colour looked fine. But if I opened a TIFF (again, 8 bit, sRGB) which I’d processed using DxO PhotoLab 2, the colour was awful and very over-saturated. But if I opened the same TIFF directly into AP by launching the “Export to application” function, the colour looked fine. I wonder why? It looks as though maybe opening the file from within AP makes the software use the ROMM profile, but launching AP from within PL2 somehow ignores it? (Everything is fine now I’ve changed the profile from ROMM to sRGB, I’m just curious about this issue).
  3. I don’t know whether I am doing something wrong or what is going on. My problem: convert a raw file in DxO PL2 (doesn’t matter whether it is a Canon or (old, non-X-trans) Fuji. The tiff is exported as 8 bit and sRGB. If I open these tiffs in Photoshop Elements 2019, they are fine. If I open with Affinity, the colours are weird and grossly over-saturated. This is almost the reverse of the known issue with Viveza and Affinity. If I process the raws in Affinity, the colour closely matches what I get from PhotoLab. (The colour rendering in Affinity of Canon raws converted to tiffs in Canon DPP, and of Fuji raws converted to tiff in Fuji/Silkypix, is not problematic). ADDED I have now discovered that this only happens when I open a tiff by browsing to the file within Affinity. If I use the “Export to application” command in PhotoLab, and choose Affinity Photo this way, the program opens and displays the colour correctly! ADDED I have discovered that I’d got the RGB Colour Profile set to ROMM RGB in error. Presumably launching AP from within DxO causes the program to display the tiff as sRGB, but opening AP and then opening the file causes it to display as ROMM.
  4. Would it be possible to include the option of displaying more grid lines within the Curves tool than the current three verticals and three horizontals? Maybe dividing up the current 16 squares into 64?
  5. Thanks, I will suggest it.
  6. Thanks. I’ve looked at this, and I can alter the grid superimposing on my image, but it doesn’t seem to control the Curves display. In the Curves dialogue the grid divides the display into sixteen squares and I’d like a lot more if possible.
  7. Apologies if this is covered in an existing post which I’ve overlooked. Is it possible to change the grid displayed in the Curves tool, to give a grid with a finer “mesh”?
  8. Thank you Callum. I’ve now downloaded the update and it seems to be working fine. Re what I wrote about the Mac and Windows differences, I got this from a recent (5 June) review on ephotozine, which seems to be suggesting that some speed improvements made to the Mac version have not yet been implemented in the Windows version. I appreciate that the Nik problems require work from DxO. It would be great if they could sort it, but maybe they aren’t too keen to do so.
  9. I have a few questions about the new 1.7 AP release: 1) If I update from my version 1.6 (not sure of the rest of the version number, I’m not on my laptop), can I still keep the last 1.7 beta on the same laptop (Windows 10), just in case I hit a snag with the updated version? 2) Will the improvements which have been implemented in the Mac version of 1.7 be available to me as a free upgrade when completed for the Windows version? 3) When (if?) the DXO Nik plugin issues eventually get sorted, will this be in a free update or is it likely to be in a future paid upgrade? Thanks
  10. @John Rostron Thank you. I’m a bit confused by this because I thought that this image, an 8 bit TIFF which I converted from a raw in Canon DPP and then opened in Affinity, was by definition a rasterised layer, so don’t really understand why I would need to rasterize it. My knowledge is very limited, but reading up a bit on this my understanding is that one can have vector layers in Affinity which can be rasterized, and have to be for certain purposes, but if a TIFF is a raster format how can it be rasterized (or re-rasterized). Or has Affinity done something to “unrasterize” this TIFF? Please excuse my ignorance.
  11. I'm disappointed to find that the weird colour problem with Nik Viveza seems unresolved still in Affinity, but I seem to be having another issue too. I cropped a photo, duplicated the layer and applied the Viveza filter, and find that not only does it have the usual colour problem, but that the filter layer is uncropped too (screen shots attached. Please ignore the first shot, which is just a duplicate of shot 2. And the fact that the shots seem to be breeding!!!).
  12. @John Rostron I think that the non-alignment issue was almost certainly because the darkest raw file, which I was trying to put beneath the HDR merge, seems to have had a slightly smaller pixel size for some reason, than the HDR stack layer. It may be because DPP had apllied lens correction but AP hadn’t (only CA and defringe). I think this is what the poster in post 3 is suggesting. Certainly DPP can make quite a noticeable difference to what appears in the image after lens correction is ticked. I think that DPP preserves all the lens correction parameters once applied until re-set. Julian
  13. @John Rostron Thanks for this tip, John. I will try it. Thanks too for showing me how to answer correctly. I did try quoting, as on some other fora, because I wanted to answer you specifically, but thought I was doing it incorrectly, so I’m glad you put me right. Julian
  14. Thanks John. I suppose it has done a pretty goog job in that case, because the edges are just the fuzzy edges of weak shadows in brighter patches. I wonder whether I might be better to try what I originally thought of, and create a selection around the most blown out area, then just apply the Blend Range manoeuvre to that. Precise alignment would then be pretty irrelevant. I’m really only trying to rescue a fairly small patch of totally blown-out white. Julian
  15. Thanks for the tip about lens correction. I think I re-opened the HDR merge in Develop to use the CA removal tool, but I will try developing each file individually and then merging them. I’m on my iPad at the moment and haven’t got access to Affinity, but think I can only access the CA removal option in Develop, but that defringeing is available in both Develop and Photo? To get rid of all the fringeing I had to use both tools. Julian

Important Information

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.