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
