PSD preview implementation
please see attached patch for an implementation of reading PSD preview images. I'm not sure whether the chosen way is acceptable. so please give me any advice, if there is a way that better fits the existing model.
PSD image header information is stored in resource blocks, which form a structure similar to the contents of a JPEG APP13 marker (8BIM ...).
A PSD preview is stored in its own resource block as small JPEG image. Metadata (EXIF, IPTC, XMP) does also occupy individual resource blocks and does AFAIK not contain any additional preview images, e.g. in EXIF data.
These are the steps of implementation:
1. Extend readMetadata() in psdimage.cpp to extract the preview.
2. Add class LoaderPsdJpeg to preview.cpp. Implement associated methods.
3. Add member preview_ and Accessors to class Image in image.cpp.
The last step may be questionable, but for the moment I found no other (simple) way of passing the preview data read in psdimage to the PreviewManager. An alternative would have been to factor out some class PsdParser, which then could be used by both psdimage and preview to scan the resource blocks for either metadata or preview image. In that case no preview_ member in image.cpp would have been necessary.
So much for now. Best regards ... Michael
RE: PSD preview implementation - Added by Volker Grabsch over 8 years ago
RE: PSD preview implementation - Added by Andreas Huggel over 8 years ago
Sorry for this very late reply, It was delayed because it required some time which I couldn't find immediately...
- Note struct
Photoshopin jpgimage.hpp which has a few methods to deal with Photoshop IRBs. If there is any further related functionality required for the handling of these native previews, it should go there as well. (Technically, if other metadata is stored in an IRB, eg IPTC, it may contain further previews)
- Current practice for preview images in Exif is that "small" previews and thumbnails are loaded into memory but "large" preview images are loaded on request.
- All related information (the full preview if loaded and/or offset and size info) is kept in metadata tags rather than in the Image. However, until we have a unified metadata container and can more easily support additional types of metadata, native previews can stay where they are now. Image already contains other data members which I'd eventually prefer to have in some synthesized metadata tags.