Re: [Oiio-dev] Review: filters updated: sinc, blackman-harris, gaussian

[Kevin Wheatley]

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:

sinc(position) * sinc(position / size)

where size = 3 for a 3 lobed window.

Also i wondered what the 'phase' of the filters does the
implementation sample at - does it always results in all pixels being
filtered when exactly halving/doubling, or does the filter only
effectively sample at 0.0 and thus return a single sample for half the
outputs? (Once I have it compiled, I can obviously run it to find out,
there appears to be a lot of +/- 0.5s in the code and I'm not as good
as the compiler :-).

Thanks

Kevin

On Wed, Aug 31, 2011 at 2:12 AM, Jeremy Selan jeremy.se...@gmail.com wrote:
 https://github.com/OpenImageIO/oiio/pull/157

 The math and filter radii have been updated for a bunch of filters to better
 match existing performance in other common applications. (The biggest change
 being sinc, which is now much sharper.)

 Filter results comparison:
 pow2 downres (4K - 128 tested)
 - katana 2.7.12
 - ImageMagick 6.3.6
 - prman 16.0 txmake

 box: oiio, prman, katana, imagemagick match
 lanczos3: oiio, katana, imagemagick match. prman is far sharper
 (perhaps lanczos2?)
 sinc: oiio, prman match. Katana is slighly softer. imagemagick is much softer
 blackman harris: all differ. In order of decreasing sharpness...
 imagemagick, oiio, prman
 catrom: oiio, imagemagick, prman match
 gaussian: oiio, prman, katana roughly match. imgmagick is sharper

 -- Jeremy
 ___
 Oiio-dev mailing list
 Oiio-dev@lists.openimageio.org
 http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] Review: filters updated: sinc, blackman-harris, gaussian

[Kevin Wheatley]

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 match the 
 results of another application that is written by smart people (including, 
 sometimes us, in other products or companies), it raises our confidence that 
 we've done it correctly this time.  When several allegedly-smart products 
 each gets a completely different answer, it makes me very nervous about 
 assuming that we are somehow the one group to get it right.

Oh I know that one...

 I notice the definition for Lanczos3 for instance is not my expected
 windowing function which is something more like:

 sinc(position) * sinc(position / size)

 where size = 3 for a 3 lobed window.

 Um... I think we're correct, and Jeremy says we match several other smart 
 apps now...

 Glancing at the code myself, I clearly see our lanczos3 implementation 
 returning

        a/(pi*x)^2 * sin(pi*x)*sin(pi*x/a)
        = sinc(x) * sinc(x/3)    (for normalized sinc, a=3)

having looked at this, I guess I should have looked at expanding the
formula... I agree it is the same... I've just never had to expand the
sync() functions for either accuracy or speed, when re-sampling an
image I just cache the filter results, although that won't work for
arbitrary transforms, it works well for typical resizing usage.

 Also i wondered what the 'phase' of the filters does the
 implementation sample at - does it always results in all pixels being
 filtered when exactly halving/doubling, or does the filter only
 effectively sample at 0.0 and thus return a single sample for half the
 outputs? (Once I have it compiled, I can obviously run it to find out,
 there appears to be a lot of +/- 0.5s in the code and I'm not as good
 as the compiler :-).

 Sorry, I'm not exactly sure I understand the question.


Jeremy's answer suggests that the implementation samples the filters
in the same way, Shake or Nuke would do. I ask because recently we
came across a production that was handing us both '4K' EXR  and '2K'
DPX files, unfortunately they used a tool that did not use the pi/4
offset to reproduce the 2K and so to reproduce the 2K DPX files from
the EXRs we had to factor that into our system. Visually, sampling on
the pi/4 offset looks much nicer, especially if the original was not
band limited correctly in the first place (in this exact halving
situation you can end up with alternate pixels being 'impulse'
filtered).

Anyway, I finally beat cmake into submission and built the code
pointing to our preferred libraries, I'll move onto testing it and
then OpenColorIO

