F-Stop end of sale

During last week, after Flickr acquisition by SmugMug, I have decided to reconsider my investment in Flickr: I don’t trust these acquisitions having been part, 2 years ago, of the big acquisition of my current employer. The lesson learned during these 2 years is that has no meaning to have concurrent and overlapping lines of products. So my guess is that Flickr and SmugMug are going to merge in the long term despite all the denials in the FAQ.

How they’ll do this is unknown but everyone can make speculations. Based on mine, I don’t want to be a part of this game so F-Stop, effective immediately, is not on sale anymore. This is a really sad decision and really hard to take: I have spent tons of hours coding in my spare time during the last 9 years. Time subtracted to my family and my friends with the simple goal to make Flickr a better place for Mac users. I did this despite the small amount of money received back.

How this decision is going to impact you:

  • If you are an happy F-Stop customer, nothing is going to change in the short term: F-stop will continue to work as usual. In the long term, F-Stop will be no more updated to add support for new functionalities, operating systems and bug fixes.
  • If you have bought F-Stop just a few days ago and you are upset for this decision you can ask for a refund. There are several tutorials on the internet on how to proceed. Google for “app store refund” and pick your preferred link.

Version 5.1.1

Version 5.1.1 is a maintenance release that introduces the following changes:

  • Fixed image flickering when scrolling with mouse wheel in dynamic layout.
  • Fixed a layout problem when there are empty groups in selection.

Version 5.1.0

Version 5.1.0 is a maintenance release that introduces the following changes:

  • Improvements in resolution of displayed images
    • Photo Browser now displays flickr large format if available (instead of medium format). Il large file format is not available, medium format is used.
    • Photo View now displays largest available image format (with the exclusion of the “original format”).
    • SlideShow now uses image formats in the following order: Very large, large, medium.
  • Fixed a bug in camera roll which prevented accurate date searches when certain dates were used (such as 31 December 2014)
  • Camera roll now uses a new graphical selector for dates.
  • Added new grid layout to Photo Browser.
  • Fixed a memory leak in Photo Downloader.
  • Photo Downloader now restores last selected destination path.
  • Fixed bugs and race conditions in Photo Downloader.
  • Photos added to Photo downloader are now added using selection order.
  • New option to remove user notifications of photos uploaded with error.
  • Fixed white screen in Photo View when a video is selected. Notes are now disabled for videos.
  • Timezones are now respected in Camera Roll when “Upload date” sorting is selected.
  • Fixed some drag&drop issues in Photo Browser.
  • Statistics view now uses monospaced font.

Version 5.0 – Technical Details

F-Stop version 5.0 introduces several changes. In this post I’m going to explain reasons and technical details behind some of these changes.

OSX 10.11 El Capitan requirement

This requirement wasn’t planned at the beginning of version 5.0 brainstorming but, during WWDC 2015, Apple announced something I was waiting since 3 years: a lot of improvements in NSCollectionView. With these improvements, NSCollectionView is able to display images in a more flexible way than the traditional IKImageBrowserView used by F-Stop since version 1. Unfortunately Apple has decided to do not back-port these improvements to NSCollectionView running on Yosemite and this is only reason why F-Stop version 5 requires OSX 10.11 El Capitan.

New graphical interface for Image Browser

IKImageBrowserView, a venerable component developed by Apple a lot of years ago, was the foundation of F-Stop image browser. At the time I started writing F-Stop, I had to do a choice between 2 components available: IKImageBrowserView and NSCollectionView. I went for IKImageBrowserView for 2 main reasons:

  • Performance. IKImageBrowserView uses layers and it’s very fast in displaying a lot of images with beautiful animations
  • Ability to display multiple groups of images

