Brad Brighton

Understandable. The reason I was asking (and would be relevant if you encounter it again) would be to attempt to differentiate between a file-system/local-environment-induced error and an app-internal error that may be hiding behind that error message. If you can't save anywhere, for example, that pretty much rules out a genuine permission error unless the disk is full (and even then, the error message would be misleading). If you could save some places but not others, that tells a different story. While I was writing this, the idea of the sandboxing comes into mind a little stronger; are you running the app purchased directly from Affinity or via the Mac App Store? I have less experience with the macOS sandboxing side of things but unexpected lack of permissions sure sounds like it could be related.

Interesting that APh is not listed under "Photos" for Privacy security. That may only come in if you try to use APh to edit out of Apple's Photos app. At least it's not "listed but not checked". No smoking guns there, I'm afraid. What was the result of attempting to save to the Desktop, if I may ask?

The suggestions here are less about "it's this problem" and more about gathering info: Is it trying to overwrite a previous version of the file with the same name and failing to bring up the "replace" flow? If you "Get Info" (Command-I) on each of the folders in the hierarchy, what do they have for permission on the folder? If you ARE trying to overwrite a file of the same name, what does "Get Info" show for permissions there? Are you able to pick a different destination and save it correctly there (the Desktop, for example)? Do you have iCloud "Desktop and Documents Folders" turned on? You can check this under System Preferences > iCloud > iCloud Drive Were you ever requested "Affinity Photo wants to access your Photos" and told it no? You can check this under System Preferences > Security & Privacy > Privacy Tab, Photos (in the sidebar)

While this is technically true (the development distribution certs expire annually), if you've developed the app in the first place (or are enough of a developer to side-load someone else's app by building it in Xcode and installing it on your device), the reality is that you're talking about 10 seconds of effort each year to "renew the cert and rebuild", especially with the automatic certificate management that removes much of the former pain-and-suffering that used to be there. If that's enough of a detriment/annoyance to prevent such a path, ok. (NOTE: If you're thinking about the 90-day expirations of TestFlight builds, that would not apply to you as a developer and devices registered as development devices -- that's for "external" testing and yes, the requirements there are, among other reasons, to prevent circumvention of the App Store. If you're thinking about Enterprise Distribution, some big names recently were caught abusing this program but it's yet another way to get apps into the hands of users in a defined environment without "going public" through the App Store.) On the primary topic of building a for-profit app for Android, the business cases are really difficult to make in general; in specific there may be niches, but issues surrounding willingness to purchase, piracy, security, fragmentation, and privacy all are predominantly negative in the Android world vs iOS. I have multiple apps in the App Store and never-say-never but there's currently no compelling reason to invest the development effort on that platform and I've been watching for at least one business for almost 5 years; the landscape simply hasn't changed enough to make it worthwhile.

@RobinMcL Keep checking for print shops; look for sign and commercial printers as well, not just photo/art printers. Using some estimates from a large-format shop I get some stuff done with here in Reno, 4'x5' would be about $120 per so while that may still be high for you, it's a lot lower than the quotes you mention.

@Patrick Connor, thanks for looking out for the people who have not yet gained the institutional knowledge of those who have been here forever! My only comment does echo some of the others though; since you appear to have control over the styling of the abbreviations, perhaps use multiple styles simultaneously to negate the link-similar behavior? strong+em maybe or give the span an enclosing border instead of just below/underscore? It won't bother me if you don't. If the options are keeping it as it is or ditching it, keep it; the benefit even as it is will be outweigh any inconvenience. However, if you can tidy it up just a bit more, I think it would further amplify your intent. Or, I guess you could turn it into an actual link, no? Point them to a page listing the abbreviations so that if someone is curious enough to click (which should also satisfy the "no tooltips on my browser" crowd) they can learn about all the different approaches to these names.

Is posting the image necessary? Not strictly; someone may be able to play a 20,000 question guessing game about what might be wrong and stumble across the right combination, but that's a low-percentage option for success. The higher likelihood is that by looking at the file and doing an export using your file, where the difference lies can be quickly identified and help you in a more concrete fashion get to the results you're desiring. Posting to IG means that the details you're talking about are unlikely to matter, but that is definitely only a personal opinion, and as they are your photos, yours is the only opinion that truly matters. At this point without a representative file, there's less of a chance that someone will be able to help. EDIT: Or maybe someone will recognize the specific scenario and dive in. :-D