Thanks

Kevin
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

[Oiio-dev] iprocess unable to resize OpenEXR Half types?

[Kevin Wheatley]

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
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] iprocess unable to resize OpenEXR Half types?

[Kevin Wheatley]

Larry,

well I was trying to use as close to a stable release as possible, oh
and we don't use git, so I didn't want to track some development
stream in a tool I'm not familiar with, but if you can recommend a
revision to work from then I'm ok with trying it.

In particular if the core IO parts are stable but the tools are less
so, that is something I can OK for the rest of the team to work from,
as they are interested in file IO mostly. We're also interested in
working with OpenColorIO, if that impacts anything at all.

Thanks,

Kevin

On Tue, Sep 6, 2011 at 5:45 PM, Larry Gritz l...@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 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


 --
 Larry Gritz
 l...@larrygritz.com


 ___
 Oiio-dev mailing list
 Oiio-dev@lists.openimageio.org
 http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] Color space conversions

[Kevin Wheatley]

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 names for things, different 
 standards, I guess that is what you mean?

I'll have to say that colour spares like hsv/hsi/etc don't really have much 
grounding in how we see images, nor how we think of colour so the best they do 
is encode an arbitrary alternative set of data channels, that algorithms have 
been designed to work in. They can have poor properties such as none smooth and 
even none continuos functions making them less useful for image contexts.

As is often the case 'better' results can be had from a more thorough 'correct' 
implementation but at the cost of some computation/complexity. There are colour 
science based encodings that can express colour in colourfulness and intensity 
terms, but they rely on knowing the original encoding more completely e.g. 
Rec709/sRGB, in order to transform correctly.

Kevin
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] Histogram calculation

[Kevin Wheatley]

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 some way of windowing into a larger histogram if possible. 

We certainly don't consider 256 enough.

Kevin

Sent on the move...

On 4 Jul 2012, at 05:37, Larry Gritz l...@larrygritz.com wrote:

 I don't think you should have variable width.  The only width that is easy to 
 do is when it's exactly equal to the number of bins you requested for the 
 histogram.  Support that only, is fine with me.
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] Poll -- C++ compilers

[Kevin Wheatley]

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 time :-) As a standalone OCIO can use whatever it wants.

Kevin


On Wed, Aug 28, 2013 at 7:51 AM, Sebastian Elsner sebast...@risefx.comwrote:

 Am 28.08.2013 02:40, schrieb Larry Gritz:
  I won't hold you to this. And I'm not planning any immediate changes.
  But thinking about where we are going with toolchain dependencies, coding
 standards, and how conservative we need to be about newer C++ features...
 
  Think ahead to where you or your facility will likely be in, say,
 January 2014.
 
  * What C++ compiler and version do you think will be the oldest (i.e.,
 least C++11-compliant) you'll need OIIO to support?

 On Windows you are free to use every compiler version since you have to
 compile all libraries yourself anyway. But this is only for open source
 apps.  I am thinking more in a way of host applications I do not have
 control over. For example OIIO is used by MtoA, MtoA must run in Maya,
 and Maya is VS 2010. Nuke uses 2010, too. So we need to stick to those
 compiler versions, because of big incompatibilities. On Linux Maya uses
 4.1.3, which is pretty old I guess. The standard Python 2.6/2.7 again,
 that  comes with the official installer is VS 2008 (as is Houdini for
 example). Since we will be stuck with Py 2.6 for a while (I guess, since
 there seems to be no urge in any software package to move to 3) 2008 is
 the lowest for windows. I guess to use all the super new feature of
 C++11 VS 2012 would be needed since older versions are not very
 compliant...
  Right now we are on Windows only, but that will change. We will be
 going with a stock CentOS 6.x. So its 4.4 there?
  * What Boost version do you think will be the oldest you'll need OIIO to
 support?

 Don't care.

 
  * Can you think of any other dependencies (OpenEXR, etc.) that you are
 likely to need support for any versions MORE THAN TWO YEARS OLD, i.e.,
 dating from 2011 or earlier?
 AFAIK None.

 
  If you aren't comfortable answering on the mail list, a private email to
 me is fine, and I will summarize results later.
 
  For simplicity, you need not reply if you are already using this year's
 tools: GCC = 4.8, MSVC = 11 (VS 2012), Clang = 3.3.
 
 
  --
  Larry Gritz
  l...@larrygritz.com
 
 
  ___
  Oiio-dev mailing list
  Oiio-dev@lists.openimageio.org
  http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

 ___
 Oiio-dev mailing list
 Oiio-dev@lists.openimageio.org
 http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] Loading .CR2 raw image in right colorSpace (get rid of blue channel predominance)

