No thats ok. I think I now have something working in nuke. I just want some test images written with a 3rd party tool that I can use to confirm that I'm not breaking OIIO.
Sam. On Tue, May 13, 2014 at 4:05 PM, Mark Boorer <[email protected]> wrote: > Hi Sam, > > The original image was written using a proprietary dpx library, but now > that OIIO can replicate its behaviour, I am using that instead. > > Are you having trouble reading / writing stereo dpx's with OIIO? > > I can dig up some example code if you like. > > Cheers, > Mark > On 13 May 2014 23:57, "Sam Richards" <[email protected]> wrote: > >> 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 >> >> > _______________________________________________ > 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
