Okay, I was not sure about BitsPerSample. I had a FIXME comment in the code to check back on that because I wasn't sure if sample=pixel or sample=channel. Did not realize I only need to set that under certain circumstances. I will fix this.
Ah I wasn't sure yet how OIIO handled other color spaces, thanks for clearing that up. I'll await input on the "open with configuration" option. I haven't pushed the code yet, I will make sure to push most tonight. Need to do some cleanup (I'm much happier with the code overall than I was before though). As for Exif/XMP, I wanted to ask a question about that: Is there reason not to use Adobe's XMP library ( http://www.adobe.com/devnet/xmp.html)? It is BSD licensed. I saw the current regex hackery and just thought it might be easier. It /is/ kind of a pain to build and required adding in some missing includes (cstring at least) but it might be worth looking into. I can use the existing code for now though. On Fri, Jun 24, 2011 at 12:32 PM, Larry Gritz <[email protected]> wrote: > 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 >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
