Re: [Oiio-dev] Setting colorspace options when reading RAW files in oiiotool

Sorry, just for completeness, the C++ version: ImageSpec cfg; cfg.attribute ("raw:ColorSpace", "XYZ); ImageBuf buf ("myrawfile.cr2", 0 /*subimage*/, 0 /*miplevel*/, NULL /*imagecache*/, /*config*/); > On Sep 14, 2016, at 10:17 PM, Larry Gritz

Re: [Oiio-dev] Setting colorspace options when reading RAW files in oiiotool

OK, so it looks like you should be able to get the data in XYZ space if you do: oiiotool --iconfig raw:ColorSpace XYZ therawfile ... > On Sep 12, 2016, at 1:50 PM, Alex Fry wrote: > > Right now I'm just using oiiotool via the command line. But I'm fine going > down the

Re: [Oiio-dev] Adding chromaticies to EXR with oiiotool?

I already backported the chromaticities fix to RB-1.6, but I wasn't planning to create a tagged release for a couple weeks. But if you want to just use the current head of RB-1.6, that's fine. > On Sep 14, 2016, at 9:10 PM, Andrew Gartner wrote: > > Sorry busy day

Re: [Oiio-dev] Adding chromaticies to EXR with oiiotool?

Sorry busy day and took forever to get back to you on this.. Patching back the chromaticities behavior would be helpful in 1.6, but yea I don't want to pull anything from 1.7 because that sounds like a nasty merge for you (and me). I'm perfectly fine waiting till I can move to 1.7 for the extra

Re: [Oiio-dev] OIIO storage and performance

Depends on the overall organization of the logic, I guess. OpenEXR is an easier case because there's really only one place where you use the instruction: inside a function that converts a whole scanline or tile from half to float or vice versa. So a loop of a whole lot of conversions can be

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

How does this look? https://github.com/OpenImageIO/oiio/pull/1490 > On Sep 13, 2016, at 9:41 PM, Haarm-Pieter Duiker > wrote: > > It looks like that 'adjust_maximum_thr' should be set to 0.0 generally. The > comment

Re: [Oiio-dev] OIIO storage and performance

> But you MUST run that version of TextureSystem only on machines that > support those hardware instructions! > How feasible is it to do a runtime cpuid check and only take the f16c paths on supported cpus? Then you can have one binary to rule them all. Thats how we handle f16c (and avx) in

Re: [Oiio-dev] OIIO storage and performance

Ah, too bad. Yeah, we also don't rely on that quite yet. Well, if you have a newer machine somewhere that does support it (anything newer than the machine you cited is likely to have it), give it a try with and without to see if makes a difference. > On Sep 14, 2016, at 11:13 AM, Dan Kripac

Re: [Oiio-dev] OIIO storage and performance

Hey Larry, I've been compiling OIIO 1.7.3dev with USE_SIMD=sse4.2 but not the f16c. Doing cat /proc/cpuinfo on my (slightly old) machine shows these flags: fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx pdpe1gb

Re: [Oiio-dev] OIIO storage and performance

Note to self: 2x improvement is "acceptably but not outrageously faster." Must recalibrate reactions to Søren's compliments. > On Sep 14, 2016, at 3:02 AM, Søren Ragsdale wrote: > > > > On Mon, Sep 12, 2016 at 7:52 PM, Larry Gritz

Re: [Oiio-dev] OIIO storage and performance

On Mon, Sep 12, 2016 at 7:52 PM, Larry Gritz wrote: > Note also that this reveals that the "genuine PRMan texture" appears to be > saving uint16... I'm not sure if that means it really is converting to > uint16, or if it's faking it by storing half in a uint16 container

[Oiio-dev] Branching for OIIO 1.7 beta

OIIO is now branched, RB-1.7, and tagged as Release-1.7.5beta. If you have been using 1.6 releases exclusively, now is the time to ensure that you can build and use 1.7 before it is final. My goal is to tag an official release on 1 October (probably with a couple release candidates along the