[Kevin Wheatley]

​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
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] Loading .CR2 raw image in right colorSpace (get rid of blue channel predominance)

[Kevin Wheatley]

I just noticed my command line isn't quite right... (in case anybody
blindly tries what I wrote)

you have to use -c and a redirection to a file to get a fully
specifiable file name for the output file

dcraw -4 -o0 -T -c /path/to/cr2  /path/to/output.tif

or you can just run it

dcraw -4 -o0 -T  /path/to/file.cr2

and it will create a new file in the same path with the tif extension

When running it it will perform no colour scaling and should leave the
colour in the same colour space as the RAW file, so it is likely you
will not get nice pictures, visually the saturation and hue will
probably look odd because camera raw spaces are not display ones.

You can specify an alternative colour space via the -o option

Kevin

On Mon, May 4, 2015 at 10:36 AM, Jerome Esnault
esnault.jer...@gmail.com wrote:
 Hello,

 I tested the dcraw conversion and it gave me a darker result (whatever the
 colorSpace destination), so I assumed this is intrinsic to the camera sensor
 parameters and/or the picture was took within these conditions.
 If you want to test it, feel free to try my program from there :
 https://github.com/ejerome/CheckImgLinearity
 Thanks again,
 Best,
 Jeorme



 2015-04-28 11: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 /path/to/cr2 /path/to/output.tiff
 Kevin
 ___
 Oiio-dev mailing list
 Oiio-dev@lists.openimageio.org
 http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org




 ___
 Oiio-dev mailing list
 Oiio-dev@lists.openimageio.org
 http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] [Oiio-announce] OpenImageIO 1.6.9

[Kevin Wheatley]

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 info. That way you have your cake and eat it,
under normal usage you only load the main executable, but if you
attach gdb or similar debugger it will use the debuglink reference to
find the debug symbols. I've got cases where the shared object is like
20K and the separate debug info is 160K, but also cases where is only
shaves of 25% of the combined size depending on situation.

Kevin

In the following case it assumes the debug symbols live alongside the
binary (shared object in this case), thus

foo.so
foo.so.debuginfo

Something like the following (Make syntax)

DEBUGINFOEXT = .debuginfo
CXXFLAGS = -g

%.o: %.cpp
$(CXX) $(CXXFLAGS) -c -o $@ $<

%.so: %.o
$(CXX) $(LDFLAGS) -shared -o $@ $< $(LDLIBS)
objcopy --only-keep-debug $@ $@${DEBUGINFOEXT}
strip --strip-debug --strip-unneeded $@
objcopy --add-gnu-debuglink=$@${DEBUGINFOEXT} $@
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] OpenEXR 2.0 tiled read speeds

[Kevin Wheatley]

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 x86 port for OpenEXR had to convert this, whereas the SGI versions 
> didn't, and we're stuck with it now?

There are certainly some case where even the non xdr paths are potentially 
slower than needed, sometimes it calls stdlib memory routines, other time it is 
implemented as a basic loop.
> 
> On top of that, in the multi-threading scenario, while using a LUT for 
> half->float conversion is faster than not using it, it causes absolute havoc 
> in terms of L1/L2 cache thrashing - from disk I've sometimes found reading 
> full float EXRs faster than half EXRs due to this, but that's probably only 
> when the OS disk cache has them, so in general it's not a huge issue given 
> the IO saving that'll happen in most real-world usage for big facilities...

