Brad Brighton

So I'm mostly a Photo user (and abuser) but I have a hand in a craft brewery as well. With a limited release coming up, it was a good opportunity to try my hand at some design as well for some small-batch labels. I've done logos and such in other applications but this is the first time using Designer for something like this. It's predominantly assembly of components I culled from elsewhere (not a freehand artist here by any definition) and then utilizing AD to unify the look.

Hi @Chris B, turns out there's more to this than first meets the eye. Ensure that two or more files will be reopened on launch of APh -- one must be "large" (that is, will take some time to open -- in my test case, the large file is 9.55GB, lots of history) Open APh by double clicking a normal image file (in my test case, a random single-frame CR2 RAW file but I don't believe it matters) See the previously noted behavior of the wrong tab being selected -- select the newly double-click opened tab -- do operations on that file or not, it does not seem to matter Watch the large file load in the title bar -- when it completes, the first re-opened file is selected, regardless of the fact that you're currently manipulating the tab representing the newly opened file Curse vehemently if you were interrupted in the middle of some important manipulation

Confirmed that I do/did have Font UI Size set to Large.

I know there were issues in 1.6, then the beta, and at least one person finding that the glitches weren't just visual for him (the extra info was preserved in export) but in my case, it's currently still just a visual annoyance. Video screen cap attached. APh 1.7.1 -- Metal enabled, macOS Mojave 10.14.5, MBP2018 32G/i9/Vega20, external display: Cinema HD 30 via OWC Thunderbolt 3 dock+Apple Dual-link DVI to Mini display port adapter Screen Recording 2019-07-11 at 1.23.47 PM.mov

It would be handy IMO to be able to control the visibility (application) of one or more history items the same way layer visibility is managed (checkbox UI probably). Personally, as I experiment, I like to find out what I did caused which effect. Going back in history doesn't accomplish this goal fully as sometimes it's a specific action that generated the result, sometimes it's a combination. By being able to granularly "disable" previous actions, I expect to be able to refine approaches and zero in on capabilities more accurately, and critically, non-destructively. Split history is useful for some of this but requires re-performing actions that may or may not be deterministic in a user's memory. Snapshots require forethought and re-performing actions. Disabling the visibility/impact of history items would be additive to the existing tools. Yes, I'd expect the state of history items to be saved when "Save History with Document" is enabled.

That one is a bit baffling; maybe someone else will have some input? The only thing that comes to mind is maybe something with the printer driver -- that's where those options come from under macOS. Are you using a current/common printer or something a little more esoteric?

