Friday - The Automatic FAQ Maker
Manual: v8/v7 - page 32-33, v6 - Page 28, v5 - Page 214
As from v7, the term "Disk Preview" was changed to "Screen Preview" - they are otherwise exactly the same and you may see both terms used throughout the FAQ.
Portfolio can create a full sized 72-dpi jpg preview of the file when it is catalogued. This means the original file can be moved somewhere else or completely offline and the user can still get a full sized preview. This can also help make the preview process faster if the original file is large.
The manual doesn't say so explicitly but you should note that Previews are not stored within the Catalogue file itself but externally, in the folder you nominate via the 'Previews' tab of the 'Catalog Administration' dialog. This means that creating Previews doesn't add the physical size of your Catalogue file (whereas it does in some DAM systems like iView). However, the Previews themselves do still take disk space outside the Catalogue so take this fact into consideration when designing your Cataloguing strategy (and back-ups!). From v7 onwards, whenever you create a catalogue you are asked if you wish to create Screen Previews. If you say 'yes', a folder called "[catalogue name]_previews" is created in the catalogue's folder and a default long side pixel size is set (see below for default size values). Unless you are a single seat user, you are strongly advised not to allow Portfolio to preconfigure this but rather to set the location and size as part of your admin set-up before you use the catalogue. If using served catalogues you should also give thought to where the folder lives in relation to the catalogue - and more importantly ensuring the folder is set with a network path that all clients, and NetPublish if used, can access without permissions problems.
The set up for Previews allows you to choose a maximum length of the longest side in pixels. It must be assumed that Portfolio check's the source images width vs. height to establish the longest before creating the Preview. The maximum value, up to v6 is 1000 pixels which increases in v7 to 2000 pixels; default is 1000 pixels (to v6) and 1024 pixels (v7+).
Preview generation is done as part of Cataloguing, assuming the 'Generate Preview' option is turned on, and is slaved to thumbnail regeneration for existing records (noting that their original files must be available online during this process). So, can Previews be updated? Yes, as long as the 'Generate Preview' option remains on. Updating of previews is not affected by the Catalogue's 'Cataloging Options' dialog's 'Update' tab's setting for thumbnail extraction/regeneration. Can previews be generated for existing records without previews? Yes - select them and regenerate thumbnails.
As previews are based on a catalogue record's internal unique Record ID (RID) and because RIDs change when records are copied between catalogues, previews can't be copied between catalogues. If you have very large numbers of previews (where regenerating them is a big time/CPU cost) a workaround is given further below.
This ability to update Previews is more useful than you might first think. You may not normally use disk Previews but wish, for example, to create them for use with files stored on unmounted media such as CD/DVD. Simply turn on the disk preview option, update the necessary records and turn the feature off again. You now have a set of disk Previews to use when the CD is not mounted.
From v8 onwards, the Previews are used as an internal proxy for various tasks like attaching JPGs to email, batch processing, etc. In these scenarios, if the desired format is smaller than the Preview, the preview will be used as source rather than the original. This can help speed up low-res asset generation, especially with big selections and/or large original files.
From v7, if you delete a record, the preview is also deleted. In v6 and before you had to do this manually. Because deleted records delete their previews, do remember this if cloning a catalogue by copying an existing one and then stripping the records. In such a scenario, your first task with the copy should be to turn off previews - or set a new folder.
A single folder holds all a given catalogue's previews, the number of files there can get very large. In such cases users should not attempt to open or browse these folders in Finder/Explorer as the OS will try to thumbnail all the images there and will most likely crash. From v8.5.2 a new folder storage method has been introduced. Basically the preview number is parsed out into a series of nested folders /previewfoldername/00/00/00/00/, ../00/00/00/01/, etc., with each folder now holding no more than 100 previews, the previews themselves retaining their existing name format. The changes will have greatest effect for users with very large catalogues who should see improvement in performance. In general it will also make it easier to investigate preview folder(s) form Explorer/Finder in thumbnail or filmstrip/coverflow type views.
To provide backwards compatibility, opening a catalogue in v8.5.2+ will not cause it's preview folder structure to change. Only new or regenerated previews will be placed in the new nested folders; existing previews will remain in the main preview folder designated for the catalogue in the Administration/Previews dialog. This means that v8.5.0/8.5.1 components won't be able to find new/re-generated previews in a mixed environment - thus the advice to update all components.
How to update a large existing folder to the new structure? There is no built-in method. You can regenerate thumbnails for all records, but that may take a long time, tie up resources and be problematic if some image are in offline storage such as DVD. In such circumstances, make a script that parses the first 8 digits into a set of 4 nested folders within the main preview folder. Thus for the preview p0001638528.jpg (for record #1,838,528) would be copied or moved to /mainpreviewfolder/00/01/63/85/p0001638528.jpg.
There is a known bug you may encounter when creating Disk Previews, arising from the logic used to create previews. It is generally more commonly seen in the Windows client but the problem affects both OSs. It appears the original coder assumed maintaining print size was more important than pixel size. When the feature was coded (back in the mid-90s) print was a primary use whereas now the assumption just seems pointless -especially as screen previews are used for ... screen use (i.e. pixel-based display).
Anyway, in some circumstances, the client produces undersized Previews (by a factor of about 0.35 or more), it is most dependent on the resolution of the original image. There bug is fixed in v8.1+. There is a demo page describing the details of the bug and letting you test you own data. v8.5.2 fixes some more edge cases associated with very high resolutions (affecting Mac client only).
[v6] If you have difficulty creating Disk Previews and needed them for use with PortWeb - where the internal link to the RID-based preview name is not important - then use the feature in Photoshop v6 or later File->Automate-%gt;Fit Image. Using the latter in conjunction with lowering the resolution to 72 dpi and resaving as a JPEG will replicate the Disk Preview process, albeit with the originals filename (and extension if the latter was a JPEG). If you need Portfolio's RID-based names then you will need to make and use a VB or AppleScript script to rename the Photoshop created preview files. The latter will be necessary with v7 NetPublish as this is designed to use Portfolio's screen previews.
See also the notes on Previews and CD, preview naming syntax and, for v5 users only, the warning at the end of the article on compacting Catalogues.
Question: Screen (Disk) previews [FAQ00040.htm]
Last Update:- 15 April 2008
Site and articles © Mark Anderson 2001-2007 - Visit my home page