Richard Liu

Very happy about this. Let's hope the changes make it into the next production release.

Thanks all for the clarification regarding the amputated colors. What is the status of this bug or feature? Will it be fixed, or is there some justification for mapping to sRGB on input and output to/from Develop instead of to the target output color space?

@>|<: Yes, that's way it's configure in my installation. If you liked prestidigitation, don't miss the sequel, legerdemain (literally French for slight of hand).

The current approach of AP to development, i. e., prestidigitation (now it's sRGB, now it ain't, now it is), essentially limiting colors to sRGB -- yes, I understand that working in between input and output in 32-bit floating point and ROMM RGB has at least theoretical benefits --, would seem to be something that it would behoove Serif to repair before it becomes public knowledge, unless, of course, this is supposed to be a feature, the superiority of which over the more straight forward approach of the competition should be more widely publicized. Ironically, I entered this thread assuming that both AP and DxO are both using all data and metadata in RAW files, so it would be possible to obtain with AP results similar to those I get with DxO, and any extra work involved would be mitigated by the benefits of working exclusively in the more powerful and more flexible product. Now, I must conclude that, unless DxO is engaging in the same color reduction hocus-pocus, the differences I see between AP and DxO might well be due to the extra color information that DxO has retained, which all the extra power and flexibility of AP is not likely to be able to compensate.

@v_kyr Yes, that's how I understood you. In fact, the camera is configured to shoot NEF + JPEG and generates not only the embedded JPEG, but also the same JPEG it would generate if I were only shooting JPEG.

@>|<, @v_kyr, @R C-R, @HVDB Photography, and all who stumble on this in thread in the future: Here is the thread that discusses bug/feature/behavior mentioned by @>|< and confirmed by @v_kyr: This is disappointing and unacceptable, especially as it seems to be a "feature" of the current release candidate as well. If I understand correctly, colors exceeding sRGB in a RAW file opened in the Develop persona are converted to sRGB. Subsequently, all operations performed during development are done in 32-bit floating point in a wider-gamut color space, just so that resulting colors that fall outside sRGB are not immediately lost. Finally, during output, any colors outside sRGB are converted to sRGB. I'm not sure I see much point in using Affinity Photo for development until this is fixed. Does anybody know whether the Photo persona performs the same kind of prestidigitation? If I developed in, say, DxO Photo Lab 2 and exported the results in, say TIFF and Adobe RGB, and opened it in AP in the Photo persona, would it first convert the colors to sRGB?