NSCollectionView was lacking support for multiple groups of images and I found it slower than IKImageBrowserView. But during these years I found a lot of limitations in IKImageBrowserView too:

  • Customization: IKImageBrowserView is cell based. There is no way for IKImageBrowserView to use subviews to render images. Every image displayed has a fixed layout and there is a limited degree of customization in cell layout too.
  • No custom layouts: IKImageBrowserView is able to display images in a grid and only in a grid.
  • Bugs/Weird behaviours. Although IKImageBrowserView is layer based, I haven’t been able to draw additional layers consistently. I have tried for several months to add a video playback layer to a cell without any luck.
  • No improvements for years: Apple has forgotten this component since its inception. No new methods, nor improvements to its deficiencies in years.

During the same years, thanks to its iOS counterpart (UICollectionView), NSCollectionView has gained a lot of focus. This year, during WWDC 2015, Apple announced some important improvements: Ability to display different groups of images within the same NSCollectionView and the possibility to use custom layouts. Time to ditch IKImageBrowserView…

Implementation of a new layout engine to emulate Flickr explore page hasn’t been easy and I have to credit this guy and its blog post for pointing me in the right direction. In addition, refactoring all F-Stop to use NSCollectionView was harder than I expected. Anyway… I did it and this is how F-Stop looks like now:

Main View version 5.0


Is NSCollectionView perfect? Not yet. I have found some limitations such as a more complex way to deal with selections (keyboard and drag&drop). And I’m still looking for a way to solve some crashes when images are added using insertItemsAtIndexPaths: method. To avoid these crashes, F-Stop reloads images every time but animations are ugly. But I’m confident that Apple will solve these defects in the future because NSCollectionsView is (loud and clear today) the way to go.

There is another subtle graphical change I have introduced. Windows have a full size content view. In simpler words, F-Stop title bar appearance is like the one seen in Safari when colored content is scrolled (blurred behind the title bar).

Full Content View


Improved performance of Photo Downloader. Downloads are executed concurrently with a progress bar for each download

There are some improvements to Photo Downloader too. The main one is that photo downloads are now executed concurrently: this increase download performance for broadband users. For each download there is also a progress bar to monitor the process.

Another improvement is related to failed downloads: Photo Downloader used to silently discard failed downloads of photos. This is not anymore: now F-Stop adds an error to its error window (describing problem occurred) and the download can be restarted once the problem is fixed.

Improved upload performance with concurrent uploads

During last year, I have received several complains regarding upload speed. Some broadband users were reporting slow uploads. Having a slow internet connection, I had hard times to understand the issues. What I found is that Flickr upload api performs some post-processing operations before returning a photo identifier (another way to say: “upload completed”). These operations include photo validation and resizing and (probably) metadata synchronization in the cluster and takes something around 10-15 seconds per upload.

For broadband users, a 10 to 15 seconds delay represents a huge increase of upload time. For example, for a 2MB file that takes 2 seconds to upload, entire upload takes (in the worst case) 17 seconds. That is 8.5 times!! So I have decided to allow for concurrent uploads. Users can tune this value in F-Stop preferences from a minimum value of 1 (serialized uploads good for slow internet connections) to 10 concurrent uploads (fast internet connections).

It’s important to note that concurrent uploads may not respect upload ordering defined in F-Stop upload sidebar. This could also affect photostream ordering in Flickr because Flickr orders photos using their upload time (except for Camera roll).

Improved editing of tags when Photos View is displaying a selection

Metadata Editor in Photos View gives users the ability to change tags of a photo or a selection of photos. F-Stop versions before 5.0 managed the latter case in the wrong way: all tags of a selection were replaced with the new set of tags specified in metadata editor. Imagine the following scenario

Selection of 3 photos:

Photo A – Tags: A,B,C

Photo B – Tags: D,E,F

Photo C – Tags: G,H,I

Setting tags X,Y,Z in metadata editor lead to the following result:

Photo A – Tags: X,Y,Z

Photo B – Tags: X,Y,Z

Photo C – Tags: X,Y,Z

Now in F-Stop version 5, tags field of Metadata Editor displays (for the selection above) the following tags: A,B,C,D,E,F,G,H,I. User can add new tags and/or remove them. Adding X,Y,Z and removing E produces the following result:

