Summary
Adobe can provide fast, high-quality thumbnails and previews of PSD and PSB files to the Mac Finder at low engineering cost and without any involvement from Apple. There are two independent improvements:
- Store higher-resolution JPEG previews in PSD and PSB files.
- Implement an OS X Quick Look Plugin for handling PSD and PSB files.
Storing higher-resolution previews would eliminate the need for users to save files with the Maximize Compatibility option just to get larger thumbnails and previews in the Mac Finder and Windows File Explorer. It would also speed up the generation of thumbnails and previews for very large files (hundreds of megabytes and larger). Previous versions of Photoshop stored such previews, but this functionality was removed some number of versions ago.
Implementing a Quick Look plugin would provide thumbnails and previews of PSB files (not currently provided on OS X), and it would greatly speed up previewing very large PSD files. It’s quite straightforward – many third-party developers do it, it is well-supported by Apple, and I managed to do it without any prior programming experience in OS X or Photoshop.
The rest of this post explains the proposal in more detail.
Higher-Resolution JPEG Previews
When you select the Image Previews: Windows Thumbnail save option, Photoshop CC 2014 stores a 160x160-pixel JPEG thumbnail in the PSD/PSB file. (The Icon option does nothing, by the way.) The OS X 10.9/10.10 built-in Quick Look functionality (invoked by the Finder) uses that JPEG, if present, to generate thumbnails 192x192 and smaller. If the JPEG thumbnail is not present, or if it is present but the Finder requests a size larger than 192x192, then Quick Look will make a thumbnail using the composite image stored by the Maximize Compatibility option.
There are two problems caused by the small size of the thumbnail:
- Generating a larger-size thumbnail from the composite image can take a very long time. For example, with a 1.3 GB PSD file stored on an SSD on my 2014 Macbook Pro 15” (2.6 GHz i7), it takes the Finder 13 seconds to produce a 512x512 thumbnail or a 2000x2000 preview, whereas it takes just 0.1 seconds to produce a 192x192 thumbnail. If the Finder handled PSB files using the same method, it would take about 130 seconds to generate thumbnails for a 13 GB 100Kx100K PSB.
- If the Maximize Compatibility option isn’t set and there are two or more layers in the file, then the composite image will be missing, and the Finder will show a blank thumbnail and preview. Many users resist saving with Maximize Compatibility because it can increase the file size by a fair bit (by storing an additional full-resolution layer), and such users get blank thumbnails and previews.
If Photoshop stored a higher-resolution JPEG preview, say 2000x1333, it would allow the current built-in Quick Look generator to provide larger Finder thumbnails extremely fast, even for very large files. It would also allow users to save their files without Maximize Compatibility but still see thumbnails up to the Finder’s maximum of 512x512.
High-resolution JPEG previews would also enable very fast Finder previews, even without Maximize Compatibility. The current Quick Look generator doesn’t use the JPEG previews for generating Finder previews, but a generator plugin written by Adobe (see the next section) could easily do so.
Previous versions of Photoshop used to store higher-resolution previews in PSD/PSB files. In fact, the current Photoshop CC 2014 documentation still (incorrectly) describes the Full Size option for saving 72-ppi previews.
The high-resolution preview would add proportionately very little to the file size. A 2000x1333 medium-quality (6) preview, suitable for large Finder previews, takes on the order of 625 KB.
There are two options for where to store the high-resolution JPEG in the file format. Photoshop could simply increase the size of the current thumbnail from160x160 to 2000x2000 and continue to store the JPEG in image resource block id 1036. The publicly available specification for PSD/PSB files puts no limit on the size of JPEGs stored in that block.
Alternatively, if Adobe is concerned about compatibility with software that incorrectly assumes that the JPEG in block 1036 is 160x160, it could introduce a new image resource block to store the high-resolution preview. It could resurrect the Image Preview: Full Size option to control whether the high-resolution previews are actually created.
Regarding compatibility, I’ve successfully tested the following applications with a PSD file containing a 2000x1333 JPEG preview stored in the existing image resource block 1036:
- OS X 10.9/10.10 Finder/Quick Look
- Ardfry’s PSD Codec (Windows)
- Bridge CC (OS X)
- PSB Quick Look (my Quick Look plugin)
Implementing an OS X Quick Look Plugin for PSD/PSB
The OS X Quick Look facility lets Finder, open/save dialogs, and other applications show thumbnails and previews for any file type. Quick Look has built-in the ability to preview the most common file types: PDF, JPEG, text, etc. While it can preview PSDs, it doesn’t handle PSBs, even though the two file formats are nearly identical.
However, Apple defined the Quick Look architecture to make it easy for application developers to add previews for additional file types. The developer provides a Quick Look plugin (or “generator”) that reads files of a given type and generates the previews. The plugin architecture is well-supported by Apple, with reasonable documentation and templates in the Xcode development tool. Many, many applications provide their own Quick Look plugins to enable their file formats to be previewed.
It’s very straightforward to write a Quick Look plugin. Having no experience with OS X programming or Photoshop file formats, I was able to implement my PSB Quick Look plugin in less than two weeks. The plugin relies on an unencumbered open-source library, ImageMagick, to read the contents of PSD/PSB files, with about 350 lines of new C code as “glue” between Quick Look and the library.
It would be similarly straightforward for Adobe to implement a Quick Look plugin for PSD/PSB files. Adobe could use its own internal libraries to read PSD/PSB files, which would likely be even faster than the ImageMagick libraries. (For example, Adobe Bridge generates thumbnails and previews for PSD/PSB files very quickly.) Adobe would just need to write the few hundred lines of glue code between Quick Look and their library. Note that a vendor-provided plugin can override the previewing built-in by Apple, so Adobe’s PSD plugin could override the one built-in to OS X.
Adobe and Apple seem to be in a finger-pointing contest about who takes responsibility for writing a PSB plugin. Apple’s position is reasonable—they build in the most commonly used file formats and expect application developers to provide the rest. PSBs are not used as widely as PSDs, so Apple expects Adobe to provide the plugin, and that clearly annoys Adobe. But other application developers have to write their own Quick Look plugins, so why doesn’t Adobe? Given the low cost of building a plugin, Adobe’s refusal makes them look petty and unconcerned about its customers.
Some design considerations of a PSB/PSD Quick Look plugin:
Given modern cameras, HDR, panoramas, and multi-layer editing, PSD and PSB files are getting very large, ranging from hundreds of megabytes to tens of gigabytes. So it’s important that a plugin avoid reading the entire file just to produce a small thumbnail or preview.
If Photoshop stored a higher-resolution JPEG preview in the file, as proposed above, then it’s very easy for the Quick Look plugin to provide a thumbnail or preview quickly. The plugin just seeks to the right location in the file and reads out the relatively small JPEG preview. (This is what the Apple PSD plugin and my PSB/PSD plugin do to access the stored thumbnail.)
But if Adobe chooses not to store higher-resolution previews, it’s still straightforward for the plugin to produce thumbnails and previews reasonably quickly. The plugin doesn’t read the entire composite image (stored by the Maximize Compatibility option), only a down-sampled subset of the rows of the composite. For example, suppose a PSB file stores a 300K x 300K image, and the plugin needs to produce a 500 x 500 thumbnail. The plugin would read just 1000 rows from the composite image, rather than all 300K rows, reducing the total I/O by 1/300. The plugin would then down-sample that 1000x1000 image to 500x500 using a fast but mediocre-quality resize algorithm.
My PSB plugin uses this down-sampling strategy, and it’s able to preview a 10 GB PSB file in a couple of seconds. It took about 20 extra lines of code in the open-source image library to implement.
7
Replies
AdChoices