Awesome. Thanks!
On Fri, Aug 16, 2013 at 6:15 PM, Larry Gritz <[email protected]> wrote: > Great. All other things being equal, this feels like a 1.3 feature to me. > But if you come to the point where you need it backported, just let me > know. > > -- lg > > > > On Aug 16, 2013, at 10:13 AM, Mark Boorer wrote: > > 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 > > > -- > 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
