Jump to content

Brad Brighton

Members
  • Content count

    225
  • Joined

  • Last visited

About Brad Brighton

  • Rank
    Advanced Member
  • Birthday 04/30/1968

Contact Methods

  • Website URL
    https://bmb.photos

Profile Information

  • Gender
    Male
  • Location
    : Nevada, USA
  • Interests
    Stretching boundaries (literally) with extreme stitched panoramas, capturing light in all its forms, software development, team and business coaching, and a few other things that seem even more completely out of place in this list.

Recent Profile Visitors

373 profile views
  1. @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.
  2. 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
  3. 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)
  4. 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.
  5. 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.
  6. 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
  7. 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
  8. 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?
  9. 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. :-)
  10. @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. :-) )
  11. 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.
  12. 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.
  13. 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?
  14. 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.
  15. 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.
×