Hi,
being new to the list, please forgive me if I've missed something, is
the goal to match existing apps in general or just to match specific
applications as a reference?
I notice the definition for Lanczos3 for instance is not my expected
windowing function which is something more like:
On Wed, Aug 31, 2011 at 6:08 PM, Larry Gritz l...@larrygritz.com wrote:
There is no specific goal to match any other application, but the filtering
is tricky and easy to get wrong (as I have clearly botched it in this case,
despite having written it many times over 25 years!). So when we
Hi,
Using oiio 0.10.2, I am unable to resize an image:
iprocess z.exr --resize 32 32 -o out.exr
fails with an 'assertion' at line 357 of iprocess.cpp
I'm assuming this is due to the files being half float and not 32 bit
float, is this expected?
Thanks
Kevin
z.exr
Description: Binary data
...@larrygritz.com wrote:
How important is it to you to be locked to 0.10? In the development trunk,
we have iprocess being rapidly made obsolete by oiiotool, so I'm a little
hesitant to put any work into fixing iprocess.
-- lg
On Sep 5, 2011, at 8:45 AM, Kevin Wheatley wrote:
Hi,
Using
Sent on the move...
On 2 Jul 2012, at 21:20, Stefan Stavrev stavrevste...@gmail.com wrote:
You mean it is complicated because conversion formulas are expensive, or lack
of agreement in the whole color spaces thing? I mean, there is a lot of
confusion about the color spaces, different
Just to add to this, when I typically want to draw a histogram for analytical
reasons I like to see every bin clearly. This is usually to look for missing
bits or bins in integer image representations.
Given that we typically need 10 bits worth as a minimum and increasingly 12, I
would want
For some plugin work we're at the choice of vendors, which means gcc 4.1.x
(Nuke/Maya/etc) on Linux :-( Luckily we're only using OIIO standalone so
for that we're 4.6.1 currently, OSX is 4.2.1. Windows is VS2010.
Boost wise we're 1.47 - probably because nobody tried building a newer one
in some
I'd like to add that you may also need to consider a Von Kries Ives style
chromatic adaptation if moving between colour spaces with different white
points see http://www.brucelindbloom.com/index.html?Eqn_ChromAdapt.html for
an introduction.
Kevin
___
:48 GMT+02:00 Jerome Esnault esnault.jer...@gmail.com:
OK, thanks!
It could be great if this could be part of the OIIO lib feature :)
Many thanks.
Best,
Jerome
2015-04-22 12:17 GMT+02:00 Kevin Wheatley kevin.j.wheat...@gmail.com:
using dcraw you can do something like...
dcraw -4 -o0 -T
For those worried about binary size, under Linux you can do something
like the following, which builds with the '-g' flag thus has all the
debug information in the object, then extracts the debug info to a
separate file and then strips it from the main object and adds back a
reference to the debug
Sent on the go...
> On 15 Jan 2016, at 21:09, Peter Pearson wrote:
>
> Replies inline...
>
>> On
>
> Also, reading and writing of values in OpenEXR goes through ImfXdr.h's
> conversion routines doing bitshifting for I assume endianness conversion? - I
> guess the
Sent on the go...
> On 19 May 2016, at 22:48, Jonathan Egstad wrote:
>
>
> Nuke's JPEG reader/writer is interpreting the xdensity and ydensity fields as
> sizes, not densities.
But does it not depend on the other header field if the units header has a non
zero value
https://www.thefoundry.co.uk/products/nuke/developers/100/ndkreference/examples/jpegReader.cpp
Has the reader code ...
In the constructor there is bits dealing with the density values.
Kevin
Sent on the go...
> On 19 May 2016, at 22:21, Jonathan Egstad wrote:
>
> If
On Thu, Sep 15, 2016 at 4:27 PM, Karl Rasche wrote:
> These conversions ended up taking an obscene amount of the decode time. I
> don't remember exact numbers, but it was in the neighbourhood
> of 20-30%.
sounds about right when I was looking on my machine trying to enable
So here are the kinds of things we do...
// Setup as much as possible to mean linear 16 bit
RawProcessor.imgdata.params.output_bps = 16;
RawProcessor.imgdata.params.gamm[0] = 1;
RawProcessor.imgdata.params.gamm[1] = 1;
RawProcessor.imgdata.params.no_auto_bright = 1;
Closest I've seen to a quality scale was this email from Karl
https://lists.nongnu.org/archive/html/openexr-devel/2014-08/msg00049.html
Kevin
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
Sent on the go...
> On 9 Jun 2017, at 18:03, Jason Iversen wrote:
> Perfectly on topic! Yes, this is work we definitely need to do. The Foundry
> should have added such a feature years ago, in my opinion; I see historical
> requests from 2012 on this same topic out there.
to further what Larry is saying, you might want to check out using
numeric limits to initialise min and max based on your source data
type, (or at least for float as that is the type of your min and max
variables) see https://en.cppreference.com/w/cpp/types/numeric_limits/lowest
So you should
18 matches
Mail list logo