Oooh, pybind11 hasn't crossed my path before -- very interesting. How much
work was it to move?
--jono
On Thu, Nov 9, 2017 at 5:48 PM Larry Gritz wrote:
> Those of you who have the OIIO Python bindings on your critical paths,
> please be aware of this outstanding PR:
>
> https://github.
If I recall correctly, when this stuff was added in 2.0, there were
discussions about if this should be a requirement or not. It was decided to
be conservative we'd start with the requirement, and then look to lift it
in a later version. Looks like it's not lifted yet, but technically could
be soon
This is just a totally fascinating study of modern software. It's
fascinating that you have a spec as widely adopted as JFIF/JPEG, and
clearly the original engineers did a good job specifying some important
meta-data. I'm sure they had all sorts of use cases where this was
important.
And yet (a) v
Thanks Larry and Ghislain-
This is what I expected, just wanted to double check that I wasn't missing
something.
--jono
On Thu, Aug 27, 2015 at 11:40 AM, Ghislain Vaillant
wrote:
> On 27/08/15 19:23, Jonathan Gibbs wrote:
>
>> Has anyone played with OIIO's FFT functions
Has anyone played with OIIO's FFT functions? I've not worked with this
much, but what I'm used to seeing out of the FFT is an image with a white
pixel in the center and some matter of pixels around those.
(For instance: http://homepages.inf.ed.ac.uk/rbf/HIPR2/fourier.htm)
What I get out of OIIO i
Yes, I think ideally for those of us using Numpy for image processing, it
would be great to get a numpy.ndarray representation of the data as
efficiently (with as few copies, maybe no copies) as possible.
In my experience using Numpy is a great way to do quick one-off image
processing experiments
ut it's a start.
>
> I'm not experienced enough with numpy to know; how would you want the
> Python API to look to be most efficient for your purposes?
>
> -- lg
>
>
> On Jun 4, 2015, at 4:24 PM, Jonathan Gibbs wrote:
>
> Does anyone have a good/simple exampl
Awesome. I've tried other alternatives, but they all seem to be tripping in
one way or another over 16-bit images.
--jono
On Fri, Jun 5, 2015 at 9:04 AM Larry Gritz wrote:
> OK, let me see what I can cook up for you.
>
>
>
> On June 5, 2015 8:50:43 AM PDT, Jonathan Gibbs
&
ng to do overall, just in case
> there's some better API strategy already in there?
>
>
> On Jun 4, 2015, at 4:24 PM, Jonathan Gibbs wrote:
>
> Does anyone have a good/simple example of working with OIIO in python. I
> can get at the raw pixels nicely enough with ImageBuf.g
Does anyone have a good/simple example of working with OIIO in python. I
can get at the raw pixels nicely enough with ImageBuf.get_pixels(), but
it's not clear the best way to get those pixels back into an ImageBuf for
writing. (There is no set_pixels.)
As a side note, get_pixels returns a Python
Yes, I was. I was waiting for my wife to be ready to head over, and I
figure how better to spend the time than thinking about 6-channel images!
>From now on, I'll try to be in formal attire when posting.
--jono
___
Oiio-dev mailing list
Oiio-dev@lists.o
On Fri, Oct 17, 2014 at 10:26 AM, Larry Gritz wrote:
> That's another possibility I would entertain -- automatically upgrading
> the subsampling when a sufficiently high quality is requested.
>
This seems too magical to me. Those who are setting subsampling levels are
probably expert users and p
A bit of info which might be useful. I am not an expert here, but we used
jpeg compression a lot.
1. Our internal tools allow you to specify compression, as well as
sampling. For sampling we offer "4:2:0" (half res chroma), "4:2:2" (half
res horizonally, full res vertically) and "4:4:4" (full reso
alues it's given. I like that it does what it's told.
>
> Cheers,
> r.
>
>
> Rangi Sutton
> VFX Supervisor
> Cutting Edge
>
>
> On 25 July 2014 09:38, Jonathan Gibbs wrote:
>
>> Well, that's pretty unfriendly on Nuke's part. PNG is pretty c
Well, that's pretty unfriendly on Nuke's part. PNG is pretty clear what is
and isn't supposed to be in the file.
--jono
On Thu, Jul 24, 2014 at 3:46 PM, Rangi Sutton
wrote:
> Hey,
>
> I think it's a good thing Nuke doesn't try and second guess you and make
> "intelligent" decisions about what
A rough guess at the minimums. These are generally determined by what old
version of third party tools we're still building for:
Compiler - icc 11.1+, gcc 4.5+
Boost: 1.46.1+
OpenEXR: 1.7.1+
Python 2.x: 2.6+
Python 3.x: nope
--jono
On Tue, Sep 3, 2013 at 3:24 PM, Larry Gritz wrote:
> Two more
> I'm a little sorry now that we didn't go the extra mile on OpenEXR 2.0
and support multiple images in full generality.
That's right. I had forgotten about that limitation. Oh well, maybe 3.0!
Another possibility is just to write an imageio plugin for your "map"
> format -- OIIO can dynamically
Hello OIIO folk!
We've had a side project to look at OIIO and it's texture sampling
abilities as an alternate to our in-house library. It's been kind of hard
to compare them as the algorithms are different, but I will share some
results when we can bang them into a reasonable form.
Our in-house l
On Wed, Jun 20, 2012 at 7:38 AM, Larry Gritz wrote:
> Or, I could even see a strong argument to be made for IBA functions being
> strictly float, if you really want to eliminate all type complexity. For
> our anticipated uses, I think that's fine. I don't know about anybody
> else. Opinions?
>
On Thu, Jun 14, 2012 at 4:05 PM, Larry Gritz wrote:
> An excellent point. I'm quite happy to just live with the advice of "if
> you want to composite a weird 4-channel spectral image, it's your
> responsibility to affix an alpha channel and label it correctly."
>
+1. I didn't think of this obvi
On Wed, Jun 13, 2012 at 2:28 PM, Larry Gritz wrote:
> You think?
>
> What are the relative probabilities of somebody asking you to composite
> two CMYK images (or even *ever* seeing a CMYK image in the kind of
> environment where somebody would be tempted to use "over"), versus being
> handed an
On Wed, Jun 13, 2012 at 10:03 AM, Larry Gritz wrote:
> (Exercise for the reader: under what circumstances, and for which formats,
> could you be SURE that a 4-channel image did not contain an alpha?)
>
A CMYK TIFF image?
That's clearly a corner case, but I guess if I had two cmyk tiff images an
On Wed, May 9, 2012 at 4:55 PM, Larry Gritz wrote:
> After the 2nd or maybe 3rd, then let's pause and look at what we have and
> see if some kind of template-based refactor can even further simplify
> things for the vast majority of operations, so that the amount of new code
> for each algorithm
The cineon spec seems to say the same as dpx. "Valid component sizes
are 1-, 8-, 10-, 12-, and 16-bit integers and 32- and 64-bit reals
(IEEE floating-point)." and I think it means both Cineon and DPX.
But as Jeremy says seeing a float Cineon file in the wild would be
really unusual... it's not cl
On Esc-to-exit:
This feels very non-standard to me, and I think is legacy from IRIX. :)
On Full-screen:
There appears to be no standards, really.
* Linux apps like Firefox and various gnome image viewers do seem to use "F11".
* Mac apps seem to like "Cmd-F" or since that is usually Find,
On Mon, Apr 9, 2012 at 11:52 AM, Colin Doncaster
wrote:
> I realize that you're looking for the path of least resistance, but I guess
> my point is that being clear on using the QTDIR variable and what that means
> for CMake vs. having users rely on macports feels more general and safer - I
> thin
On Sat, Mar 31, 2012 at 11:12 AM, Larry Gritz wrote:
> Should there be a cache
> of thumbnails on disk (say, in $HOME/.ivthumb/*)?
Or a .ivthumb file in the same directory as the images? Of course one
might not be able to write there, but it is closer to the images and
could be shared by multiple
Regarding adding movie formats to OIIO:
I think it's a great idea, and it will be very useful to do things one
is prepared to do to images directly to the frames of a movie. The
sub-images notion does map well to frames. However, movie formats like
Quicktime generally also support any number of vi
On Oct 5, 2011, at 9:57 AM, Ciaran Wills wrote:
> On an aside - display windows with the origin != (0, 0) are a pain in
> the arse, and I kinda wish EXR hadn't allowed them ;)
We often have these, because our in-house tools and in-house format are happy
with them. However, we've learned painfu
he non-full
image. But at the same time, you often display the data window instead of the
display window and this it hard to make clear as well.
--jono --mobile--
On Oct 5, 2011, at 9:56 AM, Larry Gritz wrote:
> On Oct 5, 2011, at 8:31 AM, Jonathan Gibbs wrote:
>
>> Since we'
Short reply: I agree with Larry on this one.
Longer reply:
Based on how things have been going here at DWA, I'm increasingly
seeing the "dislpayWindow" and simply metadata, and increasingly
arbitrary metadata. It's useful for sure, but no everyone dealing with
the image has the same notion of wha
31 matches
Mail list logo
