Brad Brighton

Apparently what I'm looking for is already there -- the "Transform Source Image" tool (before applying the panorama render results).
What's the preferred way of closing the thread? Delete it or leave it with this declaration in case someone else is looking for the same thing?

Hi Brad,
Could you please send the file so we can try and recreate this?
https://www.dropbox.com/request/UKIzqc3eh9WR8DiGpVb0
Lee

Adding grain to a photo is a nice way to emulate vintage images, especially older black and white photos. It has always bothered me a bit that Affinity Photo does not include a mechanism to introduce grain, other than to use the “Add Noise” filter. While adding noise is nice, it adds such a fine amount of variation that it is often quite literally unnoticeable.
I have admired the Film Grain effect that is available in other software, such as Nik’s Silver Efex. These filters can often vary grain size and intensity; sometimes grain can be added to shadows, midtones, and highlights in differing amounts.
What I’ve attached is an .afmacros file called Film Grain. This is a macros Category and should be imported into the Library panel. It includes two macros. The first is called Add Film Grain - simple. It allows the user to add grain with 2 parameters – intensity and size.
Grain - Intensity
The grain intensity defaults to 100%, but can be set to any value between 0 and 100. At 0% intensity, the grain effectively disappears. To understand intensity, think “contrast.”
Grain - Size
The size slider accepts values between 0 and 1, with the default being 0.2. The appropriate value will differ based on the image being treated, and the same perceived size might need higher values when the overall dimensions of the image are larger. Also note that values above 0.8 are rounded down to 0.8 (and this forms an effective upper limit to the slider). This is done primarily because the math breaks down at higher values.
The second macro is called Add Film Grain - by tonal range. It includes the same intensity and size parameters, but also lets the user set opacity levels for highlights, midtones, and shadows separately.
Grain Opacity - Highlights, Midtones, and Shadows
There are three separate sliders for highlights, midtones, and shadows respectively. Each defaults to 100%, but can be set to values between 0 and 100. While the “simple” macro creates a single Film Grain layer, the “tonal range” version creates a group containing 3 layers, one each for the three tonal ranges. The Grain Opacity sliders simply vary the opacity of the corresponding layers within that group.
Finishing Touches
When each of the macros finishes, the Blend Range for the result (the Film Grain layer in the case of the “simple” macro, and the Group in the case of the “tonal range” macro) is set to diminish the effect of the grain on the highlights slightly. This is an aesthetic choice on my part, and I think you will agree. However, you can set the Blend Range to anything you might like, as desired.
*  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *
For most users, the “simple” macro will be enough. It lets the editor vary the Intensity of the grain and also the Size. I have always liked adding grain that was a bit larger, because it becomes more noticeable.
For other users, the “tonal range” macro will allow you to add some additional nuance to the grain, by letting you emphasize grain in the shadows, midtones and highlights. Do this by first setting a global Intensity and Size, and then adjusting the opacity of the 3 tone ranges as desired.
*  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *
Here are samples of the two macros, along with the settings as applied. The differences between the two results is quite subtle, but might be worth the effort in some cases.

*  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *  *
As with all the macros I have posted, I have tested these on one computer under a limited number of conditions. I cannot guarantee anything, but I have no reason to think they will not work for you just as they have for me. The macros are free, with the suggestion to “pay it forward.” As you become more proficient, be sure to share your experience and your work with others.
By the way, happy holidays to everyone. Here’s hoping that 2021 is a more positive, uplifting year than 2020. And maybe, just maybe, we’ll be able to ring in 2022 in a crowd without any masks!
Film Grain.afmacros

Thanks for that Brad,

It looks like it was trying to load a document on your machine and then crashed, unfortunately I can't say what document that was sadly! I'll pass the crash report on anyways.

Hi @Brad Brighton,
Thanks for your report. It's really doing poor job correcting it. I've logged the issue and passed the file to the dev team for further inspection. Thanks.
Did you notice similar issue with other images from the same or other cameras?

Regarding Photo Persona: If you set the RAW Output format in the Develop Assistant to 16bit rather than 32, the Chromatic Aberration filter does fix the aberration correctly.

On my MacBook Pro (9,1) there's a difference if I use ctrl-click or two-fingers-tap aka "secondary click":
ctrl-click behaves like in the video above two-fingers-tap displays the context menu everywhere as expected

Thanks @Brad Brighton. We are already aware of this issue. I've updated/bumped the report to bring it up to developers attention again.

Thanks for the file @Brad Brighton. Issue logged to be looked at.

Thanks for posting this. I'm glad I saw it. Now I don't have to restart to get the HSL dialog fixed... I can just move between monitors. I'm also on a dual monitor setup (MBP 16" over thunderbolt to Samsung C43J89x)

Hi Brad,
This is known to us. I'll give the bug a bump. Thanks for the reminder  