Photo A – Tags: A,B,C,X,Y,Z

Photo B – Tags: D,F,X,Y,Z

Photo C – Tags: G,H,I,X,Y,Z

Removed support for Google Maps

F-Stop 5.0 doesn’t use Google Maps anymore to display user photos on a map. Apple map is the only choice available. Google Maps in F-Stop used to work using a WebKit view rendering a javascript content described in a file. With El Capitan there are additional restrictions to access this file and, honestly, I’m not very good with HTML and Javascript. Considering how Apple Maps have improved during the last couple of years, I believe that this is not going to hurt anyone.

Removed all deprecated methods of old releases of OSX including NSURLConnection

Every year Apple introduces so many changes to its platform that new deprecated methods are a fact life when an application is recompiled using the latest and the greatest developer tools. Compiler embedded in Xcode 7 emitted more that fifty deprecated methods warnings with F-Stop version 4.x… time for a definitive cleanup. Generally speaking, replacement of a deprecated method is easy: there is a new method to call. Nothing more, nothing less. But with OSX 10.11 El Capitan NSURLConnection is going to be deprecated and this is huge. Its replacement, named NSURLSession, is more efficient, more elegant, more sophisticated and in the most of cases very easy to be introduced as replacement for NSURLConnection. In most of cases apart one: synchronous connections. NSURLSession has no synchronous mode of operation: everything is managed asynchronously.

Unfortunately is not always easy to deal with an asynchronously logic. Especially if you have spent your last 5 years to use NSOperationQueue with synchronous operations to perform all your background tasks. A lot of people out of there argues that synchronous logic is evil. I disagree. Synchronous is the perfect fit for sequential operations if you can perform them in background. Synchronous sequential operations are easier to understand, easier to debug and, if there is a real reason to have them sequentially executed, performance difference is negligible in comparison to asynchronous operations.

In any case F-Stop uses now NSURLSession everywhere but it costed me a lot of headaches. I hope Apple will reintroduce Synchronous methods to NSURLSession.

Version 5.0

Version 5.0 is a new major release of F-Stop. This release introduces some important changes. If you are interested in technical details please see this post.
Here are the changes:

Changes for the end user

  • OSX 10.11 El Capitan required
  • New graphical interface for Image Browser.
  • Videos can now be played within Image Browser
  • Improved performance of Photo Downloader. Downloads are executed concurrently with a progress bar for each download
  • Improved upload performance with concurrent uploads (Max 10 concurrent uploads. To be set in preferences)
  • Added ability to specify geolocation in Uploads and in Metadata Editor
  • Improved editing of tags when Photo View is displaying a selection
  • Improved animation of sidebars
  • QuickEditor is now displayed using CMD+Left Click on a Photo (instead of a long left click)
  • User definable default custom size for uploads
  • Removed support for Google Maps

Under the hood changes:

  • Removed all deprecated methods of old releases of OSX including NSURLConnection
  • Increased logical separation between application modules using Frameworks
  • Fixed a bug when displaying Total in statistics view
  • Fixed some memory leaks
  • Fixed a bug when displaying notes in Photo View
  • Fixed a crash when starting slideshow in Photo View
  • Other minor bug fixes


This is the how F-Stop version 5 looks like.

Main View version 5.0


Version 4.1.4

Version 4.1.4 is a maintenance release that fixes a critical bug in backups: due to a change in a Flickr api named flickr.people.getPhotos, F-Stop routine that checks for photos to backup is not able to terminate and runs indefinitely.

Version 4.1.4 introduces another change: now backed up files have their creation date set to EXIF Date Time Original if available.

This is version is going to be released next week (assuming Apple will approve it)

Version 4.1.3

Version 4.1.3 is a small maintenance release. Details follow.

  • Fixed an exception raised when an invalid page number is inserted in page number field
  • Fixed some warnings on startup
  • Fixed a bug in search that prevented tag mode (any, all) to work properly

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.