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
>
>
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Reply via email to