Brad Brighton

@CallumIt's a one-off so far.

The app had been running for a while (mostly background as I was working on other things), nothing notable identified about the circumstances. Came back to the machine, up popped the crash reporter. File attached. Affinity Photo 2-2023-03-18-132522.ips

Done, including a fresh version of the crash log. Thank you and let me know please if you need anything else.

So far, this has been reproducible every time (4x as of this post). Crash attached. Original and afphoto files too large to attach but can deliver them if you like. This is a DNG created via VueScan, opened in AP2 and manipulated, saved. Original is linked, still in its original location (different disk), as well as a copy in the same folder as the .afphoto file Steps (when you have the files in question): * open the .afphoto file * select the background layer * click the develop persona button * crash immediately AP 2.0.4 / Mac OS 13.2.1 intel / MBP2018 / 2.9 6-core i9 / Pro Vega 20 4GB Affinity Photo 2-2023-02-25-195228.ips

This is a more comprehensive bug. In my case, hangs and outright crashes are when I'm trying to apply noise reduction to Canon CR2 files in initial develop mode. It's practically unusable at the moment for me. (Big Sur 11.16 / Intel) Yes, turning off all the performance enhancements seems to avoid the crash. However, just turning off using the discrete GPU does NOT solve the issue; one must turn off Metal entirely. 😐 Affinity Photo_2021-10-26-124138_SpamBook2018-2.hang

Given that the app opened normally (for all indications) immediately afterward, it's probably something that will be maddening to attempt to track down. 😄 Also, since I'm mostly in Photo, not Designer, it doesn't mean much one way or the other when I say that there have been no further similar issues.

Posting for documentation purposes since I have the crash report. * Launch 1.9.x (most current, I _think_) * Install and relaunch * On auto-relaunch, crashy * Manual launch after that seemed fine Affinity Designer_2021-08-05-072623_SpamBook2018.crash

Hi @Sean P Sorry, I lost track of this over the week. Here is what I have. -brad 2021_cc_rally.afdesign

