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