It would be nice if the copypixels and similar calls supported cpu specific 
implementations and there was an f16c implementation for the half conversions, 
once I patched the avx detection code in configure for gcc4.1, I got the big 
win mentioned in the dwa white paper, at lest in Nuke the conversion function 
inside the DWA parts of the library totally dropped to the bottom of the 
profiler hot spots and the performance jumped.

Karl, would that explain some of your differences with compiler versions?

I did think about rewriting the code myself but my assembler experience is 
somewhere around 80386 time frame (or ARM2/3, PDP8) so I put that near the 
bottom of my pile

Kevin
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] Any Nuke authors out there?

[Kevin Wheatley]

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 to be interpreted as a density, else it is an aspect ratio...

Which I could see as  2:1 meaning make a wide image... But when set as a 
density it means the opposite no?

Kevin

___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] Any Nuke authors out there?

[Kevin Wheatley]

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 it makes you feel any better, the Nuke notation is based on film 
> terminology where the anamorphic value refers to the projector lens stretch, 
> not the camera lens squeeze.  i.e. 2.0 means x2 in display width.
> 
> Typically anamorphic is not referred to as 0.5...
> 
> -j
> 
> On May 19, 2016, at 1:34 PM, Larry Gritz  wrote:
> 
> No, but it doesn't agree after all!
> 
> When I instruct oiiotool to write an OpenEXR with pixel aspect of 2.0, Nuke 
> correctly displays it as wide.
> 
> Same with TIFF.
> 
> But when oiiotool writes a JPEG with pixel aspect of 2.0 -- I *THINK* I'm 
> doing it right, there is no JPEG aspect field, in infers it from the x and y 
> densities (pixels per inch), so I set ydensity = aspect*xdensity -- then Nuke 
> displays it as as skinny rather than wide.
> 
> Apparently, PhotoShop, rv, and ffmpeg all agree with Nuke.
> 
> So it must be me who is wrong here! But for the life of me, I can't figure 
> out from the JFIF spec why the Nuke/rv/ffmpeg/PS interpretation makes sense.
> 
> Either the problem is entirely in my head -- I'm just interpreting the JFIF 
> spec incorrectly -- or else a long time ago somebody got it backwards, and 
> now everybody else is just trying to be compatible despite not agreeing with 
> the spec.
> 
> 
>> On May 19, 2016, at 1:17 PM, Jonathan Egstad  wrote:
>> 
>> (typing on a small iphone atm so I'll check out the thread in more detail 
>> later)
>> 
>> You're correct about what Nuke's format.pixel_aspect() is - it's the 
>> correction factor from pixel-storage to real-world coordinates.
>> So a Nuke format with pa 2.0 is typically an anamorphic image where the 
>> stored pixels are half their real-world width and require stretching out 
>> horizontally when viewed.
>> 
>> As for the jpeg reader/writer I wrote a pa 2.0 checkerboard jpeg out of Nuke 
>> and it displays correctly in ffmpeg's ffplay viewer - i.e. not squished.
>> For reference DWA's internal viewing tool ignores the density vars and 
>> displays a squished image.
>> 
>> So I think you're interpretation is correct in OIIO, and Nuke, RV & ffmpeg 
>> agree with it.
>> 
>> -j
>> 
>> On May 19, 2016, at 10:43 AM, Larry Gritz  wrote:
>> 
>> Hi, Jonathan, thanks!
>> 
>> If you could quickly read over the discussion in this PR: 
>> https://github.com/OpenImageIO/oiio/pull/1412
>> 
>> (It's not overly long or technical, but it might make you scratch your head 
>> a bit.)
>> 
>> The question is: Do you know anything about what Nuke is up to in the cited 
>> JPEG code? Do you believe Nuke is computing the aspect ratio for JPEG files 
>> backwards (versus the JFIF spec), or do you think that my interpretation of 
>> JFIF's fields are incorrect?
>> 
>> If Nuke is wrong, does that mean that we'd better do it wrong, too, or be 
>> forever doomed to have the aspect ratio being mangled when Nuke reads our 
>> files or vice versa? Or is there another solution you can think of that 
>> doesn't involve our having to introduce a bug? (I don't imagine that the 
>> Foundry will deem it practical to suddenly change Nuke's interpretation at 
>> this stage, even if it's technically wrong.)
>> 
>> 
>>> On May 19, 2016, at 10:02 AM, Jonathan Egstad  wrote:
>>> 
>>> Hey Larry,
>>> I'm one of the original Nuke authors but not with the Foundry - if you need 
>>> help with general plugin coding questions maybe I can help.
>>> 
>>> Cheers,
>>> -j
>>> 
>>> On May 18, 2016, at 10:18 AM, Larry Gritz  wrote:
>>> 
>>> Anybody from the Foundry who works on Nuke reading this?
>> 
>> --
>> Larry Gritz
>> l...@larrygritz.com
>> 
>> 
>> ___
>> Oiio-dev mailing list
>> Oiio-dev@lists.openimageio.org
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> 
>> ___
>> Oiio-dev mailing list
>> Oiio-dev@lists.openimageio.org
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> 
> --
> Larry Gritz
> l...@larrygritz.com
> 
> 
> ___
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> 
> ___
> Oiio-dev mailing list
> Oiio-dev@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] F16C (was Re: OIIO storage and performance)

