Richard Liu

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.

Oh, sorry, yes, the alias works. Your suggestion would, too, presumably. But, as I said, is this the only way for Affinity Photo to get those profiles? Because I don't remember copying them to either ~/Library/ColorSync/Profiles/ or /Library/ColorSync/Profiles/, and I see neither the profiles nor aliases pointing to their location in backups that were made before the macOS upgrade, when the profiles were appearing in the dropdown displayed by the Softproof layer. Is this just suspicious me, with more than forty years of experience in IT, fearing that another problem might be responsible for Affinity's not finding the profiles after the OS update, and your and my solutions do not address that problem, only a symptom of it?

Thanks for the reply. In fact, I ended up doing something similar, i. e., putting an alias to the folder that contains the profiles in /Library/ColorSync/Profiles/. I just don't remember doing either what I did or what you recommended before, and hunting through Time Machine to backups made just before I migrated to macOS 10.13.6 turned up neither aliases nor the profiles themselves, not in ~/Library/ColorSync/Profiles/ and not in /Library/ColorSync/Profiles/ either.

I just upgraded macOS from 10.12.6 to 10.13.6. Since then I haven't used Affinity Photo. Today, I discovered that the printer profiles for my Canon PRO-1000 no longer appear in the list that the Softproof adjustment layer displays. They do appears in the usual macOS print dialog, and I see them in /Library/Printers/Canon/BJPrinter/Resources/ICCProfiles/PRO1000series.canonicc/Contents/Resources. Where is Softproof expecting those profiles? If where they are, why am I not seeing them in the Softproof dropdown?

Apple was on the right track for a while, organizing images in iPhoto by event, location and people. Machine learning as applied to images has evolved to the point that a machine learner can be trained to describe pictures, recognize landmarks, etc. This technology makes keywording pictures as a means of describing their contents as obsolete as, say, keywording web pages as an alternative to using sophisticated search engines that deal with the actual contents of web pages. If I were developing a photo manager I would pay close attention to opportunities to apply machine learning instead of relying on the patience and diligence of a human keyworder. Professional photographers might have a higher tolerance for the pain of providing accurate metadata for their photos than recreational photographers. Yes, in a sense, classic relational databases are not the best way to store information about photos. You really want something more flexible, e. g. and ontology. I am still using iPhoto, the predecessor of Photos, for organizing my photos. I have only recently begun developing and editing them, in Affinity Photo, so would need a program that manages workflows and dovetails with iPhoto/Photos, or one that does everything that iPhoto/Photos does plus manages workflows. I have all but given up hope on ever being able to migrate my photos to another application without losing all the manually supplied locations where I took the photos.

I second this feature request. I find it really odd that, when a RAW file is opened individually and the Develop Assistant has been configured to perform lens correction, that is done, but when a RAW file is in a batch job, lens correction -- and, presumably, any other operations that have been configured in the Develop Assistant (such as color noise reduction or tone curve) -- is/are not. Surely, Batch Job must open each file in the job and pass it to the Photo Persona, where any macros are created and applied. Surely, Affinity Photo should open the files the same way as it opens them individually. In Batch Job it could be desirable to specify which configurable options of the Develop Assistant should be applied to the RAW files, just in case they are not the same as the ones configured in the Develop Assistant.

A variation on the theme of improving the batch processing of RAW files would the option of applying any or all options in the Develop Assistant, e. g. lens correction, color reduction, tone curve. Right now the lens correction, which I have configured to be automatically applied to RAW files by the Develop Assistant, is not being honored by Batch Job, so I must do that manually, and the simplest way to do that is just to open each RAW file, immediately click "Develop", then in the Photo Persona export it to, say, a JPG or so, then offer the JPG files to Batch Job.

Just tried batch job. No joy. I can at least confirm that, despite being configured in the Develop Assistant, lens correction is not applied to any RAW files in a batch job. I have no idea whether any of the configurable default actions in the Develop Assistant are honored. Viewing the situation from the end of a forty-year career in IT, given the fact that macros that can be applied to batch jobs are created and run in the Photo Persona, then some minimal development -- to use Affinity Photo's terminology -- must be performed on a RAW file before it can be processed by any macros. One such minimal development might have been to (virtually) open the RAW file, perform any default actions, and "click Develop." Performing default actions configured in the Develop Assistant could be an option in Batch Job. As things stand now, it is unclear what Affinity Photo is doing to a RAW file that it encounters in a batch job before handing it over to the Photo Persona, and, above all, why it should be doing anything differently than when a RAW file is opened manually.

I can reply now to my own question. No, when RAW files are batch processed, any default processing configured in the Develop Assistant is not performed. At least, lens correction is definitely not. I don't know what other configurable develop defaults are ignored. Above all, I have no idea why they should be. It would seem to be such a simple thing to honor them in a batch job, or, at least, make that an option.

I apologize for asking a related question instead of offering an answer. If I create a batch job consisting of RAW photos, does the batch job "develop" them before manipulating them? By "develop" I mean, does it apply any default operations configured in the Develop Assistant (e. g., lens correction, de-noising, etc.). I understand that the macros that can be applied are created in the Photo Persona; however, when I open a RAW file in Affinity Photo, I'm taken by the Develop Assistant to the Develop Persona. So I would expect the same to happen "behind the scenes" when a batch job opens a RAW file, i. e., apply any default processing configured in the Develop Assistant, develop, then drop the result into the Photo Persona. Question: Does this in fact happen? Thanks

Oh, I hadn't noticed that. Must try it. Thanks.

Thanks for the reply. Other than the issue at hand, the results seem perfectly fine when I use the the RAW files directly instead of developing them individually first. I have the Develop Assistant configured not to use a tone curve and to apply color noise reduction. As far as I am aware, Affinity Photo does not support batch development (but correct me if I'm wrong). Thus, manually developing even a half-dozen RAW files could be rather tedious, even if the "development" consists only in opening the RAW file and clicking Develop.

Is there some reason why automatic lens distortion corrections that are applied to a single RAW file when the assistant is so configured, are not applied to RAW files that participate in File | New HDR merge... ? It would seem to be one of the more evident things to do. Now I find myself having to remove pin cushion and barrel distortion in a separate step. I am running ver. 1.6.7 on a Mac.

Thanks, @dominik. That doesn't seem to work with Apple's "no-button" mouse in the Mac version of Affinity Photo. I see that you have a Windows setup. For those who might be interested, for the last few iterations Apple's mice have had no buttons and no scroll wheel. The whole top of the mouse is touch sensitive and can be depressed. You simply use the mouse as if it had two buttons and a scroll wheel; however, It is not possible to "hold down" one side of the top while the other remains up and clickable. That said, it probably would be simple to implement appropriate gestures on the mouse for changing characteristics of tools that one operates by clicking and dragging, but I don't see any way of doing this in Preferences.