Brad Brighton

Post it here if you don't mind the public nature of the forum. If you prefer it to be private communication, my email address is bbrighton at the domain in my post signature.

@//iain One thing I've noticed with Photo is that if your RAW files need attention, give them the develop treatment before stitching then save as EXR for further processing/stitching. Also, do make sure your Develop Assistant settings are what you want them to be -- View > Assistant Manager... then click Develop Assistant. Since I don't use Lightroom, I can't give you any one-for-one suggestions but I've done LOTS of panos using Photo and the things I've suggested so far have helped me control the topics you've brought up. Certainly doesn't guarantee your success though. If you want to post a zip of the originals, I'd be happy to do a stitching on my side for you to compare whether there's any improvement (not to show off my skills or anything -- this exercise might let you know if it's more about the practice with Photo or its capabilities/lack thereof).

@//iain These will be helpful in stage 2 (the cleanup): https://affinity.help/photo/en-US.lproj/index.html?page=pages/Panorama/panorama_stitching.html?title=Stitching panoramas https://affinity.serif.com/en-gb/tutorials/photo/desktop/video/332168133/ For the initial stitch, part of it will depend on the overlap of the component images, part will depend on what your settings are in the assistant. I've seen those smudges before -- check out the linked help[ and video and see if it doesn't make things better for you.

@Chris B On the hang, all I can say for certain is that I've only encountered it twice and both time were in the context of having an undeveloped RAW file during the process of isolating the details for this post. By hang, I mean: beachball unresponsive once (the second time), unclear if I had that the first time or not since it caught me by surprise. When I get some spare cycles, I'll see if I can reliably repro for you.

@Dr. Dave For #2: Making a child layer is one of the options. When you drag there should be a visual insertion point that should tell you whether you are inserting within or moving below.

