Bug in v5, v6 and tested in v7.0.4 clients. Verified in v.0.4 as Windows only.
Replace the default values in the boxes below with those for your project and then click the button:
The apparent logic for preview creation makes the assumption that images are 72dpi, and first divides 72 by the source image resolution, then it multiplies the result by the desired long side value. So a 72 dpi original, under 100px long side will use the actual image size and not the preview value. The default long side value is always 1000 unless you alter this via the catalogue's Administration dialog.
So, Assume our image is 72 dpi and has 836 pixels on its long side; 72/72 = 1, (1 x836) < 1000, so preview will be 836 pixels long side.
Now assume our image is 72 dpi, 1500 pixels; 72/72 = 1, (1 X 1500) > 1000 so now the preview will be 1000. In effect the code is saying the desired preview long side value is a "not greater than" whereas most users assume it is an "equals" value
Change the source resolution and things get odd. Thus, dpi 300, preview long side 450, original long side 900. 72/300 = 0.24, 0.24 x 900 = 216, 216 < 450, so the preview is 216 pixels long side - only 48% of the desired vlaue of 450 pixels.
Why the 72 dpi assumption? It is not clear but probably to do with the way the filter works and probably the (erroneous) assumption that all monitors/screens have a resolution of 72 dpi. In fact that was only ever true for Macs, and now not even all Macs as I believe the new Apple Cinema displays now run at a native res of > 100dpi. Meanwhile, the Windows desktop has always been 96 dpi - or 120 dpi if 'large fonts' are set. This Mac/Win disparity is most commonly exemplified by Acrobat/Reader which displays PDFs at 72 dpi on both OSs. As a result windows (96dpi) screengrabs look out of focus at 100% zoom - you must use 133.33% to see them correctly (1.33 = 96/72).
So we know there's a bug, we can see how it gets the sizing maths all wrong, but sadly only Extensis can fix it. Let's hope they do!
1. If you accept the default "create previews" dialog at catalogue creation, the desired long side value default is 1000 pixels. If you desire a different value, then before you start adding image you should open the Catalog Administration dialog, Preview tab, and set your chosen value. If not, any previews will be created at a target 1000 pixels per long side. If you change the value after some images have already been added, then use Item/Regenerate Thumbnails and this recreates both thumbnails and previews, given you fresh previews at the new target size.
2. If the original size is at or under the desired preview size, the preview long side = original's long side.
3. If Portfolio can't create a thumbnail or preview at all (e.g. for a sound or spreadsheet file), no preview image is added to the preview folder.
4. If Portfolio can extract a thumbnail image but can't create a preview (e.g. an unsupported RAW file type) the thumbnail is saved as the preview (at thumbnail actual size).
5. Can you over-ride the above sizing bug by a workaround? No! You can create your own previews via Photoshop, but if you want to use them inside the catalogue and with NetPublish, then you'll need to name your cutom previews with the RID based names Portfolio uses and put the files in the folder set in the Admin/Previews dialog.
This form uses the same logic as above but tells you - for a given original long side resolution and target longside - the output preview's long side, so you can see how badly the bug will affect you.
Note there may be a discrepancy of a pixel or two between the cut-off figure in the top form and the values computed here - this is due to rounding issues.