Now, after your example, there are still other factors like what profile your monitor is set to, whether exporting as sRGB is sufficient, and of course, what you intend to do with these image files once they're exported. If you're going to incorporate them into print, for example, the conversation changes again -- not in tone (you still need to do the same basic behaviors) but in detail (the specific settings may change). So, what is the purpose you're processing these images for? (And don't forget to post an example file that you saved out of Affinity Photo -- the one with the afphoto extension -- and tell us what computer, OS, version of monitor, etc you're running)

APh is shorthand for the Affinity Photo app (as opposed to, for examples, AD for Affinity Designer or APub for Affinity Publisher). afphoto = the extension file that you save directly from Affinity Photo, as opposed to the JPG (for example) that you get from exporting.

That's a sane start but there are other variables that could complicate the situation, such as what you've changed along the way in the native APh files, both intentionally and "randomly" attempting to solve the problem. If you want to try setting the export profile to sRGB first and testing your satisfaction with the result, that's a good first step. If subsequent steps are needed, you'll be best served by posting the afphoto file(s) here so forum denizens have an opportunity to look a little more deeply into what your current state of affairs is.

Ok; the layman's summary of what you're about to learn: different color systems have different colors that can be shown (RGB, CMYK, etc) different devices have different abilities to show color regardless of the mathematical color identifier (various monitors, printers, etc) applying and when necessary, converting, between the profiles helps you get the closest match from one device to another (and from one file format to another) improper applying of profile (or applying when conversion is necessary) is a dominant (though not exclusively the only possible) reason for the kinds of mismatch you see

On a second pass (and digging out the macOS Color Meter), yes, I can see a difference in the foliage -- the JPG is a little muddier. I would expect that since you're 16-bit RGB inside Photo (see: RGBA/16 near the top in your screenshot of the bird -- though you're using RGBA/8 for the ant... are you intentionally changing these and if so, do you understand how and why?) and probably exporting to something other than that for the JPG. Has anyone pointed you to this yet? https://affinity.help/designer/en-US.lproj/index.html?page=pages/Clr/ClrProfiles.html?title=Color management EDIT: Looking at your previous thread, yes, you're already being walked down the color profile road. It's just that no one other than Serif has jumped in yet to help and the forum can be quite busy at times. EDIT 2: Just realized the link was for Designer -- similarly, here's the Photo link: https://affinity.help/photo/en-US.lproj/index.html?page=pages/Clr/ClrProfiles.html?title=Color management

May I suggest you add a link in the post to your prior discussions? That may save anyone trying to help you from reinventing any particular wheel. Not having that info and given that the images actually look the same to me here on the post... my first thought is about profiles (image, conversions, monitor). Have you gone down that road yet?

You have me in a mis-wording there. Change WILL to MAY. And I suspect from a technical aspect, the specs of the brushes define the maximum bounds (allowing that in the cases of most entropy, the effect applied may go from zero to the bounds and may be non-deterministic as to where within those bounds any given effect will be applied). If the bounds of some extreme brushes are the full document (in which case brush width would be a useless attribute) so be it but I would also wager that those are edge cases (pun not intended) and that most brushes, by definition, have a finite maximum bound (even if it's non-obvious to a human observer when the interactions of sub-components are computed in compound groupings) regardless of any variability within that maximum. If the argument is that there is no way to predict the largest possible region for the effect of a brush (compound or simple) to be applied based on settings that demonstrably change the effect, we'll have to agree to disagree until and unless additional technical information proves otherwise. From everything I can see, the maximums are deterministic even if the current values are not. Now, if the argument is that you do not see the utility in demonstrating the bounds I describe, that's fine; we each have different approaches to our work and different needs within a generally describable workflow. It will (obviously) ultimately be up to the Serif folks to weigh the utility and difficulty of implementation of what I describe against the infinite list of other demands. :-)

@R C-R Knowing the area to which an effect will be applied is my wishlist desire. I fully understand that how much of an effect within that area may be applied may vary, sometimes greatly.You're attributing intent to me that I do not describe (unless I mistakenly did at some point -- show me where and I'll correct it. :-) )

I had not considered that but nowhere in the declaration that you quoted (though I did indeed use 'circle' in other instances) did I say it had to be a regular region. The analogy holds though; if the app can demonstrate any bounds (which it does) it can know what the outer bounds are as well. "Unpredictable" behavior (or "predictable but only with magic knowledge") is less useful than "clearly predictable". EDIT: Even for brushes that have an element of random set to them; an outer bound of effect (other than canvas edge) is surely known. EDIT 2: As far as discontinuity within the bounds, I don't think I care (for the sake of this particular discussion), only the maximum effect bounds.

