Apple Photos and F-Stop integration

Some days ago, a user notified me a new different behaviour of Apple Photos app in comparison to iPhoto when dragging photos to a batch in F-Stop. With new Apple Photos app, nothing happens. After some investigations, I have discovered that new Photos app is more complex than before when copying photos.

You can check it by yourself giving a look at the screenshot below.

Photos and Mail

Photos and Mail

 
What is the difference between these 2 images? I can assure that they are the same photo stored in Photos.app copied to mail.

Well, in the first case (upper image) the photo is copy/pasted. Under the hood, Photos app sends a File URL to target application (in this case mail). This File URL references an existing file on disk which contains a thumbnail (1024px) of the original image. This file is stored inside Photos app library.

In the second case the photo is drag/dropped; Under the hood, Photos app sends (again to mail) a File Promise. A File Promise is a file which doesn’t exist during drag&drop session but it’s created later (generally asynchronously) in a path specified by target application. This File Promise will become eventually a new file on disk that can be read by target application (again mail).

At a first glance, this approach is a bit awkward. Performing what, on the user side, is the same operation (have the same image on 2 different applications), leads to completely different results.
In addition to that, the use of Files Promise has a lot of other important side effects:

1) A proliferation of duplicate files on disk. Imagine you want to drag&drop a lot of photos (may be thousand) from Photos app to another application: doing this, is going to increase (potentially double) space occupation of photos.
2) Creating these copies has also a great impact on CPU because each photo is rendered again in an independent file. Do a test by yourself dragging thousand of photos from Photos app to a finder folder. You’ll see your mac sustain a 100% utilization (with a huge impact on battery life if your using a laptop)
3) These copies are not temporary. It’s up to the destination application an eventual removal.

Now, speaking about F-Stop, there are additional problems because I engineered it to upload EXISTING files. So when you add a file to a batch, F-Stop immediately checks for its existence on disk. But, as a File Promise is managed asynchronously, it could happen that the file still doesn’t exist when F-Stop tries the addition. And while I could think to apply a workaround for this behavior, it’s far harder to apply a workaround if File Promise is still a promise when the upload batch is started.
Last but not least, F-Stop should remove all these temporary files but it cannot do immediately because it should still allow a retry in case of upload failure. So it should clean these files on exit or when a file is manually removed from a batch. Both cases have their own tradeoffs too.

Probably all of above are not an issue if a user is uploading a small batch of files. But F-Stop users use it to batch upload thousand of photos and I’m not confident in messing up the upload engine to support this change in photos.app.

So, considering all of the above, if 1024px resolution is fine for your needs, I suggest to use copy/paste to copy photos from Photos.app to F-Stop instead of drag&drop. Otherwise export images manually to a finder folder, then upload using F-Stop.

Version 4.1.2

Version 4.1.2 is a small maintenance release. Details follow.

  • Fixed another “skipped file counter” bug which displays an abnormal big number (in upload view) the first time an incremental upload is started for a directory
  • Fixed an auto layout bug triggered by displaying upload preferences
  • Fixed a bug which prevented manual change of page number in search photo view
  • Fixed a bug which allowed to populate editable field in search photo view also when there wasn’t any search selected. Now criteria fields are hidden when there is no selection
  • Restored “parameterless search” alert when user tries to make a search without parameters. This time, alert is less intrusive than the one in previous versions of F-Stop
  • Fixed a memory allocation problem in canvas view of Stacks
  • Fixed a memory leak during incremental uploads
  • Fixed a memory allocation problem in application delegate

Version 4.1.1

Version 4.1.1 is a small maintenance release that add support for 2 new kind of licenses supported by Flickr which are Public Domain Mark and Creative Common 0.
You can read more about these licenses and flickr support here:

Great news for the commons: Flickr now supports CC0 and the CC Public Domain Mark
Flickr now offers Public Domain and CC0 designations

With this version of F-Stop you can search photos tagged with these licenses and/or you can set these licenses for your photos

Version 4.1.1 also includes a fix for wrong counting of skipped files during an incremental upload.