We're mostly running 1.1 here, but the tool utilising the stereo writing via OIIO isn't even finished yet, so I'm happy to wait till the next major version (assuming that's not terribly far away). Until then, i'll just keep using the copy I compiled this morning and be mindful that any further hiccups are probably related to its Beta nature. No need to back port from my perspective.
Cheers, Mark On Fri, Aug 16, 2013 at 5:46 PM, Larry Gritz <[email protected]> wrote: > Great, I'm glad it checks out on your end. > > It's such a big change to the DPX code that I'm not comfortable merging it > into a release branch immediately. So here's my plan: I'll merge it into > master fairly soon, and if it seems well behaved after some time there (at > SPI, we build from the master branch, so it will get thoroughly production > tested), then I'll think about back-porting it to 1.2. (If you guys are on > 1.2 and start itching for this, just let me know.) > > -- lg > > > On Aug 16, 2013, at 9:26 AM, Mark Boorer wrote: > > Hey Larry, > > I managed to compile your version today, and it worked great! I was able > to read and write both stereo and mono DPX's, and they were viewable in > both iv and our own in house playback software. > > I've never been able to read back DPX's with subimages in Nuke. I don't > think it supports them. Also I think i was mistaken when i mentioned that > RV could read them. I must've been looking at the source EXRs :/ . So I do > believe you are correct that OIIO is now the most complete implementation :D > > Everything is groovy from my perspective, so assuming things look okay to > you, I guess we'll see this in a future release. > > Thanks again for all your effort! > > Cheers, > Mark > > > > On Thu, Aug 15, 2013 at 11:42 PM, Larry Gritz <[email protected]> wrote: > >> Incidentally, I was never able to get Nuke to properly read those stereo >> files, no matter what I do it only recognizes one of the views. And also, >> even for single-image DPX files, Nuke gives errors if you try to feed it a >> DPX file with 'float' data, ugh. OIIO may very well be the most complete >> DPX implementation readily available. If all else fails, you can use >> OIIO's 'iv' to view these stereo files (with the '<' and '>' hotkeys >> stepping through the subimages/views within a file). >> >> Oh, and thanks for pointing all this out, Mark. Even though this >> deficiency had not yet been noticed where I work, surely it was only a >> matter of time before somebody sent us stereo DPX (or wanted to generate >> them) and found the problem. It's always nice to fix a bug before it ever >> becomes an issue that could hold us up. >> >> -- lg >> >> >> On Aug 15, 2013, at 3:33 PM, Larry Gritz wrote: >> >> https://github.com/OpenImageIO/oiio/pull/658 >> >> It's a pretty big change to the DPX module, which is a fairly important >> file format for us, so it does make me a little nervous. It would be very >> helpful if you could build the branch referenced in the pull request (git >> pull https://github.com/lgritz/oiio lg-dpx) and give that a spin on a >> bunch of your files, that would give me a lot more confidence about >> committing it to master. >> >> -- lg >> >> >> On Aug 15, 2013, at 11:40 AM, Mark Boorer wrote: >> >> 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 >> >> >> -- >> Larry Gritz >> [email protected] >> >> >> _______________________________________________ >> 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] > > > > _______________________________________________ > 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