[Kevin Wheatley]

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
f16c on older compilers, the frame buffer conversion routines are also
about 20-30% at least in the Nuke reader so I agree would probably
also benefit

> The condition ends up happening at a very high level, in staticInitialize(),
> which sets some function pointers based on the current cpu capability.

that is effectively how most of the dynamic dispatch is done in most libraries.

Kevin
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] libRaw/dcraw 'auto_bright' changing raw image exposure

[Kevin Wheatley]

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;
RawProcessor.imgdata.params.adjust_maximum_thr = 0.0;

// Some parameters effect open() and unpack()
RawProcessor.imgdata.params.use_camera_matrix = 
RawProcessor.imgdata.params.use_camera_wb = 

and some more parts... but those are the important colour ones, other
than intercepting the raw colour space buffer and calculating the
matrix multiplication ourselves in float to avoid clipping due to
white balance/etc.

Kevin
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] oiiotool --quality for dwaa exr ignored

[Kevin Wheatley]

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
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] Reading partial EXRs

[Kevin Wheatley]

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.

As a practical note, the first time I did this it was because it allowed files 
being actively rendered to be used before the 3D render was finished due to a 
last minute change requested by a client!

A case where coding and testing being faster than the render as I started after 
the render :-) would not suggest this as a normal working practice - ignoring 
return codes is usually a bad thing, so the codes were conditionally ignored 
based on a Boolean knob.

Kevin


___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] Normalize values

[Kevin Wheatley]

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 initialise your 'min' to the value provided by
numeric_limits::max() and your 'max' value to
numeric_limits::lowest(), or you could initialise both of them to the
value of the first pixel.

kevin

