Richard Liu

Can we get confirmation from a developer on this?  After all, the Soft proof adjustment layer would seem to be somewhat useless without the ability to specify the same rendering intent for the print.

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.

Hi @MEB,
I believe it has to do with the fact that the BenQ SW271 external display is a 27" display that is operating (by default) as if it were a 32" one, i.e. at 3840x2160.  You might poll the users who have reported this problem and see what display and setting they are using to see whether there's a common thread.
Thanks,

Aha!  Thanks.  As you say, it's there in 1.8.6, too. I just wasn't looking under Adjustment.

@Boldlinedesign Why not keep the old Mac just for running things that don't have updates to Big Sur/M1, and get an M1-Mac for running everything else?

Here is what Thom Hogan (ByThom.com) had to say:
 

Chris,
I've uploaded a "bunch" of files.  The AFP file beginning with _DSC2980... has the behavior I described, i.e., slow to load the print dialog (64 sec.), slow to change the printer in the dialog (50 - 55 sec.) and slow to finish the print (64 sec. before the printing message disappears in AFP).
With the other files I have a problem with printing that I just discovered while timing it.  The timing in the print is OK (this is the one that is about as large as yours), but the printout is drastically different from what soft proof shows in AFP, not to mention how everything appears on the screen.  When I export to tiff then print that from Preview, the results very closely resemble the appearance in AFP on my display.  When I print directly from AFP, the result looks like the .pdf that I uploaded.  I produced it by printing to PDF in the print dialog, incl. specifying the ICC profile for the printer.  That is pretty much how the actual print from AFP to the printer looks.  In the AFP file you see at the top a group "Soft proof & corrections".  I use the stuff in here to soft proof with out of gamut stuff displayed, then use adjustments below the soft proof adjustment to correct.  I rarely need to use it, but the result was no different when I did this time.  The print didn't improve at all when I activated the group and the corrections but not the soft proof.  It resembled the print without the corrections.  What's going on?

About that size.  They're obviously too big to simply attach, but I could send you one if you tell me where to upload it.

@Patrick Connor Printing from Affinity Photo 1.8.3 is working as intended, and there are indeed differences between printing from Affinity Photo and exporting to, say, tiff then printing the exported file from Preview, even though the same ICC profile with which I am working in AFP is also embedded in the .tiff file, and both prints are being produced on the same printer with the same ICC printer profile.
However, as I report in https://forum.affinity.serif.com/index.php?/topic/116509-printing-in-183-excruciatingly-slow/&do=findComment&comment=632335, printing from AFP is extremely slow.  I assume that hardly anyone is using Print, or there is something wrong with my setup.  
 

Very generally speaking, the way to write software than runs on several OS's is to separate the device independent logic from the device dependent operations and, for the latter to create device-dependent services (subprograms) for each OS that are invoked from the device independent logic in a device-agnostic way.  This is likely less the problem than testing changes to those services to ensure that everything that invokes them still runs properly.  Many so-called regression tests can be automated -- indeed, good software is designed from the very beginning to be "testable" --, but those that cannot can be very time consuming to test, and are susceptible to tester inattention/fatigue.  Remember, too, that many services invoked by the software's are supplied by the purveyor of the OS, and some of them tend to make changes to their OS even after the final release candidate of a new version has been sent to developers.

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.

@haakoo,
Anticipating the day hopefully soon to come when printing actually does work -- presently, for all intents and purposes it is broken --, I export to JPEG or TIFF and print the exported file with Preview.  Yes, in general, something will be lost in the conversion, but it is not clear to me that rasterizing then printing with the broken print is the equivalent of printing with print as it is supposed to work.  If it were, wouldn't it be better to fix this problem by modifying print to first rasterize what needs to be rasterized, instead of placing the dual burdens of rasterizing and somehow also retaining the unrasterized layers on the user?
 
 

Seriously, I hope none.  I do not have Affinity Publisher, but I do rely heavily on Affinity Photo.  I am dismayed at how long some features remain broken, while others seem trapped in a cycle of breaking, being fixed, then regressing.  A long thread about compatibility with Apple Photos is an example of the former.  And it is still not possible to print directly (i. e., without merging layers or exporting to another format ... except PDF) an .afphoto that uses live filters. In my experience as a software developer for a major Swiss bank and a large Swiss pharmaceutical company, it is sometimes necessary to put new software and new features on the back burner in order to fix the foundations of existing products.  This would be a good time to do so.

