casesensitive);
}, "name"_a, "searchtype"_a = TypeUnknown,
"casesensitive"_a = false)
On Tue, Jul 14, 2020 at 4:22 PM Andrew Gartner wrote:
>
> Yikes nvm, that' a lambda with an empty function body so that doesn't
> fix it. If anyone has an
Yikes nvm, that' a lambda with an empty function body so that doesn't
fix it. If anyone has any thoughts on the root issue that'd be great
though
~Andrew
On Tue, Jul 14, 2020 at 12:49 PM Andrew Gartner wrote:
>
> Hey Larry (et all),
>
> I was trying to use erase_attribute from py
Hey Larry (et all),
I was trying to use erase_attribute from python in oiio 2.0.x since
that's what I'm currently using. Looks like the python function wrap
isn't working. No matter what I do with casting things etc. For
example
...Load some image and store it's spec via spec()...
for attribute
ough, because there's a spot
> in the testsuite where this is required (
> https://github.com/OpenImageIO/oiio/blob/master/testsuite/python-imagebuf/src/test_imagebuf.py#L137).
> It's not exactly this construct, but because an ImageBuf can only hold one
> data type, underneath it's doin
Hey Larry (and anyone else who may be able to help),
Just moved to OIIO 2.0 and realized I've got issues with how i was using
write_scanlines from python now.
Prior to 2.x I had been passing oiio.UNKNOWN to the call as I had been
treating all my pixel data as raw char*'s under the hood. I was
Hey Deke,
I don't have the exact code handy, but I've managed to do this a few times.
If memory serves you just need to create imagespecs for each part with the
proper metadata you want per-part and use the oiio.AppendSubimage with
ImageOutput after calling open().
outFile = foo.exr
specs =
I've been using numpy from oiio reads for a few years now and the main
reason I prefer it is the datatype flexibility (half floats are supported
natively for one thing). So that was my main reason to use it (I'm
converting all oiio reads to numpy across a lot of code at the moment)
In short I'm
supported production release, so even the
> stuff i won't backport will no longer be considered experimental.
>
>
> On Sep 13, 2016, at 5:48 PM, Andrew Gartner <andrewgart...@gmail.com>
> wrote:
>
> Ah ok, that would make much more sense then. Also do you have any
> ob
in double quotes,
> in case the shell is getting confused by the brackets.
>
> It works for me, BTW.
>
>
> On Sep 13, 2016, at 2:09 PM, Andrew Gartner <andrewgart...@gmail.com>
> wrote:
>
> Sure thing, here's what i get in my shell with this command. I'm guessing
> it'
will fix that
> in the patch.
>
>
>
> On Sep 13, 2016, at 1:28 PM, Andrew Gartner <andrewgart...@gmail.com>
> wrote:
>
> Hey Larry,
>
> Thanks for the super fast response.
>
> The patch worked from python like a charm once I set the type desc to the
> attribute ca
Hey all,
Has anyone tried to add chromaticies to an EXR by hand via oiiotool (or
python)?
We're starting to expand our color support so for testing I'm trying to add
it by hand. I believe the attribute is a special case in the EXR spec that
needs 8 floats (in an array?). however trying this on
, but I'll try
to do so after my code is all patched up.
Also looks like the Travis CI build failed on this PR so I don't know if
that would hold up review/merging but I figured I'd bring it up in case it
fell under the radar.
~Andrew
On Mon, Feb 22, 2016 at 3:03 PM, Andrew Gartner <andrewg
equivalent) into both branches.
>
>
> On Feb 22, 2016, at 2:32 PM, Andrew Gartner <andrewgart...@gmail.com>
> wrote:
>
> Thanks much Larry, I'll give it a whirl. just out of curiousity, is that
> commit for the 1.6 branch(es) or just master (which I guess is 1.7 at this
>
t moving forward.
>
>
>
> On Feb 19, 2016, at 11:49 AM, Haarm-Pieter Duiker <l...@duikerresearch.com>
> wrote:
>
> Two thumbs up! (packed into one float thumbs up)
>
> HP
>
>
>
>
> On Fri, Feb 19, 2016 at 10:21 AM, Andrew Gartner <andrewgart...@gmail.com>
;
>>
>>
>> On Thu, Feb 18, 2016 at 1:23 PM, Larry Gritz <l...@larrygritz.com> wrote:
>>
>>> I don't have especially strong feelings about this one way or the other.
>>>
>>> Just returning a raw data byte array matches the C++ behavior more
>&
t's
> a type that exists in Python, return that type.
> 2b. If you ask for UNKNOWN and it's a "mixed type" file, or a single type
> but one that doesn't exist in Python, or the type you ask for doesn't exist
> in Python, return raw data packed into an unsigned char array.
Hey all,
Apologies if this has come up before, but I'm curious if anyone had
considered exposing ImageInput.read_native_scanlines() on the python side
before. The reason I ask is mainly because the half datatype doesn't exist
in the native python array class which OIIO uses for python reads.
I *think* you can convert between the two without creating any copies
python (I think it's possible because both array and numpy.ndarray
implement the python buffer interface, but I may be wrong). I didn't spend
a ton of time looking at it and was ok with eating the cost of the copy if
it made
18 matches
Mail list logo
