Jump to content

GFS

Members
  • Content count

    283
  • Joined

  • Last visited

About GFS

  • Rank
    Advanced Member

Profile Information

  • Gender
    Not Telling

Recent Profile Visitors

862 profile views
  1. Thank you Chris B. Can you tell me what the advantages of mipmapping are in this respect? Is it just a question of speed?
  2. And there I was thinking that I could use the iPad to do some work with focus merging ... but .. uhhh ... no! Such a shame, because the AFP focus merging is really fast and extremely good, but unfortunatley, it turns specular highlights into white blobs, so you need the sources panel to be able to remove this messy treatment.
  3. I wonder if this isn't a decision about speed by Serif. I expect that AFP has a pyramid of internal jpegs for display and adjusts on the fly for in-betweens. Blur is slow to calculate and can bring AFP to it's knees in processing ... although this has improved significantly with 1.7x. Perhaps it would be enough to simply offer a checkbox to use 'accurate' previews, when desired. My old favourite imaging app had this waaaayyy back in the mid90s. A simple toggle between speed and accuracy.
  4. Thanks Walt. You're correct.. and there I was thinking that zoom to 100% to see if, e.g. banding is really there, days we're over. Ho hum. *However* This remains an issue. I need to be able to see my entire image on-screen, in order to judge how much blur I want to apply. Zooming in to 100% on a ~100 megapixel image is completely unworkable in this regard. So at the moment, in order to see how much blur I want, I have to make a guess in AFP, Export to tiff, look at that, go back, adjust, Export to tiff, look at that, go back adjust, Export to tiff, look at that ... I think we call this a problem. The AFP preview (on-screen image) needs to be accurate.
  5. I have a gaussian blur layer, which when exported to tiff, is not applied to the same level (amount) as the screen preview in AFP 1.7.3. In order to have the same amount of blur in the exported tiff, I have to increase the blur radius from 0.9 to 3.8px
  6. Hi MEB, thanks for the reply. I couldn't find a Mac beta to use instead, so I had to workaround ... neither of the above 'fixes' actually fixed it for me.
  7. Thanks haakoo. That's just the attitude. Perhaps you work for Serif?? Anyway, I already said goodbye, but seeing as it's my profession, I have to deal with the past as well as the future.
  8. I don't think Serif realise how bad this is ... I stopped using AFP because of the several serious masking issues I reported 2-3 years back. Nothing was done until 1.7, which fixed some of them, but even then, not fully. Yesterday morning I had a client asking for some variations on some images, from back then and I've just spent an hour trying to work out what the heck is going on. I realise that most amateurs don't get into much compositing, but it's crucial to many pros and this is definitely NOT what I would call a professional approach. When I suggested a couple of years back, to one of Serif's forum guys, that he was talking crap, when he said it's normal that a Preview doesn't reflect the result, he reported me for bad behaviour, which I guess was an unfortunate pointer and it doesn't look like anything has improved. I'm fairly annoyed right now, which doesn't seem like the attitude you want to be encouraging. Serif really really really needs to address ALL of these masking issues as quickly as possible.
  9. I think this will depend on whoever and whatever apps, if any, take advantage of MacOS 10.15 giving developers access to the Photos database. We just don't know yet. It hasn't even shipped. (Another month?) Obviously it would be in the interests of any developer to make a transition to their system as simple as possible. I would imagine that Catalogs and Collections would be easy as they're essentially a database question. Adjustments may be harder.
  10. It looks like he's proceeding with the DAM aspects. As for using Managed Libraries in Aperture ... most users didn't understand what this involved, or that Aperture offers the choice of both Managed and Referenced, with a fast and easy way of moving files from one to the other. As any database developer would tell you, the golden rule is to have everything managed, otherwise the risk of damage/loss from things being messed up by human beings remains very real. Aperture's Managed database is very good (and can be read in the Finder if you really want) and continues to be used with Photos. Since the changes to the MacOS file system, with 10.14, all of these assets are much safer, because they are constantly tracked. If Nik Bhatt's RAW Power can tap into the Photos database, as he believes he can, then he should be able to quite feasibly recreate the vital DAM aspects of Aperture. The added bonus, is that Apple's RAW engine is very very good. Edit: (Of course, Serif will also be aware of the changes to the OS coming with 10.15, so they too could quite easily produce a DAM front-end for Affinity ... but it would only be for Mac)
  11. On the Mac, this is called the Finder, although most people wouldn't be aware of how powerful it is.
  12. You may be in luck! Nik Bhatt, ex-lead of Aperture, brought out his excellent RAW Power app a while back. It taps into the MacOS built-in RAW decoding, which is used/maintained for Photos. This is what Aperture uses too, although Aperture can no longer use the current decoding. A couple of weeks ago at Apple's WWDC, Apple announced that they are going to allow developers to access to Photos' database in 10.15 Catalina. This means that apps like RAW Power will be able to use the Photos database, which crucially will allow them to share all that metadata and perhaps the adjustments. So I would imagine, that you will be able to import your files into Photos, but then ... not use Photos ... and instead use something else, with more features and a better UI more suited to pros, like RAW Power. The long and short of it is that Nik could build RAW Power into as good a DAM as Aperture AND it will be able to read your Aperture Libraries (because Photos already can). Did I just make your day? Maybe give him some encouragement ... https://twitter.com/gentcoders https://gentlemencoders.com/raw-power-for-macos/
  13. Thanks for the replies. As you said Walt and R C-R, AFP is respecting the metadata, which is great and my problem was coming from the way that Aperture handles files which are lacking a metadata date. In fact, what it does is it displays the Finder date in the exif date field, but if these files are exported *as originals*, that date is not included, presumably because it is not a part of the original file. So that is as it should be. If you export as a version, then the date is applied, which equally, makes sense. On top of this, it turns out that it's trivial to set the date permanently in the originals, within Aperture. So my problems is solved without any headache ... just a lot of fiddling, checking, searching etc. Also good to see that AFP is handling batch conversion in a useful way.
  14. Thanks again and I should have been more specific about which date, but those still don't answer the question. FWIW and not relevant for much longer, Aperture can batch change EXIF date. So I already have this ability. The question is how to batch convert (or retain in AFP when using Batch Job) the original file date, so that the new file's date matches the old (original) file's date. I have many thousands of these images, so doing them one-by-one would be time consuming.
  15. Thank you for the reply. These don't address the issue though. The question is not how to change a file's date, it is how to retain the date of the original file when batch converting (the exif date ... not the Finder date).
×

Important Information

These are the Terms of Use you will be asked to agree to if you join the forum. | 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.