Hi Larry, It should contain an image with L and an image with R. The view of the plant in the center is also from a different camera in the R eye.
I'm not sure if Nuke allows for subimages in DPX files, and I've never been able to view these images in Nuke. (They are able to be read by our own grading / playback software). It could be that our library is doing things wrong, but not having an alternative library to write a stereo DPX, I was unable to test it ;) To answer your previous question, your initial summation was correct. I am unable to read or write stereo DPX's with the OpenImageIO DPX plugin (assuming my stereo DPX is valid). Thanks! Mark On Wed, Aug 14, 2013 at 8:34 PM, Larry Gritz <[email protected]> wrote: > 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 > >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