So...
I have an image that was imported from a PDF where I've been doing some color changes. When I first added an HSL Adjustment layer, all was cool. Left the tab open, went off, did other things... eventually back to the work at hand, double-clicked to modify, get the screenshot for the panel. Closing and reopening the editor panel does not change the behavior.
macOS 11.0.1 (intel MBP2018 15" 32G, 2.9 GHz 6-Core Intel Core i9, Radeon Pro Vega 20 4 GB, Metal enabled), Affinity Photo 1.8.6
A bug? Seems to be environmental in some fashion since closing the file and reloading from disk makes the issue go away.
ETA: This happened on a non-retina external display. I did not test whether it happened on the built-in display before reloading the file and the problem disappearing.
ETA 2: It has something to do with non-retina displays and/or moving the panel to the retina display causes a "corrective" redraw. Obviously, the condition re-occurred -- I moved the HSL edit panel to the internal display, the layout corrected itself, even after returning the panel to the non-retina external.

@Patrick Connor Confirmed that I can now see this item in the macro editor - thank you! macOS 1.8.4 
I assume the duplication displayed is legit and because I couldn't tell what was going on during the original macro recording.

Panoramas are produced from overlapping images - I can't see any way those images could be used.  If you create a pano from the left and right scans and deal with the text later you'll have better results.

Hi @Chris B,
Never mind. Looking at the timestamps of the images, it seems I'm erroneously including the scope image in the panorama (thanks for the hint from photoshop -- that might be an awesome feature request for Photo) and that's throwing everything off.
I have some others taken at the same time with the same level of haziness that are stitching properly.
As of now, please close this one as PEBCAK.

Hey Brad,
It looks like this is happening because the scene is quite hazy and there's no real sharp lines. For what it's worth, I get the same result in Photoshop:

It even seems to highlight the problem area.

I'll keep an eye out, thanks!

Hi Brad
We've fixed a bug that was probably causing your issue so you might want to try it again when the next beta is released, which shouldn't be too long.
Cheers
Justin 

Turning off Hardware Acceleration appears to have eliminated the image result corruption in the 1-test-pass-per-version (production and beta) against the same dataset. 

Thanks for all the info! I would really like to have a stab at this so I've made you a Dropbox folder:
https://www.dropbox.com/request/RVsCN94m1W3gHxyBOW72
Once the upload has finished, can you give me a nudge as I won't get a notification otherwise.
Thanks! 

@Chris B And finally, I can do a private upload of the folder of images (~13GB of CR2 RAW) if you want to attempt a direct repro.
More info on "why/what I was trying to accomplish": I was exploring the batch feature (only used it a few times previously), so I was attempting to make the functional equivalent of a JPG contact sheet (as opposed to the CR2 QuickLook I could already do).
I don't shoot RAW+JPG because I don't often want/care to process the entire shoot; I pick and choose. This time, I did the direct color batch, then used a batch on those results to get B&W results so I could eyeball what ones I wanted to "production process" and in what fashion.

Thanks. I misunderstood what you were saying.
I agree that if playing the macro sets that option, it should show as a recorded step.

Confirmed - thanks for the explanation.

Hi DeepDesertPhoto
This is the current expected behaviour, and this has been logged previously with our developers. I can confirm that when opening multiple files on Windows, Affinity will display these files in the order they're processed by the app, meaning they load asynchronously. Usually this is based on file size, as a smaller file will be processed faster - however this depends on multiple factors and occasionally a larger file may open quicker than a smaller file.
On MacOS,  they are loaded by user selection order. However, the load time differs for each document so they might finish loading in a different order - hence your documents don't appear in the same order they are selected/loaded in. 
As mentioned, this is logged with our developers and I've requested an update on this log as to if/when we may implement a 'logic' into file opening. I hope this helps!

I think @mpowell is a MS Windows user. Else he would have discovered Apple Keynote by now. By the way, it is available in the browser for non-Mac or non-iPad users via iCloud.com and includes many of the features available on Mac or iPad.
 

To get this out of the way, I do NOT work for Serif nor am I an apologist.
I'm going to dive in on this part only because it may be useful for any non-developers reading, either for this specific topic or generally.
App Store versions (both Microsoft and Apple) of any app are NOT identical to self-distributed versions of those same apps in two critical ways:
There is extra code involved to support the delivery of the app (security & receipt checking, etc) through the respective app store as well as potentially dealing with the environmental differences because of delivery method (see the next point). The "rules" of what an App Store version of an app can do by default are increasingly different than what a self-distributed app may do, predominantly centered around asset and resource access security. "What can you open?", "Where can you save?", "How do you talk to other apps?", "What hoops do you have to jump through to achieve a particular action?", etc. Neither of these is meant to be a "get out of jail free" card for Serif should there be bugs or uncaught misbehaviors due to restriction cases that weren't clear. However, the nature of software development is that the results are imperfect and the more variations there are of an environment, the more likely there will be errors that are only discovered "in the field". Serif, I'm certain, tests for as many of these as reasonable and when something breaks or is missed, works diligently to identify, isolate, and correct those issues.
Add in the nature of App Store business agreements (which effectively are determined by MS and Apple, NOT Serif) and it's understandable that some audiences may feel slighted when there are issues. It's unfortunate, both that those feelings are incurred and that the remedies are fewer for Serif when working with the App Stores but that's the state of the situation in cases like these.