Mark, I'm doing some testing with your stereo test image. How did you create that image?
Sam. On Fri, Aug 16, 2013 at 10:17 AM, Mark Boorer <[email protected]> wrote: > 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 > >
_______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
