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.

Posted in Technical details and tagged , , , , .