The only thing I did that's unusual is dragging the width of the studio to be able to see the dimensions I'm typing in. I had entered values into these fields prior to drag-expanding. The first variation seems to work ok, the second on these slices does not. macOS 11.4 (20F71), AD 1.9.3, MBP 2018 32GB/Radeon Pro Vega 20, external monitor. * moving the AD editor window to the main screen does not make the problem go away * Shrinking the studio does not make the problem change (though I don't know what the exact original width is) * Resetting Studio lost my values in that variation but did not set the editing field back to the full visible width * No, I haven't tried to repro this from a clean start (yet) because I'm trying to get work out under a deadline * However, deleting that variation and adding another for the same slice while the studio is expanded *does* allow proper editing. Screen capture of the oddness attached. Screen Recording 2021-07-17 at 4.16.03 PM.mov

Attached are a CR2 file and a movie showing some rather poor (and to this point, highly unexpected) behaviors attempting to adjust for chromatic aberration. Develop assistant and Performance prefs also included. It's possible that the whole situation is a trick of the light, as it were, and simply a situation the app can't handle well but take a look and see if, especially the "estimate from image" behavior, this is what you'd expect. APh 1.9.1, macOS 11.2.2, MBP2018 ETA: The video is obviously in Develop. The "even worse aberration" case can also be generated by applying Filters > Colors > Chromatic Aberration in the Photo persona after developing. Screen_Recording_2021-03-10_at_7_28.07_PM.mov _D7A4697.CR2

FWIW, confirmed on my side too. Since I most often use a wireless keyboard and Magic Trackpad, I rarely use the two-finger click (intentionally). In fact, I'm not sure when my settings were changed from click-on-the-right of the trackpad back to two-finger click. Don't worry, I don't blame Photo for that. Now that I'm paying specific attention, it seems ctrl-click is treated just as a click. Odd.

In the on-again, off-again world of "will my archive be read properly?", I've found at least one image from a 2006 session that won't read the EXIF correctly. At least some of the others from that same session read fine (I haven't done an exhaustive test against every file). Attached are the original CRW and various bits of info showing the state of "unknown" though the Finder reads it fine. MacOS 11.2.2, MBP2018, APh 1.9.1 CRW_9088.CRW

This may happen elsewhere too but this is the first time I've encountered it. If you click along the area (likely) covered by the name label, the context click (right-click or control-click) does not work. Click in the small area above or below the label, and it does. See attached video. This happens both on internal and external screen so does not _appear_ to be another retina-vs-non-retina behavior. macOS 11.2.2, APh 1.9.1, MBP2018 Screen_Recording_2021-03-05_at_8_50.51_AM.mov

Attached is a crash dump in case it's useful for you. Hard to describe the state of the environment in detail because it had been running for a long time -- lots of large files, lots of tabs open. I was in the process of closing now-unneeded tabs (some just closed, some needed mods saved) when the crash occurred. I couldn't actually tell you what tab was active but I do know it was neither the oldest nor the most recent tab open, so no magic there. I don't expect you to come back with any answer (though if this fits a known footprint, knowing would always be welcome) nor do I expect this to be reproducible in any realistic fashion. I do expect that this will be reviewed in case it adds context to other reported crashes. Thanks! Affinity Photo_2021-01-24-093844_SpamBook2018.crash

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.

FWIW, I'd also be curious (on the suspected behalf of someone troubleshooting this) whether those shadow-elements (for example. the sliders on the right incorrectly appearing inside the Layers panel) are functional or simply visual artifacts. It would mean different kinds of errors behind the scenes if those things that are in the wrong place are functional or not. Separately, if you purchased from the Affinity Store, you should be able to download older versions directly (link culled from other support posts: https://store.serif.com/en-us/update/macos/photo/1/). If you're using the Mac App Store version, you're stuck.

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

@Justin @Chris B @MEB Recreating the test with Beta 1.8.4.186, Metal accelerator on: Crash: NO Corruption: NO (at least none seen through my 2x QuickLook scan of the 487 images, the same visual scan that easily found errant images in the past) Looks good.

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.

So, I have an admittedly challenging panorama I'm trying to stitch. It is from Pike's Peak, CO looking over the valley so the features at a distance can be very similar. On my 9-image stitch, it always puts what should be the left-hand border in the center, and goes from there. I've tried cleaning up the component frames a bit (and exporting to EXR) to enhance the detail but either I haven't done enough cleanup or it's not helping. I currently consider reliably mis-ordering components (even in a challenging composition) a bug. What I'm looking for (aside from a magic fix ) would be some suggestions on what is actually causing it (in order to avoid it in the future) and if there's a way to force the linear order because I haven't found such (re-arranging frames with drag+render doesn't change the canvas size and thus requires too much fiddling with every component frame). This specific example photo set is from 2010 and isn't that great so there's no particular damage done here except it's a convenient repro case for the stitch failure. Files attached (along with screenshots of the stitch attempt -- I haven't bothered saving any broken results yet). Attempted with both 1.8.3 and 1.8.4.184 with no noticeable change in behavior. CRW_1400.CRW CRW_1401.CRW CRW_1402.CRW CRW_1403.CRW CRW_1404.CRW CRW_1405.CRW CRW_1406.CRW CRW_1407.CRW CRW_1408.CRW

I'll keep an eye out, thanks!

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.

Glad to help. If you need additional info, just ask.

@MEB @Chris B Results: External source, internal destination Environment Change as requested: Noise reduction = "Take No Action" Beta 1.8.4.184: Crash = NO, Result image corruption = YES Production 1.8.3: Crash = NO, Result image corruption = YES I have to say, this surprised me. I had pretty much assumed the corruption was a function of the crash during parallel processing but now it looks like they are separate issues.

Hi @Justin, production, beta, or does it matter? Also, it's currently set to "color reduction" -- you want it set to "Take no action"? On a side note, has that setting always been there? Thanks for pointing it out -- it looks like I have more configuration to do to turn things off.