Quitting when in "Hide UI" mode means having to manually restore the state on next launch Open APh 1.7.1 (I have images that are reopening -- not clear if that's required or not) Tab for "Toggle UI" to turn off all the frobs Quit ISSUE 2: Note that I've had hangs in this point (multiple minutes requiring force-quit -- usually when I've launched APh via opening a CR2 raw file then, for the sake of testing, canceled development) Relaunch APh - see it come up with minimal UI Toggle UI -- see very little happen. Studios, context bar, tools, and toolbar all have to be manually restored to visibility Photo 1.7.1, macOS Mojave (10.14.5), MBP2018 32G/i9/Vega20

One last bit -- please note that when it comes to translating the "turn off metal" responses, these are my suppositions and assumptions based on interacting with Serif support for several months. I'm not part of Serif nor do I speak for them (not that they would want me to anyway )

@Cecil I guess my point ultimately is twofold: first, it's a complex topic to handle across time snd second, complexity leads to bugs for even the most diligent. As far as a common refrain being to turn off metal support, I suspect that's as much a workaround as anything, though the lack of spelling that out can come across as it being "the solution". I always take it as a "let's see if this improves things and if so, we (Serif) will look into it further while the [bug | crash | misfeature] is better behaved in the meantime.

I don't know how Serif has implemented things but Metal support is not monolithic; it's actually varied and complicated. Check out this Metal 3.0 (and yes, there are Metal 1 and 2 as well) feature chart; you don't have to know what the details mean. The complexity point is supported by the horizontal columns and the mix of supported/non-supported for the rows. https://developer.apple.com/metal/Metal-Feature-Set-Tables.pdf

FWIW and all that... The image you posted isn't the one in the zip so it's hard to genuinely compare. However, taking your designer file and exporting here (macOS Mojave, AD 1.7.1, to PNG in this case) shows no noticeable difference (to my quick review anyway). That would seem to put the issue either into something you're doing at export that's different or a display config that may be impacting. Edit: so, while I am arguably an idiot (the thread talks about Windows, after all) perhaps this cross-check will still be useful?

Hi @MEB, Is it possible to convey the reaction behind the scenes to this on a scale of "that should be easy" to "that's not supposed to be able to happen in any multiverse?!?" I understand it can take a while to triage and investigate even in isolation, much less with everything else going on,... any guide at all on expectations to workaround and/or fix would be awesome though since this project (and the real money attached to it) are on hold currently. Thank you!

At this point, I think we're veering into arguing personal preference rather than platform standards so I'll leave my piece of it as this: I don't disagree with what you say above, I just believe it's incomplete for the bigger picture (that is, for some set of people who are not you :-) ). Moving on?

That would be an awesome addition too, IMO.

@R C-R Genuine question: Since long-press is the default method of bringing up a context menu on iOS/iPadOS (akin to ctrl-click on the Mac, which I've shown Apple still considers the default there) if that didn't work because you had a multi-button mouse plugged into your iPad and could therefore execute a secondary click with it, would you hold the same position that this would be a feature request?

Too many people seem to think that the suggestion is to turn it on by default for everyone. Speaking only for myself (since that's the only person I can speak for), that's not what I'm saying. What I want is a checkbox in preferences that is disabled by app and user default, that says "Save History with Document" that I can turn on (once) and from that point forward, the functionality is enabled for every file I open until I manually turn it off per file or uncheck the preference which would take the behavior back to the currently available functionality. If anyone in the multiple discussions is arguing that "Save History" needs to be turned on for every user, I haven't seen it.

@R C-R I do see your point but I fall on the other side of the line on this one. I think that given both that there does not appear to be a toolbar-centric override going on with APh AND that other Apple documentation sets the user expectation that ctrl-click AND any user-defined gestures should invoke secondary-click, it's a bug of omission. I also recognize that I'm very much a stickler for platform correctness when there's not a good reason to deviate; platform consistency has been and (to a lesser extent) continues to be a key differentiator of the macOS (& iOS/iPadOS) productivity philosophy versus alternatives. I don't consider deviation by accident or omission to be a good enough reason not to put this on the list to be addressed. At the same time, I also recognize that in practical terms, this is certainly not the highest priority. ¯\_(ツ)_/¯

Ha! True. Still...

@Old Bruce Whoa... that's an interesting UI choice to make the develop/cancel buttons optionally visible. :-| (The rest of the details I can understand...)

@tbransco DNG (like RAW) invokes the Develop persona. You're seeing the expected results; to get to the Photo persona, click "Develop" in the top left (this is what the quitting dialog is telling you -- Cancel or Develop before progressing -- even when progressing is quitting).

Having the option (read: preference) to be automatically on would make some peoples' workflows less error-prone (as some of us really do turn it on for all but the most trivial of efforts). So... I'll vote (again) for having the choice of turning it on for every file by default and of course, allowing it to be turned off in a case-by-case basis.

@R C-R As far as ctrl-click being a relic, here are current links from Apple's support docs pointing out that the expectation is that ctrl-click is a way of performing a secondary click. https://support.apple.com/guide/mac-help/right-click-mh35853/mac https://support.apple.com/en-us/HT207700 Yes, it also highlights the default alternatives as well that involve gestures or device-specific support but that's in addition to, not in place of.

It's not a relic -- it's still true. The Finder (arguably the canonical macOS app, works with both). As a developer myself, I understand the conflicts that sometimes come up (and in fact noted this in my specific bug report that there doesn't seem to be any override going on here, it's simply missing). Quoting Apple's current HIG (https://developer.apple.com/design/human-interface-guidelines/macos/user-interaction/mouse-and-trackpad/): If there's an Affinity-specific override here (and maybe there is, and a good reason for it to boot) it's not obvious. Anyway, The discussion of behaviors is, ahem, overriding, the main point of the OP. If it makes sense to continue debating conformance of interface design to user expectations, let's do it on the bug thread. :-D ( )

CTRL-click in the toolbar does not bring up the contextual menu for customizing the toolbar. The "secondary click" gesture as defined in System Preferences does bring up the contextual menu. This is inconsistent and unexpected behavior compared to other macOS apps and it's unclear what, if any, conflicts there would or should be with APh-specific behavior in the toolbar to warrant overriding or disabling CTRL-click.

@R C-R Interesting. The behavior is only partially implemented, it seems. You're correct that if you use the defined gesture (see below), it does work. HOWEVER... CTRL-click is supposed to be the same as right-click (actually "secondary click" in Apple's UI parlance). With the external keyboard, I almost never use the secondary-click gesture (two finger click on a Magic Trackpad in my current setup) and wound up quite frustrated by the omission. Time for another bug report and thanks for the additional info!

I cannot correlate to Publisher but add me to the list of people who had issues with the toolbar on moving to APh 1.7 (production). I had not customized the toolbar (that I recall) and definitely had not removed the shortcut to color/white balance/contrast/levels but it was missing for me. I specifically remember this because I had to discover where the "customize toolbar" functionality resided since the default macOS way of invoking (ctrl-click in the toolbar itself for a context menu or cmd-click to rearrange) are not present.