Wow, you are a legend! Thank you so much for putting the time in to fix it!
Cheers, Mark On 15/08/2013 7:15 PM, "Larry Gritz" <[email protected]> wrote: > Update: It turned out that it was a bit of an overhaul of DPXOutput to get > it in shape to output subimage, but I dove in and did it last night. I > also found some bugs in the underlying implementation of libdpx. > > But I got success! -- I can write multi-image DPX files, read them back > correctly, as well as read the sample image you provided. Whew! > > I left it late last night working, but with some cleanup left to do. If I > can get some of my real work out of the way first, I'll try to get a chance > to tidy things up enough to send out a pull request today. Tonight at the > latest. > > -- lg > > > On Aug 14, 2013, at 12:51 PM, Mark Boorer wrote: > > 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 > > > -- > 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