Thanks for bearing with me... I finally understand (I think) where my misunderstanding lies. Apparently I am more focused on the task than on the exact size of the white bounding circle because it indeed does change with relation to hardness. It took setting up a video and comparing directly for me to realize this. As a general statement, you're already measuring it, to my mind, when you decide what the new representation of the bounding circle on the screen is. I can't say I know of other software that does differently as I've never noticed the need to look this closely before and even if it does behave differently than other software, now that I realize how THIS works, can deal with it. If changes were going to be offered though, I'd go one of two ways; the first (and likely the least intrusive to existing behaviors) would be a second circle that marks the true outside bounds (the end of the feathering). The two circles would be the same size at 100% hardness and diverge from there. The second of the two ways would be a user-selectable toggle (current behavior should be the default) that turns the single bounding circle into a true bounding circle, always representing the outside edge of the effect of the brush. My ultimate wish is to see a visual demarcation of the bounds of the effect even, (or especially) in the case where the changes may not be noticeable on the particular monitor or to a given set of eyes even though modifications are being made. THANK YOU for all your help and I apologize for being "that person" this time. I'm considering this thread completed unless there's something useful to you to continue it.

Hi @Chris B, I do apologize for being obtuse but my American English reading of your comment confuses me. Maybe we have a terminology thing going on here? When I describe the bounding circle, I refer to the white circle whose width can be set in a variety of ways. When I describe the _effect_ of the brush, it is outside or inside of that circle. When you say, for example, "the brush stays the same and the circle gets smaller", the white circle (see my definition above) does not change size visually (except when I specifically change its width), even though the visible _effect_ and the reach of the tool (inside or outside that circle) does indeed change on changes to hardness. Thanks for bearing with me... are we saying the same thing just in different phrasings?

So in the process of getting into the nitty-gritty of making sure everything was equal for the video, a few things are becoming clearer: The bounding circle may or may not actually delineate the bounds of the effect (dodging in the case of the example I'm testing) Hardness at 100% does bring the effect within the bounding circle. As the hardness is reduced, the core effect zone shrinks within the bounding circle while the external "corona" if you will grows. Opacity and flow each impacts my ability to determine whether the effect is being applied or not, both in actual application as well as preview mode (as would be expected) The differences I noted between 1.6.11 and 1.7.2 are probably explained by different settings in the opacity, flow If these described behaviors are as expected, then I guess we're done on this thread. I figured it was something about me; that's why this is here, not in the bug threads. If these behaviors seem off in some fashion, perhaps more investigation is required.

Hi @Chris B, Thanks for weighing in. I re-tested before I posted my most recent followup so I'll see if I can put a video together for it. I don't know if I'm misinterpreting what I'm seeing or what, but I feel like I'm definitely seeing a difference in behavior between the two versions.

@Lee D Is this an intentional behavior change in 1.7 because with the same settings, 1.6.x honors the bounds as a maximum (that is, hardness takes the effect UP TO the bounds but not beyond it). 1.7 seems to treat the bounds as a minimum effect, not a maximum.

Hi @Lee D, Bingo - for part of this. Thank you. "Enable EDR" was on; "Show EDR Clipping" and "Prevent display tone-mapping" were both off. And no, this display is not EDR. The remaining question: does this also explain the action outside the brush circle or am I misunderstanding the bounds of the brush? Shouldn't its effects be limited to a maximum of that bound?

I'm sure this is something I'm doing/misunderstanding but I haven't figured it out yet. Anyone care to share some insight? The attached video shows a zero hardness, low flow, attempt to dodge the shadows of an image but when I get anywhere close to the highlights, weird things start happening, such as: the effect of the brush is applied outside the bounds of the brush the effect of the brush is applied to areas specifically outside the selected tonal range the effect of the brush has an unexpected result The things that appear NOT to change the behavior: Changing the tonal range Changing protect hue Changing the brush size (it still impacts outside the visible bounds of the brush) Thoughts? Affinity Photo 1.7.2 Production, macOS X Mojave EDIT: Added a screenshot of the image details Screen_Recording_2019-09-09_at_5_00.57_PM.mov

Could you post a concurrent screenshot of the colo(u)r tab configuration?

Without seeing the images in question, it's hard to tell. Since you describe it as a storm, I'm going to guess that there is either not enough overlap in critical areas or the overlap that is there is ambiguous -- likely in the cloud formations which tend to be self-similar. I've had some cloud-centric panos fail in similar ways. If you want to post your files, one or more of us can take a look in deeper detail to attempt to answer whether it's the images, the software, or you. :-)