This seems to be coming along nicely! Just a few comments: oiio:BitsPerSample should be 16 in that example... you have 48, which would be bits per *pixel*. In fact, you only need to set oiio:BitsPerSample if it's different from what the 'format' (uint16 in this case) would imply. For example, if the file were 10 bits per channel, and we didn't have any choice but to pass back uint16's (since there is no 10 bit data type in C/C++), we use oiio:BitsPerSample to indicate that the data in the file actually had less precision than the pixels we are passing through the OIIO APIs.
Thus far, the OIIO policy has been that only RGB (i.e. additive, noninterfering, spectral color model) channels are passed through OIIO, and thus YUV, Lab, or CMYK are expected to be converted to/from RGB on the plugin side, so that apps can always assume that they are working in RGB, with the only free variable being the mapping from coded value to light level (Linear, sRGB, Gamma, KodakLog, etc.). My inclination is to convert to RGB while passing through OIIO by default, and possibly have another mode (using the "open with configuration" API routine) that instructs it to pass original data without color space conversion. But... I'm not sure. What does everybody think? Jack? Jeremy? Daniel, have you pushed this to your repo so that people can take a peek at the code if they want? PS. when it comes time to do the Exif/XMP, please try to use the code I've already written for this rather than reinvent it from scratch. (Just didn't know if you'd already stumbled across it.) On Jun 23, 2011, at 8:12 PM, Daniel Wyatt wrote: > Hi all. > The input side of the PSD plugin is coming along steadily. > Here is what I've completed recently: > -Optimized/redesigned resource loading (loading only resources that we have > support for) > -Correct ImageSpec creation (tested with various 1, 8, 16, and 32-bit Bitmap, > Grayscale, Indexed, RGB, CMYK, Lab, and Multichannel images) > -Channel names (loaded from image resource when present) > -attribute X/YResolution and ResolutionUnit > -attribute PixelAspectRatio > -Reading layers (everything except actual pixel data is done) > -Adding some subimage bits (not complete yet) > Here is some iinfo output: > $ dist/linux64/bin/iinfo -v ../multichannel_16bit.psd > ../multichannel_16bit.psd : 504 x 360, 3 channel, uint16 psd > channel list: Cyan, Magenta, Yellow > oiio:BitsPerSample: 48 > XResolution: 72 > YResolution: 72 > ResolutionUnit: "in" > PixelAspectRatio: 1 > Note that the channel names are custom names that can be changed in Photoshop > (they happen to have those names because I converted from a CMYK IIRC). > > I struggled a bit since the file format specs left out at least one important > alignment detail (an issue I thankfully found mentioned in code from 2007). > I'm now to a point that the only real thing left to do is to read the actual > image data (layers and merged). > > By midterm I hope to have the following accomplished: > -Complete subimage support (index 0 for merged composite, 1 for first layer, > etc) > -Support all compression modes (Raw, RLE, ZIP, ZIP w/prediction) > -Read Bitmap image data > -Read RGB image data > -Read Indexed image data > -Read Exif and/or XMP metadata from image resources > -Split the code up (psdinput.cpp is over 1k lines now) -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