Seriously, I hope none.  I do not have Affinity Publisher, but I do rely heavily on Affinity Photo.  I am dismayed at how long some features remain broken, while others seem trapped in a cycle of breaking, being fixed, then regressing.  A long thread about compatibility with Apple Photos is an example of the former.  And it is still not possible to print directly (i. e., without merging layers or exporting to another format ... except PDF) an .afphoto that uses live filters. In my experience as a software developer for a major Swiss bank and a large Swiss pharmaceutical company, it is sometimes necessary to put new software and new features on the back burner in order to fix the foundations of existing products.  This would be a good time to do so.

Seriously, I hope none.  I do not have Affinity Publisher, but I do rely heavily on Affinity Photo.  I am dismayed at how long some features remain broken, while others seem trapped in a cycle of breaking, being fixed, then regressing.  A long thread about compatibility with Apple Photos is an example of the former.  And it is still not possible to print directly (i. e., without merging layers or exporting to another format ... except PDF) an .afphoto that uses live filters. In my experience as a software developer for a major Swiss bank and a large Swiss pharmaceutical company, it is sometimes necessary to put new software and new features on the back burner in order to fix the foundations of existing products.  This would be a good time to do so.

I apologize.  The panel appeared on the laptop's monitor, not on the external monitor where the rest of Affinity Photo is running.

If I recall correctly, the cloning tool operates differently.  Even though one could argue that, by its very nature, a source must be selected, it does not just select, say, the upper right or left corner of the image, depending on the side of the road on which drivers of the locale configured in the OS drive.  If one attempts to click somewhere on the image without having used Option-Click to set a source, a very prominent warning from the Cloning Brush appears in the top right corner of the screen in addition to the still visible discrete prompt in the lower left corner.  There is nothing inherently "right" about selecting white; it would be "righter" to select the color of the color picker if one must be selected by default.
I wouldn't be making such a mountain out of this mole hill if it weren't for the fact that the behavior and even the wording in the Select drop down are so misleading that I spent lots of time trying to figure out what I was doing wrong.  After all, although the "..." in "Select Sampled Color..." indicates that I might have to do something after clicking the item, a selection immediately appeared, the Deselect did not work, and "Sampled" is, after all, past tense, so, I thought, perhaps I must first sample the color.

Thanks.  That works.  Pity having to jump through hoops just to find out whether one's question has already been answered before posting a new topic.

James,
Thanks for these new tutorials.
I find that I'm still not clear what I should do in the Develop persona that could also be done later in the Photo persona, as there is considerable overlap between the tools provided in the former and the more basic adjustment and live filter layers in the latter.
For a time I was just concentrating on flattening the image, having opened the RAW file without applying curves, e.g. pushing the black point a bit away from the left edge of the histogram, pushing the midtones toward the center, and recovering highlights, opening up shadows, etc.  Sharpening, clarifying, increasing contrast, etc.could be done in the Photo persona, after all.  But then I discovered haze removal.  It requires a pixel layer to work on, so it seemed to make sense to do some of the things in the Develop persona that I had intended to do later.  So now I am thinking that I should perhaps do some sharpening and perhaps introduce a curve during development.
I would find a tutorial on the theme, what should I consider doing in the Develop persona and what might I want to postpone for later, extremely helpful.

@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.

@mac_heibu,
I'm sorry, I didn't mean to ignore @TomM1's posts.  I took his last post to be adding to mine, i. e., I asked for a developer to confirm something, and he added something related that he would like to have confirmed.  Similarly, his post after my first in this thread, seemed to be an addendum to my argument, offering another reason why omitting support for rendering intent in the print dialog is curious, namely, that rendering intent can be set in other parts of Affinity Photo.

@Murfee,
Following your suggestion I checked which of the three sharpening filters is generating the most luminance noise.  In my case, it's the Unsharp Mask.  So I inverted it and just painted over roughly everything except the sky, then saved the Unsharp Mask's alpha channel as a spare channel, and loaded it to the other two live filters, Clarity and High Pass.  At that point, I really didn't need the Noise Reduction filter anymore, but if I wanted to use it, less than half the previous amount was more than sufficient to reduce the luminance noise that existed before sharpening.

I think it very useful to see what what James is doing on the keyboard as he shortcuts his way through a recipe.

Andy,
I was editing the message as you were replying.  In the meantime I have found that restarting Affinity Photo seems to clear up the problem of the "whacky" HSL control ... until whatever provokes this behavior recurs.  In the sense that I can still save my work and restart AFP, this is certainly preferable to losing work because of a crash.

There's something very wrong with the HSL control in this beta.  Here's a screen shot:

NB:  I'm still running macOS 10.13.6