I loaded the image in Nuke, added a "SideBySide" node between the read node and the viewer, and what I see in the preview window is side by side images where they both have a big "L", neither has "R".
Can you confirm? On Aug 14, 2013, at 12:18 PM, Larry Gritz wrote: > Aha, I misunderstood. I thought you meant that you could neither read nor > write. > > The underlying "libDPX" looks like it should support multiple image elements > (that's what DPX calls subimages) for both reading and writing. > > The dpxinput.cpp code looks like it supports reading multiple elements, but > although the test file you sent is reported as having two elements, they both > look the same (with an "L", I presume the other is intended to have "R"?). I > don't yet know if that is because we have a bug, or because your file has two > identical elements. Can you verify on your end? Do you have an app that can > view the two subimages and be sure that they are actually different? > > The dpxoutput.cpp is, indeed, written in such a way that it ignores the > possibility of multiple elements when writing the file, but I think it's a > pretty simple matter to fix it up. Let me take a stab at it. > > > > On Aug 14, 2013, at 11:09 AM, Mark Boorer wrote: > >> Thanks again Larry, >> >> Just confirming though, this is for reading sub image DPX's. The writing is >> still very much unimplemented? >> >> Cheers, >> Mark >> >> On 14/08/2013 6:30 PM, "Larry Gritz" <[email protected]> wrote: >> Thanks for the test case. I briefly glanced at the code yesterday, and it's >> structured as if it expects subimages to work in the DPX code. So it's >> probably just a bug, not a case of it being written without considering >> subimages at all and needs a total rewrite. I'll try to take a quick look >> and see if it's something obvious, I'll let you know what I find. >> >> -- lg >> >> >> On Aug 14, 2013, at 1:34 AM, Mark Boorer wrote: >> >>> Hi Larry, >>> >>> Thanks for your quick reply and willingness to take a look. >>> I've attached an example file (its a test plate so no copyright issues). It >>> was written using an internal, quite old library, and is fine for reading >>> back by said library (it also seems okay in RV). I'm looking to transition >>> new code over to OIIO, so as I mentioned, if you don't have time to tinker >>> with it, I'm happy to take a stab :) >>> >>> File can be downloaded from here: >>> https://docs.google.com/file/d/0B7tMukhco9MwVjZWa09ZWW04Vm8/edit?usp=sharing >>> >>> Thanks! >>> Mark >>> >>> >>> On Tue, Aug 13, 2013 at 8:20 PM, Larry Gritz <[email protected]> wrote: >>> Nobody is working on it as far as I know. We use the DPX support >>> extensively here, but I think our convention is to save L & R as separate >>> images, so it hadn't been brought to my attention that our DPX subimage >>> support was lacking. A fix for that would be very welcome. >>> >>> But before you dive in too deep... if you want to send me (privately is ok, >>> I won't share) one of these stereo DPX files, I would be happy to take a >>> *quick* look at the DPX code -- which I didn't write, but am at least >>> passingly familiar with -- just to see if it's an extremely minor >>> alteration (or even an obvious bug) to fix subimages, and if so I can just >>> bang it out. But if it's more extensive, I'll let you know because if I >>> don't know immediately how to do it, you'll probably get a fix faster if >>> you are able to do it yourself rather than wait for me to free up a bigger >>> block of time. >>> >>> -- lg >>> >>> >>> On Aug 13, 2013, at 11:50 AM, Mark Boorer wrote: >>> >>> > Hi, >>> > >>> > I'm looking to read/write some stereo DPX files I have, and I noticed >>> > that the DPXOutput class explicitly does not support subimages. >>> > I've also tried reading some files that contain subimages (written >>> > from a custom library), but I'm unable to get the data out of them >>> > after calling seek_subimage() (though the seek call works as >>> > expected). >>> > >>> > Is anyone presently working on supporting subimages in the DPX writer? >>> > I'm not too familiar with the guts of the format, but I do have access >>> > to the spec and may be motivated to add support. >>> > >>> > Cheers, >>> > Mark >>> > >>> >>> -- >>> 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 >> >> -- >> 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 > > -- > Larry Gritz > [email protected] > > -- Larry Gritz [email protected]
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
