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