On Thu, Nov 28, 2019 at 3:06 AM Larry Gritz  wrote:
>
> I'm still concerned about your initialization of the "min" variable. Can you 
> see how this will give the incorrect result if the minimum pixel value in 
> your image is > 0 ?
>
> As written below, this will scale up the lightest values to fully "white", 
> but it will fail to convert the darkest values to fully black.
>
>
>
> On Nov 27, 2019, at 6:14 PM, Chris Dawlud  wrote:
>
> Thank you. It makes a lot of sense.
> I completely forgot about discarding alpha channel. Also, I'm using half 
> format so in my specific case I should have used half instead of float in the 
> iterator constructor.
>
> For future reference, here's the working code:
>
> void ImageLoader::normalize(OIIO::ImageBuf* image)
> {
> using namespace OIIO;
>
> auto stats = ImageBufAlgo::computePixelStats(*image);
>
> auto min = 0.0f;
> auto max = 0.0f;
>
> auto nc = std::min(3, image->nchannels());
>
> for (auto c=0; c < nc; ++c) {
> min = std::min(min, stats.min[c]);
> max = std::max(max, stats.max[c]);
> }
>
> auto roi = image->roi();
> roi.chend = nc;
> ImageBufAlgo::contrast_remap(*image, *image, min, max, 0.0f, 1.0f, 1.0, 0.5f, 
> roi);
> }
>
>
>
>
> ‐‐‐ Original Message ‐‐‐
> On Thursday, 28 November 2019 02:32, Larry Gritz  wrote:
>
> To clarify: I believe that the contrast_remap function is new in OIIO 2.1. On 
> older versions, or merely if you prefer it, I think you could achieve the 
> same thing with
>
> ImageBufAlgo::sub(*image, *image, min, roi);
> ImageBufAlgo::mul(*image, *image, (max-min), roi);
>
> Note also that this whole business of passing the roi explicitly is to limit 
> the pixel alterations to just the first 3 channels. You almost surely don't 
> want to scale the alpha values or any additional channels.
>
>
> On Nov 27, 2019, at 5:27 PM, Larry Gritz  wrote:
>
> In what way doesn't it work properly? Does it crash? Appear to do nothing? Do 
> something but not what you expect? What kind of image are you trying (I mean, 
> what data type and channels)?
>
> I can only speak in generalities without this info, but here's what I spotted 
> as likely problems.
>
> * ConstIterator/Iterator is likely to be problematic, because it 
> requires the buffer itself to be float. (Is it?) Usually we write a function 
> like your normalize as a template and then have a big switch statement that 
> selects a specialized variety based on the data type. (This may not really be 
> a problem if all of your images are stored as 'float' buffers internally.)
>
> * You initialized 'min' (why are these half?) to 0.0, which means that "if 
> (it[c] < min)" will probably never be true (unless you have negative values), 
> so it probably is not going to compute the correct minimum. A better way to 
> compute min/max would be:
>
> float min = 1e6f;
> float max = -1e6f;
> ...
> for (int c = 0; c < nchannels; ++c) {
> min = std::min(max, it[c]);
> max = std::max(max, it[c]);
> }
>
> * Depending on your image, you may also find that scaling all channels based 
> on the biggest min/max may be wrong, particularly if it has any non-color 
> chanels like alpha or Z.
>
>
> So OIIO 2.1 (a release candidate now, scheduled to be the official supported 
> release in 3 days!) has a function that does everything you want. Assuming 
> you're able to use that, here's how I recommend doing this operation robustly 
> (this is off the top of my head, I have not tested, so take with a grain of 
> salt, but this is the basic idea):
>
> ImageBufAlgo::PixelStats stats = ImageBufAlgo::computePixelStats(*image);
> float min = 1e6f;
> float max = -1e6f;
> int nc = std::min (3, image->nchannels());  // only consider R,G,B
> for (int c = 0; c < nc; ++c) {
> min = std::min(max, stats.min[c]);
> max = std::max(max, stats.max[c]);
> }
> ROI roi = image->roi();
> roi.chend = 3;  // only rescale at most the first three channels!
> ImageBufAlgo::contrast_remap(*image, *image, min, max, 0.0f, 1.0f, 1.0, 
> 0.5, roi);
>
>
> Using IBA::computePixelStats and contrast_remap has two big advantages over 
> writing the loops yourself: (1) it handles every data type that OIIO 
> supports, not just float; and (2) will go much faster because internally it's 
> multithreaded!
>
>
>
> On Nov 27, 2019, at 4:31 PM, Chris Dawlud  wrote:
>
> Hi,
>
> I want to normalize exr to make even very bright/dark images visible.
> The idea is simple but I can't