Richard Liu

I'm not quite sure where to put this question, so, since it arose while I was trying to follow the tutorial on isolating layers, I'll post it here. On my Mac I most often have to option-double click where @James Ritson says to option-click when I use the Apple Bluetooth keyboard and mouse, but the same thing happens when I use only the MacBook Pro's keyboard and trackpad. In fact, very often I have to double click where a single click should suffice. I don't notice this behavior in another application. I'm running AFP 1.7.1.

@Murfee, For the better part of a week now I've been reconsidering my Develop-Photo workflow on the basis of yours. I've set RAW output format in Develop Assistant to RGB (32 bit HDR) and leave Blackpoint alone in the Develop persona¹. I content myself simply with addressing clipped hightlights and shadows and adding some details to the image, then develop it. In the Photo Persona, I apply Haze Removal to a duplicate of Background. Then, depending on the particular photo, I will usually work on a duplicate of either Background or the dehazed duplicate² in the Tone Mapping persona, limiting myself to either a reasonable adjusting compression and local contrast, or setting compression to 0% and local contrast to 100%³. Back in the Photo persona I then combine all the layers, choosing their opacities and blend modes to produce a pleasing, realistic result while avoiding the "burn your eyeballs out" effects typical of bad HDR. From there on, my work in the Photo persona is not much different than when I work in 16-bit RGB. I do notice that results have more "pop" than before, and the agreement between what is displayed on the BenQ SW271 calibrated to RGB, 100 cd/m², 5800K and gamma 2.2 and what is printed on the Canon Pro-1000 with the paper-specific profile provided by Canon is reasonably good. The Soft Proof adjustment layer still has its limitations, of course, and I do not find a clear statement from Serif about how it is handling out-of-gamut colors. If Check gamut is activated, pixels of out-of-gamut color are displayed in black. But if that option is not selected, are those same pixels displayed in the color calculated by Affinity Photo from the specified rendering intent, or does Affinity Photo simply pass the rendering intent to the operating system, in effect leaving the handling of out-of-gamut colors to it and the display? So thanks for your help. __________ ¹ That was a misunderstanding on my part. In a tutorial for AFP 1.6 entitled Salvaging Underexposed Images (http://player.vimeo.com/video/202715178/) James does adjust among other things the blackpoint of the RAW file and summarizes these endeavors collectively at 1:16 as "creating a very flat image" in an attempt to capture "as much highlight and shadow detail as possible." ² If haze removal has dramatically improved sky detail, I usually pass the Tone Mapping persona a duplicate of the original Background layer. If the effects of dehazing are more subtle, I apply Tone Mapping to a duplicate of the dehazed layer. I don't want overly dramatic skies in the tone mapped layer to dictate its opacity in such a way that the extra detail that I intended it to provide must be barely visible, lest the sky be too dramatic. ³ James' new tutorial, and his older one on bringing out water detail (http://player.vimeo.com/video/202899215/) are reliable guides to which tactic to use, depending on which of these two purposes the tone mapped layer should fulfill.

@BofG AD = Affinity Designer? This discussion is being posted in Bug Reporting > Report a Bug in Affinity Photo > Photo Bugs found on MacOS I find no such setting in Affinity Photo or the the macOS dialog that printing from the application initiates. If your replies pertain to Affinity Designer, I wonder whether they shouldn't be posted in a more appropriate forum? What do the moderators recommend? At any rate, and pertaining to the problem at hand, i. e., that live filters aren't being processed (properly) by Affinity Photo during printing, given the many blend modes with which they can be applied that greatly affect chromatic aspects of the final result, it is unsurprising that, absent such effects in the print, colors will be "waaay off." Regarding the tangent in which I vented my frustrations over what appears to be a reduced concern on Serif's part for ensuring that printing works properly, if indeed that is the case, I have no doubt that other Serif products will also be afflicted by it.

@walt.farrell No, you haven't misunderstood. I haven't made myself very clear. I rely on the soft proof to tell me what is out-of-gamut. Sometimes I will then add layers below it (not nested in it!) to bring those areas into the gamut of the printer profile that I have specified. When I do, I turn off the soft proof layer, leaving the correction layers on, then decide how close the result is to what I had when I wasn't worrying about printing at all. In order to make this iterative process more manageable, I group the soft proof and correction layers together, especially as, typically, I might have two Curves layers, one for RGB and one for LAB/lightness, and an HSL layer for lowering saturation and raising luminosity, and I am trying to decide which one(s) do the job best. In the end, though, I might decide not to correct at all. So, if that's what I decide, then of course I uncheck the whole group before printing. Otherwise, I leave the soft proof layer and any superfluous correction layers unchecked, but the whole group checked. I apologize for the confusion.

@Murfee, What bothers me is the extra manual intervention required before printing. It just creates other sources of operator error. As it is, occasionally before printing I forget to uncheck the group of soft proof and out-of-gamut correction layers, or, assuming I do not wish to apply the corrections, mistakenly uncheck only the soft proof layer instead. Using merge visible I have to determine whether an existing pixel layer so created is current -- yes, I know, the History tab! -- and remember to turn off all the layers below it -- not just in the interest of saving computing time, since we know that live filters in those layers aren't being rendered when printing or exporting to PDF, so who knows how they plus now the pixel layer created by merge visible will be. "Venting" a bit here, I wonder how regression tests missed something so serious as live filters not being printed or exported to PDF? In other threads that I read relating to discrepancies between what Affinity Photo displays and what it print, some contributors express views similar to this one by @BofG in this discussion: He/she replies Of course, nobody printing at home is expecting "pro-level print output," only accuracy within limitations imposed the available equipment. As @DianeF intimates, there's no reason to believe that Serif, with all the talent that it evidently possesses, cannot meet the high standards for print quality established by Photoshop. Perhaps it's time for Serif to taking printing more seriously.

Oh, wow! That's everything, then. I'm no expert user, but where else can a live filter be placed where they are neither nested nor sitting at the top level? So, in my example, even removing the grouping so that the highlighted live filters and three pixel layers below them pop up to top level, doesn't circumvent the problem. It seems that the safest course of action for printing with the least impact on a future when this bug has been squashed is, export to anything but PDF and print with another program, e. g., Preview on Mac's.

What I value about @James Ritson's tutorials: They're short, focused, and get right to the point. No introductory music, no self promotions, no solicitation for clicks. Even the 1.6 tutorials' introductory "Welcome to Affinity Photo" has been dispensed with in those for 1.7. And, as @LILOUBAE's post makes clear, the photos on which the techniques are illustrated are well chosen, seem to be unique for each tutorial, and remain in the mind's eye long after the recipe has vanished from short-term memory. Thumbnails of the photos used in a tutorial would therefore be a brilliant addition to the index in the first post in this thread. https://affinity.serif.com/en-us/tutorials/photo/desktop/ goes in that direction.

@LILOUBAE, I believe you mean this one: https://player.vimeo.com/video/155542288/ You can find the old tutorials here: http://www.miguelboto.com/affinity/photo/video-tutorials/

OK. I don't mean to be "dense," but I assume that live filters in the Background group in this example are not affected by the problem and will print, right?

@Chris B, All Live Filter layers that are nested in other layers? That would explain why some prints don't look quite right, given that I usually nest the sharpening live filters in the Background pixel layer.

Still more on this while waiting for some response from a moderator or developer. I tried turning off Metal, but that does not seem to solve this problem.

@Chris26, OK, thanks for your help. I think, like you, most of us live by the maxim, if it ain't broke, don't fix it, a corollary of which is, if it works, don't worry how it works. It's when things don't work, at least, not the way we expect them to, that our strategies diverge. Mine is to try to understand what components are involved, what each is supposed to do, and where the cause(s) of the problem might lie. I do not know Photoshop, have never worked with it.

@Murfee, I really appreciate your time. After reading your account, I redeveloped the .NEF file. I've made a screen movie of my developing steps. It's also on Google Drive: https://drive.google.com/open?id=1zkX5qqe1shqc2igAalTTEVzNNefsDwZc. 00:00 Load the .NEF into AFP 1.7.1 00:07 The Develop Assistant confirms that it has applied the +2/3 stops exposure correction that I dialed in on the camera. Clipped highlights, shadows and tones are displayed. 00:16 I begin to play with the Blackpoint. Usually, I push it to about -5% in order to create what @James Ritson in one of his 1.6 tutorials calls RAW latitude. You can see the veil appear as the slider moves below zero. 00:31 Pull the highlights down until they aren't clipped anymore. 00:41 Increase brightness. 01:00 Add a bit of sharpening. 01:17 The sharpening has evidently clipped some shadows and tones. 01:35 Just demonstrating which profile we're working in. 01:38 Opening the shadows up a bit to remove the clipping caused by sharpening. 01:51 Oops! Forgot to activate sharpening. Do it, then try to get a good setting for Shadows. 02:30 Check increasing exposure. Nope, that just blows out some highlights. 03:16 One last check before hitting Develop. Some tones are still being clipped, but I think that's OK. 03:26 I just noticed that I deactivated Details before hitting Develop! Dumb! But you get the idea, I think. So the veil is being caused by reducing the blackpoint. Now I've done everything all over again, beginning with a more careful development as per the above, except for the oversight at 3:26 (_DSC1411_AFP36_2.afphoto and _DSC1411_AFP36_2.jpg) In Photo I first dehazed a copy of Background, then ran that through Tone Mapping, adjusting basically tone compression and micro-contrast, then I recombined the original and the tone mapped, dehazed Backgrounds. I didn't see much point in adding more sharpening, but I did use the High Pass live filter to sharpen small details, e. g. the pebbles in the swing area and the leaves. Defringe was supplied selectively to the folded umbrellas and the pole to the left of the bear, lest even the little red bulbs be defringed and lose their color. After that things are pretty straight forward: Levels, Brightness/Contrast and Curves deepen the shadows and colors, then Vibrance and White Balance to adjust the colors, Soft Proof and Curves to address out-of-gamut colors. Basically, if the gamut check is deactivated, the soft proof is just somewhat lighter than the original. In fact, if I turn off soft proof and uncheck the curves adjustment required to address the out-of-gammut tones, and print, the printout is much lighter. One possible bug: The fringing that is selectively corrected with Defringe is very visible in the print and in the exported JPEG, but not when viewed in AFP at 100%. If you have time, can you confirm that this happens on your setup, too? Thanks.

@Chris26, Thanks, I didn't see the Header record. Yes, actually one can use the ColorSync utility to examine any of the profiles, so not only the ones for the displays, but also those for the printers, scanners, etc. Seems that they all say "Perceptual" in the Header, but I'm wondering what those entries with descriptions "Intent-i, 16-bit, device to PCS converter," and "Intent-i, 16-bit, PCS to device converter" do? I would imagine it's the printer driver that takes the colors that an application sends it and maps it to the color specified by the printer profile, and it would have to handle any rendering intent specified as well. The printer dialog is what pops up when you tell Affinity Photo to print. There, you specify the printer and the profile. It needn't be the same printer and profile that you specified for soft proofing, of course, since nothing even forces you to soft proof. So, taking the profile for my Canon Pro-1000 and the Canon Plus Glossy II paper as an example, I see that the header in the profile specifies rendering intent Perceptual. So if I give that profile to the Soft Proof adjustment layer and specify Absolute Colorimetric, how can it possibly honor that profile unless there's something in it that either supports that intent directly, or tells the application or print driver how to convert from Perceptual to it? In other words, why doesn't AFP give me an error message saying this printer and profile only support Perceptual? Now things get more interesting when I print, because, on a Mac there's nowhere in the print dialog, including all its submenus, where one can specify rendering intent. I understand that specifying rendering intent for printing is supported on Windows.

Your thruppence is much appreciated. I have opened some profiles and see variables with descriptions like "Intent-i, 16-bit, device to PCS converter," and "Intent-i, 16-bit, PCS to device converter," where i is an integer from 0 to 2. I was expecting something like "Relative colorimetric," "Absolute colorimetric," "Perceptual," etc. The problem is specifying the intent for printing, since the print dialog evidently does not support it. I assume that the printer driver then uses a default one, but which one is that?