Jump to content

lphilpot

Members
  • Posts

    414
  • Joined

Contact Methods

  • Website URL
    https://www.flickr.com/photos/14015058@N07/

Profile Information

  • Gender
    Male
  • Location
    Central Louisiana, USA
  • Interests
    Photography, astronomy, music, computers

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I'd love to see a non-destructive gradient that could be applied to / as a layer mask and later edited. I've played a bit with gradient fill layers but only partially successfully in that context.
  2. For what it's worth (which may be nothing ultimately) I leave my personal copyright in even if I strip other metadata.
  3. Yes, the shortcut can be configured to do that. But it shouldn't be necessary, especially if you're referencing a plugin owned by you, in a folder owned by you, with permissions on your account. If the plugin is installed under C:\ProgramData, that's almost certainly (IMO) why admin rights are required. If it's installed elsewhere, it might be educational to see the security rights on the GMIC plugin as well as the folder tree in which it lives.
  4. I'm running the MSI version of Photo, but it should have the same permissions as the sandboxed version so that shouldn't be an issue. It's not surprising the app would've have rights to create a directory under ProgramData but I'm not sure what's interfering elsewhere. My user account is a local admin but again that shouldn't be a factor under one's own home.
  5. Is that where it installed by default? C:\ProgramData is a very protected location so permissions issues aren't surprising. I put my GMIC plugin (and any other third party 8bf / Photoshop plugins) into a folder under my home directory and then added that path to Preferences. Unless you're using the standalone version of GMIC and want the installer to create shortcuts, etc., you don't even need to install it. Just extract and copy GmicPlugin.8bf to wherever you've instructed Photo to look. Restart Photo and it should work.
  6. Opening it in ART gives this WB: Setting Photo to those same (or equivalent) values gets closer but not the same. The lens vignetting correction is in metadata, but I can't say why Photo is apparently misreading the WB.
  7. There are other options than just Affinity or brick... 🙂 Some are paid, some are free, several are very capable from either option.
  8. Maybe I hit on a lesser course, but my impression of the couple of AR Photo tutorials I looked at were ... thin and somewhat tedious (I guess is the best desccription). I realize it's probably down to personal preference but I got the impression it wasn't exactly information-dense. I would much prefer something more akin to a university-level classroom. It's not that I'm smart -- far from it 🙃 -- but I see little reason to spend time on instruction if it's relatively little 'elevated' from what I can figure out on my own (again person preference). More dense instruction will likely be more difficult but in the end you'll know more. I've been looking for landscape-oriented Photo training more in the vein of Mads Peter Iversen's big Photoshop course. At $300 USD and ~25 videos that course is in a different category from AR. So far I've found nothing, though.
  9. Yeah, I came up with that on the spur of moment to illustrate the concept. Point is, a standard template "database" format that covers all the necessary information about functionalities is IMO the best approach, instead of a more purely prosaic style (for lack of a better term). That would tend to enforce more complete documentation. I do find it amazing -- and not in a good way -- that pressing F1 doesn't open help relevant to the current app context. You still have to search and then try to pick the best results, if any. It's not like context-sensitive help is a new concept... The current help system is literally nothing more than a basic local website.
  10. I agree, Help isn't particularly helpful at times. It's not context-sensitive, there's no index, there's no "by menu" documentation of each function presented in the UI and what functional descriptions are there are sometimes frustratingly thin, often just repeating what's already visible on screen. And no, I can't provide examples for all of this ATM, but I've seen it quite often. Personally I think every capability should be documented along these lines: Function name Functional context / persona (e.g., raw only, vector only, etc.) Purpose Technical description / parameters, etc. Complete functional instructions Sample / brief tutorial Context, i.e., "see also" or other similar functionality That sort of template has been used in developer documentation for decades, because it works.
  11. I've not run into that but Photo 2.5.2 seems to be noticeably slower in screen refreshes than before. There's noticeable pixel layer tiling which I've not seen before, even on my (very) moderate laptop.
  12. POSIX and other standards are great for what they are (not minimizing them) but they're only a subset of what's coded. As you indicate, it's all the non-portable (even undocumented?) stuff that's the problem. Try writing a real-world, non-trivial, usable app in completely portable ANSI C, for example...
  13. Then again, as I recall you Texans got to see Comet McNaught (C/2006 P1) in the daytime during early 2007 while farther east we were totally overcast for the entire apparition. And that's way cooler than an eclipse. 🙂
  14. Every time I think about the crowds I lose all enthusiasm for the trip. After all, it's only 4 minutes out of an entire week... But we're paid up, so might as well go.
  15. Ah ha... I'll blame it on trying to pack for our eclipse trip while replying... 🙂
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.