What I do (and I was surprised I had to do this in multiple steps originally but it's fallen into the "eh" category) is this: Modify the DPI by Document > Resize Document Change the DPI Uncheck Resample checkbox Click "Resize" Modify the size of the document by Document > Resize Document Change the Units value as desired Change the size to desired size in the selected units Change the resample method as needed Click "Resize" Print... You probably mention elsewhere, but not here: what platform? When I try this on macOS, I get visual changes to the preview as expected (and large borders) when I change the scale factor to, for example, 50%. Maybe post some screenshots or a screen capture video of your failure case?

Thank you much! First try failed... glitch during the upload, likely. Re-attempting.

You probably CAN successfully use all 7, @//iain but there will be more work involved to mask the overlap properly (another official video: https://player.vimeo.com/video/161038267/ -- I think this is a different one, focuses more on challenging alignments). Unless you're trying to get the specific benefits of overlaying the multiple exposures (in which case you probably want to look at the stack groups as well), it's generally a benefit to use fewer images as long as you have enough overlap. About 20% is the number thrown about on these forums often.

Hi @MEB, I'm curious -- did you follow the steps I outlined and did you see the same behavior? At the very least, the data loss is the list of open files. There may be more but I left it as unknown on the rest because it's not a user-visible thing the presence/absence of some of those pieces. As to "normal users shouldn't encounter this", first, I'd point to every request to be able to reinstall 1.6 here on the forums (several) as a possible candidate for running into this. Do I think a substantial portion of the userbase will be affected? No, probably not, but think of this straightforward example: since the file format is not backward-compatible, if you have two people, one on 1.6 and one on 1.7, working on the same project, the 1.7 user will need both apps. (Again, refer back to the requests to reinstall 1.6 for some of the reasons why the 1.6 user may be staying on 1.6 and not upgrading.) Relying on users to remember to quit out of 1.7 before opening the 1.6 file in 1.6 is blaming the user for what arguably could be considered an app failure. Please note: I'm not asking for the ability to run both simultaneously -- I understand at least some of the variety of reasons why that's disallowed. What I'm asking is that my 1.7 app state should not be impacted by the steps I outlined in the OP. Speculating, it looks like the open file list is updated only at the time it's changed (generally, a good thing) but the at-launch code updates it before the app has successfully completed restoring state. Since, in my scenario, I didn't make any changes that would force an update in 1.7, the partial launch of 1.6 wipes it out. It's way too easy (IMO) to induce destructive conflicts accidentally and honestly, it's a little dispiriting the number of issues there are with properly maintaining application state across simple error scenarios. Ultimately, this is less about the specific 1.6 vs 1.7 thing (that's just a symptom) and more a plea for additional developer attention to the ongoing integrity of both the content files and application state management. EDIT: Oh, and to answer your specific questions (sorry!): I made no changes during this process so there was no NEW data from the session for the app to ask me to save at step 4. No, I did not force-quit; there was no need.

Open APh 1.7.1 and ensure there is 1 or more files open Attempt to open APh 1.6.11 while 1.7.1 is open Get the 1.6.11 splash Get the alert that Photo is already running -- :-| "OK" the alert and watch 1.6.11 go away Quit 1.7.1 Relaunch 1.7.1 See an empty window Status of any autosaves or recoveries? Unknown. Why might this scenario happen? Comparing behavior on a given file of version over version Attempting to isolate behaviors reported in the forum (which is how I triggered it, trying to help out) Preserving project file compatibility in a mixed version environment Preserving project file compatibility with external services Accidentally launching an older version

Yes, I'll have to dig more into those, thanks. On first glance, seems to be a more heavy-weight solution (with attendant benefits as well).

You must not have seen people fumble with trackpads before... :-D Exporting, saving a copy, etc are all possible but are PITAs compared to "lock/unlock edit state" so that inspection is the only thing that can be done. I can just make a mental note about the history position too and undo until I get there or "revert to saved" (which should also be a one-step feature but isn't) but that doesn't (to my way of thinking) negate the usefulness of the feature request. EDIT: To be clear, I'm not talking about security from intentional changes; this is about blocking accidental/incidental changes caused by clicking, dragging, and otherwise fumbling through pan/zoom.

@haakoo That's a good workaround in the meantime, yes. Thank you. EDIT: One thing about that is that it does add non-productive noise to the history; what I'm envisioning would not (though technically, depending on how various things are implemented, that may not be avoidable).

The ability to label certain locations in the history would be cool. This would let the user define groups of actions and human-centric/human-readable known save points that could make the saved history even more useful without having to trial-and-error "where did I start working on that section of the project?" sort of thing.

I have occasion (as I'm sure almost all of us do) to show off work or otherwise review the contents of Affinity documents (Photo specifically in my case though I could also see it in each of the others) with non-users of the app interactively. It would be awesome, in my opinion, if there was a "lock toggle" that would disable any changes other than pan/zoom when enabled. My specific use case is to put others in front of the keyboard to inspect the results without having to worry about undoing whatever they accidentally do in the process of fumbling through the project.

Thanks @Old Bruce but playing with the visibility of the live stack does not resolve the issue. Even without walking the history, the file exports properly so I'm fairly confident the issue is in the screen rendering itself. As I said in the post though, I'm moving on with the production work since I was able to get past the glitch in a copy of the file but since my case appears to be reliably reproducible, I'm thinking the devs might want to explore how it got into that state (or at least understand the state it's in).

I have a 10GB .afphoto file (panorama, live stack groups) that managed to get into a "won't render properly" state (this is a recreation of the image that I'm blocked on because of a different crash issue). If I manually walk through the history (but not just any way, though it's not clear what the pattern is since sometimes the issue will clear up, sometimes it won't), I can get it to render properly as expected. After correcting the rendering, I saved as a separate file and am able to continue working on it however, the "original" continues to exhibit the brokenness so you (Serif) may want to take a look at it. (I'll need an upload link please if you do.) In one screenshot, you can see the transparent background and the blocky overlay -- the other shows what the corrected file looks like with no content changes, just re-playing the history. Attached a screenshot of the layers as well just for fun. Metal does not appear to be a factor on load+display because the same behavior on open happens with Metal enabled (my default) or using Software rendering (for testing/isolation). The screenshots of both were taken without Metal acceleration. The behavior exists on both internal and external display. macOS Mojave 10.14.5, MBP2018 32G/i9/Vega20, External display: Cinema HD 30 via OWC Thunderbolt 3 dock + Apple Dual-link DVI to Mini DisplayPort adapter.

It should do it, definitely. I have multiple vertical panos. However, I have seen misplaced components before when the content overlap was ambiguous -- in my case, it was with clouds/sky that could reasonably be interpreted to "fit" in multiple places.

So, with @//iain's permission and for the benefit of others, the first pass (to me) looked like too many images with too much overlap. When you have fine detail and slightly varying angles AND lots of overlap, it becomes quite difficult to properly mask for alignment. The original set of images (which I received directly) had 7 images -- selectively choosing 4 of them yielded better results due to fewer conflicts. The rest, so far, is a matter of adjusting contrast, levels, etc. that I'll let Iain describe when the forum allows his return tomorrow. :-)

@//iain I know you hit your new user post limit... so watch your email. :-)

It failed differently this time (more spectacularly). I received 5 of 7 the first time. If you just want to email the first two or try posting those individually maybe that'll get me a full set.

Thanks for the cross-check @emmrecs01! There's definitely something amiss in the file; unclear if it was during creation or transmission to the forum.

@//iain How strange. I haven't had this problem with the forums before but the zip appears to be corrupted. Files 1 and 2 appear to be mangled. It looks like 3-7 are intact.

Can't open the zip file -- how was it created?