@>|<: Woah! I have my camera configured to use Adobe RGB, so, do you mean to say, when AP opens the NEF (Nikon's own RAW format) file in the Develop persona it first converts all the colors that Adobe RGB can represent that sRGB cannot into the "next best" sRGB colors??? I can hardly believe that. If you mean, in this case it retains the Adobe RGB colors during the development, but converts the results of the development to sRGB during output. Well, that, too I find hard to believe. Why on earth would it do either of these two things if I've taken the trouble to photograph in Adobe RGB?

@R C-R: Yes, I was sure. Furthermore, how many bits (16 or 32) which color format (8-, 16- or 32-bit RGB, etc.) and which ICC profile (sRGB, Adobe RGB, ROMM RGB) are used during the processing, especially in the Photo persona, seem to be three independently configurable aspects of the processing, an impression that one doesn't automatically get when one learns that the Develop persona works in 32-bit float and uses the ROMM RGB profile. Indeed, I had assumed up until now, that ROMM RGB implied 32-bit processing and 32-bit RGB color format, and that the advantages of both developing and editing using 32-bit floating point calculations in ROMM RGB would outweigh the slowness of floating point calculations. I think I, at least, really need to understand what @James Ritson was warning against when he wrote, "Honestly, I wouldn't recommend touching 32-bit unless ... ." Did he mean color format 32-bit RGB or 32-bit floating point processing, or are these equivalent for him. Specifically, too, I would like to know some of the pitfalls of "32-bit" to which he alludes.

Thanks, Hubert. I read @James Ritson's answer in that thread, obviously in a way that he never intended, weighing each and every word twice and thrice, and coming up with more questions than answers. A cursory reading reveals what seems to be a contradiction between the virtues of development done in 32-bit floating point, the advantages of editing (in the Photo persona) in a wider-gamut color space than sRGB, and the ominous sentence that begins, "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 [...]" I think 32-bit processing and working in, say, ROMM RGB are two different animals. At least, that's the only way I find to avoid that contradiction. The abrupt cut to the take-home message, not to use 32-bit unless ..., is, in my case at least, unhelpful, for it's exactly the sky and the clouds, blown out in the JPEG generated in-camera and quite evident in Develop, that I will want to preserve, if not enhance, in the Photo persona. Maybe James would not consider that to qualify as "close-ups of clouds or skies." Finally, the reason that James gives for avoiding 32-bit if possible is enticingly nebulous: "but it brings about other issues into your typical image editing workflow." I suspect that I am experiencing some of those issues, and could avoid them altogether by configuring Develop to output 16-bit RGB using the ROMM RGB profile; however, my understanding of why I might not want to opt automatically for the seemingly greater flexibility of 32-bit RGB and ROMM RGB would be enhanced by a tutorial that clarifies the terms 16- and 32-bit processing; 8-, 16- and 32-bit RGB color format; sRGB and ROMM RGB profiles and illustrates the advantages and disadvantages of 32-bit editing.

By the way, do you have the your settings for Develop in 32 bits and and those for the tone mapping to hand. Perhaps there's "just" something that I'm overlooking in Develop. If not, don't worry. I'll have something to do over the Christmas holidays. Merry Christmas to All

I second the motion. By the way, I had a look at your tutorials on YouTube. I think you could improve them by using your own voice. The reader that you use often puts the emphasis on the wrong word in a phrase. Besides, a foreign accent enhances the aura of the product. Otherwise, my compliments. Well done, and very useful.

Hi @HVDB Photography, Thanks. I was able to reproduce your results provided I changed RAW output format in the Develop Assistant to RGB (16 bit), even though our settings on Noise reduction also disagree (I have only Apply color reduction). I notice that, in my case, clipped highlights, shadows and tones appear. Maybe they would disappear if I changed my configuration for Noise reduction to yours. At any rate, the main difference is the RAW output format. I'll be the first to admit that I really don't understand what I gain by configuring RGB (32 bit HDR). Is there any tangible benefit, or are the benefits only theoretical? My (mis)understanding is, Affinity Photo is working in 32 bit anyway, and therefore it might be advantageous to postpone a conversion to 16 bit until the device for which the output is intended cannot handle 32 bit. Also: I'm not sure how you came up with the idea of increasing Blackpoint. I usually decrease it, since many adjustments that I will perform in the Photo persona (e.g., increasing contrast and detail) seem quite often to push the histogram back to the left. Regards, Richard

Hi, I think I have the same question as @kwebble. I am uploading a .NEF, an .aphoto and its corresponding .jpg, and a .dop and its corresponding _DxO.jpg (Archive.zip) and would like to ask the forum what I can do to make the .aphoto more similar to the .dop. Technical background: Affinity Photo 1.6.7, DxO Photo Lab 2 2.1.1 build 17, macOS 10.13.6 running on 2018 MacBook Pro 15". Photo: Taken Dec. 6, 2018 at 16:11 from one of the two towers of the Basel cathedral. It had rained off and on the whole day, the sky was just clearing and the sun just setting. The camera is configured to use Adobe RGB. Affinity Photo is configured to use ROMM RGB. The .afphoto seems "muddy," particularly in the foreground, and lacks the "punch" of the .dop. I am sure that most of the difference can be attributed to my inexperience. Affinity Photo is configured not to use a tone curve when importing a RAW file. In the Develop persona I do some minimal sharpening, tame blown out highlights and try to "spread" the histogram. In the Photo persona I try to first get the colors right before I mess with sharpening, but invariably find that I spend more time on sharpening. Photos like this one stand to benefit from dehazing, but dehazing and sharpening seem to introduce enough visible noise that avoiding and/or mitigating it soon becomes important. I hesitate to use DxO as a substitute for Affinity Photo's Develop persona. I tried exporting from DxO to .DNG, and importing it to Affinity Photo. Yes, the file was recognized as RAW, but it bore little resemblance to what I was seeing in DxO when I exported it. A mix-and-match approach to developing RAW "film" and "printing" "negatives," although perhaps logical, would seem to be fraught with pitfalls. Thanks in advance.

Thanks to both of you, @Gnobelix and @MEB. Yes, that's undoubtedly the problem.

Hi, I took advantage of Black Friday sales to purchase DxO's Nik collection. I followed the installation instructions for installing the plugins into Affinity Photo. They show up Preferences > Photoshop Plugins, "Allow 'Unknown' plugins to be used" is checked, "/" is in Plugin Support Folders and "Authorize Global" is greyed out. When I select a pixel layer in the Photo Persona I can select only one of the plugins that appears in Filters > Plugins > Nik Collection, "HDR Efex Pro 2". All the others are greyed out and cannot be clicked, not even the two that have status "Working." HDR Efex Pro 2 did run when I clicked it. I am running Affinity Photo 1.6.7 on macOS 10.13.6 on a 2018 MacBook Pro 15" with Touch Bar & Touch ID. The pixel layer is "Background," generated by the Develop Persona. The file that was developed was a Nikon RAW (NEF) created on a D7200 using Adobe RGB. The Develop Persona uses the ROMM RGB profile for output. Neither Lightroom nor Photoshop is installed on the machine.