Aha. I've posted a new version of the patch. Try now.
-- lg
On Jul 5, 2013, at 6:50 PM, Larry Gritz wrote:
> Aha, yes, I can reproduce something weird here. Stay tuned...
>
>
>
> On Jul 5, 2013, at 5:44 PM, Andrew Wood wrote:
>
>> Try putting this through autotrim:
>>
>>
>>
>> before:
>> /var/tmp/flower.exr:
>>
>> file format version: 2, flags 0x0
>> channels (type chlist):
>> B, 16-bit floating-point, sampling 1 1
>> G, 16-bit floating-point, sampling 1 1
>> R, 16-bit floating-point, sampling 1 1
>> compression (type compression): zip, individual scanlines
>> dataWindow (type box2i): (0 0) - (1919 1079)
>> displayWindow (type box2i): (0 0) - (1919 1079)
>> lineOrder (type lineOrder): increasing y
>> nuke/input/bitsperchannel (type string): "32-bit float"
>> nuke/input/ctime (type string): "2013-07-01 14:11:50"
>> nuke/input/filename (type string): "/var/tmp/test.exr"
>> nuke/input/filereader (type string): "exr"
>> nuke/input/filesize (type int): 2761776
>> nuke/input/height (type int): 1080
>> nuke/input/mtime (type string): "2013-07-01 14:11:50"
>> nuke/input/width (type int): 1920
>> nuke/node_hash (type string): "7a4990d4f3aa42ab"
>> pixelAspectRatio (type float): 1
>> screenWindowCenter (type v2f): (0 0)
>> screenWindowWidth (type float): 1
>>
>>
>> after:
>>
>>
>> /var/tmp/flowerout.exr:
>>
>> file format version: 2, flags 0x0
>> Exif:ImageHistory (type string):
>> "/dd/tools/cent5_64/package/openimageio/1.2.0-alpha01/bin/oiiotool
>> /var/tmp/flower.exr --autotrim -o /var/tmp/flowerout.exr"
>> Software (type string): "OpenImageIO 1.3.0dev :
>> /dd/tools/cent5_64/package/openimageio/1.2.0-alpha01/bin/oiiotool
>> /var/tmp/flower.exr --autotrim -o /var/tmp/flowerout.exr"
>> capDate (type string): "2013:07:05 17:42:03"
>> channels (type chlist):
>> B, 16-bit floating-point, sampling 1 1
>> G, 16-bit floating-point, sampling 1 1
>> R, 16-bit floating-point, sampling 1 1
>> compression (type compression): zip, individual scanlines
>> dataWindow (type box2i): (0 0) - (0 0)
>> displayWindow (type box2i): (0 0) - (1919 1079)
>> lineOrder (type lineOrder): increasing y
>> nuke/input/bitsperchannel (type string): "32-bit float"
>> nuke/input/ctime (type string): "2013-07-01 14:11:50"
>> nuke/input/filename (type string): "/var/tmp/test.exr"
>> nuke/input/filereader (type string): "exr"
>> nuke/input/filesize (type int): 2761776
>> nuke/input/height (type int): 1080
>> nuke/input/mtime (type string): "2013-07-01 14:11:50"
>> nuke/input/width (type int): 1920
>> nuke/node_hash (type string): "7a4990d4f3aa42ab"
>> pixelAspectRatio (type float): 1
>> screenWindowCenter (type v2f): (0 0)
>> screenWindowWidth (type float): 1
>>
>>
>> Sorry for the image size, it's a hard problem to reproduce.
>> thanks again for your help!
>> Andrew
>>
>>
>>
>> Andrew Wood
>> Pipeline Engineer, Digital Domain
>> x2914
>>
>>
>> On Fri, Jul 5, 2013 at 4:06 PM, Andrew Wood <[email protected]> wrote:
>> ah nuts, you're right. I'm having problems with it on a larger proprietary
>> image, where it's changing the data window to 0 (as in out.exr)
>>
>> I was trying to reproduce with smaller images. let me play around some more.
>>
>>
>>
>> Andrew Wood
>> Pipeline Engineer, Digital Domain
>> x2914
>>
>>
>> On Fri, Jul 5, 2013 at 3:09 PM, Larry Gritz <[email protected]> wrote:
>> Are you absolutely sure that out.exr is the right file? Your input was RGB,
>> but out.exr was RGBA, that looks suspicious, like maybe you were using a
>> different file as input than you may have thought.
>>
>>
>>
>> On Jul 5, 2013, at 3:05 PM, Larry Gritz wrote:
>>
>>> Works for me!
>>>
>>> Hmmm...
>>>
>>> Maybe just to be sure, do a 'make nuke' and then make it from scratch?
>>>
>>> Also, maybe try pulling exactly what I have to be sure (like I said in the
>>> earlier email), instead of applying just the patch? Just in case?
>>>
>>> If this still doesn't work, maybe do a 'make test' and let me know if
>>> anything else interesting fails? (I'm expecting a failure for 'psd', but
>>> everything else should be fine.)
>>>
>>>
>>>
>>>
>>> On Jul 5, 2013, at 2:45 PM, Andrew Wood wrote:
>>>
>>>> Did some simple tests. My simple colorwheel worked, but a nonsymmettrical
>>>> test didn't. What do you think?
>>>>
>>>>
>>>> /var/tmp/in.exr:
>>>>
>>>> file format version: 2, flags 0x0
>>>> channels (type chlist):
>>>> B, 16-bit floating-point, sampling 1 1
>>>> G, 16-bit floating-point, sampling 1 1
>>>> R, 16-bit floating-point, sampling 1 1
>>>> compression (type compression): zip, individual scanlines
>>>> dataWindow (type box2i): (0 0) - (19 19)
>>>> displayWindow (type box2i): (0 0) - (19 19)
>>>> lineOrder (type lineOrder): increasing y
>>>> pixelAspectRatio (type float): 1
>>>> screenWindowCenter (type v2f): (0 0)
>>>> screenWindowWidth (type float): 1
>>>>
>>>> dataWindow is 0,0 and looks like its falling back on an HD formatting
>>>> here...
>>>>
>>>> /var/tmp/out.exr:
>>>>
>>>> file format version: 2, flags 0x0
>>>> Exif:ImageHistory (type string):
>>>> "/dd/tools/cent5_64/package/openimageio/1.2.0-alpha01/bin/oiiotool
>>>> /var/tmp/test.exr --autotrim -o /var/tmp/out.exr"
>>>> Software (type string): "OpenImageIO 1.3.0dev :
>>>> /dd/tools/cent5_64/package/openimageio/1.2.0-alpha01/bin/oiiotool
>>>> /var/tmp/test.exr --autotrim -o /var/tmp/out.exr"
>>>> capDate (type string): "2013:07:05 14:36:20"
>>>> channels (type chlist):
>>>> A, 32-bit floating-point, sampling 1 1
>>>> B, 32-bit floating-point, sampling 1 1
>>>> G, 32-bit floating-point, sampling 1 1
>>>> R, 32-bit floating-point, sampling 1 1
>>>> compression (type compression): piz
>>>> dataWindow (type box2i): (0 0) - (0 0)
>>>> displayWindow (type box2i): (0 0) - (1919 1079)
>>>> lineOrder (type lineOrder): increasing y
>>>> pixelAspectRatio (type float): 1
>>>> screenWindowCenter (type v2f): (0 0)
>>>> screenWindowWidth (type float): 1
>>>>
>>>>
>>>> this is how nuke spits it out:
>>>>
>>>>
>>>> /var/tmp/out2.exr:
>>>>
>>>> file format version: 2, flags 0x0
>>>> channels (type chlist):
>>>> B, 16-bit floating-point, sampling 1 1
>>>> G, 16-bit floating-point, sampling 1 1
>>>> R, 16-bit floating-point, sampling 1 1
>>>> compression (type compression): zip, individual scanlines
>>>> dataWindow (type box2i): (5 4) - (15 14)
>>>> displayWindow (type box2i): (0 0) - (19 19)
>>>> lineOrder (type lineOrder): increasing y
>>>> pixelAspectRatio (type float): 1
>>>> screenWindowCenter (type v2f): (0 0)
>>>> screenWindowWidth (type float): 1
>>>>
>>>> thanks so much for your help!
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> Andrew Wood
>>>> Pipeline Engineer, Digital Domain
>>>> x2914
>>>>
>>>>
>>>> On Fri, Jul 5, 2013 at 1:17 PM, Larry Gritz <[email protected]> wrote:
>>>> Yeah, I'm sure it also works just fine to apply the patch directly.
>>>>
>>>>
>>>> On Jul 5, 2013, at 1:14 PM, Andrew Wood wrote:
>>>>
>>>>> thanks for the heads up. I have the master checked out, so I just did
>>>>>
>>>>> curl https://github.com/OpenImageIO/oiio/pull/635.patch -k | git am
>>>>>
>>>>> I believe that's the same thing, although I'm still learning my way
>>>>> around git.
>>>>>
>>>>>
>>>>>
>>>>> Andrew Wood
>>>>> Pipeline Engineer, Digital Domain
>>>>> x2914
>>>>>
>>>>>
>>>>> On Fri, Jul 5, 2013 at 1:10 PM, Larry Gritz <[email protected]> wrote:
>>>>> Just to be clear -- I haven't merged this into master yet, you'll need to
>>>>> pull from the branch mentioned in the pull request, like this:
>>>>>
>>>>> git pull https://github.com/lgritz/oiio lg-trim
>>>>>
>>>>>
>>>>>
>>>>> On Jul 5, 2013, at 11:44 AM, Andrew Wood wrote:
>>>>>
>>>>>> sorry, didn't see this. I'll give it a go!
>>>>>>
>>>>>>
>>>>>>
>>>>>> Andrew Wood
>>>>>> Pipeline Engineer, Digital Domain
>>>>>> x2914
>>>>>>
>>>>>>
>>>>>> On Thu, Jul 4, 2013 at 11:15 PM, Larry Gritz <[email protected]> wrote:
>>>>>> https://github.com/OpenImageIO/oiio/pull/635
>>>>>>
>>>>>> Try the patch in this pull request, see if that does what you expect.
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Jun 28, 2013, at 6:30 PM, Andrew Wood wrote:
>>>>>>
>>>>>>> yeah, that's exactly right. Same size image, just set the data window
>>>>>>> automatically. If you're familiar with nuke, the Write node has an
>>>>>>> "autocrop" button.
>>>>>>>
>>>>>>> would be much appreciated!
>>>>>>>
>>>>>>> one of these days, I need to read through all of your docs and start
>>>>>>> helping out! Thanks for all your amazing work. it's a fantastic
>>>>>>> toolset.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Andrew Wood
>>>>>>> Pipeline Engineer, Digital Domain
>>>>>>> x2914
>>>>>>>
>>>>>>>
>>>>>>> On Fri, Jun 28, 2013 at 4:02 PM, Larry Gritz <[email protected]>
>>>>>>> wrote:
>>>>>>> The "autocrop" feature that it refers to means that oiiotool
>>>>>>> automatically behaves as if they had specified --croptofull, if and
>>>>>>> only if outputting to a file format that doesn't support separate data
>>>>>>> and display windows. That's the default, and you turn it off with
>>>>>>> --noautocrop.
>>>>>>>
>>>>>>> You're looking for something different -- if I understand properly, you
>>>>>>> want to shrink the data window so that it encloses the minimal area
>>>>>>> with non-black pixels, right?
>>>>>>>
>>>>>>> There is no such functionality in oiiotool at the moment, but it would
>>>>>>> be easy to add. I'll try to take a whack at it over the weekend.
>>>>>>>
>>>>>>> -- lg
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Jun 28, 2013, at 11:51 AM, Andrew Wood wrote:
>>>>>>>
>>>>>>> > I see this flag:
>>>>>>> >
>>>>>>> > --noautocrop Do not automatically crop images whose formats
>>>>>>> > don't support separate pixel data and full/display windows
>>>>>>> >
>>>>>>> > I'm reading an exr (display window same as data window) and
>>>>>>> > outputting an exr. I'd love an autocrop behavior to set the bounding
>>>>>>> > box. I was thinking that is what it would do automatically based on
>>>>>>> > that flag.
>>>>>>> >
>>>>>>> > But that does not seem to be the case. Am I missing something
>>>>>>> > obvious? oiio 1.1.9
>>>>>>> >
>>>>>>> > thanks!
>>>>>>> > Andrew
>>>>>>> >
>>>>>>> >
>>>>>>> > oiiotool input.exr -o /var/tmp/test.exr
>>>>>>> >
>>>>>>> > channels (type chlist):
>>>>>>> > A, 16-bit floating-point, sampling 1 1
>>>>>>> > B, 16-bit floating-point, sampling 1 1
>>>>>>> > G, 16-bit floating-point, sampling 1 1
>>>>>>> > R, 16-bit floating-point, sampling 1 1
>>>>>>> > fire_color.b, 16-bit floating-point, sampling 1 1
>>>>>>> > fire_color.g, 16-bit floating-point, sampling 1 1
>>>>>>> > fire_color.r, 16-bit floating-point, sampling 1 1
>>>>>>> > fire_mask, 16-bit floating-point, sampling 1 1
>>>>>>> > smoke_color.b, 16-bit floating-point, sampling 1 1
>>>>>>> > smoke_color.g, 16-bit floating-point, sampling 1 1
>>>>>>> > smoke_color.r, 16-bit floating-point, sampling 1 1
>>>>>>> > smoke_mask, 16-bit floating-point, sampling 1 1
>>>>>>> > comment (type string): "none"
>>>>>>> > compression (type compression): zip, individual scanlines
>>>>>>> > dataWindow (type box2i): (0 0) - (2251 967)
>>>>>>> > displayWindow (type box2i): (0 0) - (2251 967)
>>>>>>> > lineOrder (type lineOrder): increasing y
>>>>>>> > pixelAspectRatio (type float): 1
>>>>>>> > screenWindowCenter (type v2f): (0 0)
>>>>>>> > screenWindowWidth (type float): 1
>>>>>>> >
>>>>>>> > channels (type chlist):
>>>>>>> > A, 16-bit floating-point, sampling 1 1
>>>>>>> > B, 16-bit floating-point, sampling 1 1
>>>>>>> > G, 16-bit floating-point, sampling 1 1
>>>>>>> > R, 16-bit floating-point, sampling 1 1
>>>>>>> > fire_color.b, 16-bit floating-point, sampling 1 1
>>>>>>> > fire_color.g, 16-bit floating-point, sampling 1 1
>>>>>>> > fire_color.r, 16-bit floating-point, sampling 1 1
>>>>>>> > fire_mask, 16-bit floating-point, sampling 1 1
>>>>>>> > smoke_color.b, 16-bit floating-point, sampling 1 1
>>>>>>> > smoke_color.g, 16-bit floating-point, sampling 1 1
>>>>>>> > smoke_color.r, 16-bit floating-point, sampling 1 1
>>>>>>> > smoke_mask, 16-bit floating-point, sampling 1 1
>>>>>>> > comment (type string): "none"
>>>>>>> > compression (type compression): zip, multi-scanline blocks
>>>>>>> > dataWindow (type box2i): (0 0) - (2251 967)
>>>>>>> > displayWindow (type box2i): (0 0) - (2251 967)
>>>>>>> > lineOrder (type lineOrder): increasing y
>>>>>>> > pixelAspectRatio (type float): 1
>>>>>>> > screenWindowCenter (type v2f): (0 0)
>>>>>>> > screenWindowWidth (type float): 1
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> >
>>>>>>> > Andrew Wood
>>>>>>> > Pipeline Engineer, Digital Domain
>>>>>>> > x2914
>>>>>>> > _______________________________________________
>>>>>>> > 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
>>>>
>>>> --
>>>> Larry Gritz
>>>> [email protected]
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> [email protected]
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>
>>>>
>>>> <in.exr><out.exr><out2.exr>_______________________________________________
>>>> 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
>>
>>
>>
>> <flower.exr>_______________________________________________
>> 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
