It looks like that 'adjust_maximum_thr' should be set to 0.0 generally. The
comment from the libRaw changelog is as follows:
"
* dcraw_emu's -c parameter now wants numeric (float) argument.
This value
is assigned to params.adjust_maximum_thr.
Use -c 0.0 for
I can certainly backport this exr fix to 1.6. I'm slightly more hesitant about
backporting the "--attrib" extensions for oiiotool, mostly because I don't
remember what they in turn depend on or what else was included in the same
patch.
But the high point is that we're on track to in the next
Ah... I can't quite remember when we extended the --attrib syntax to have the
extra bits to let you set oddball types, but it's possible that you're using an
OIIO that's just too old to support that, so it's still not getting the type
right with oiiotool.
I see now, looks like that was a 1.7
Sounds like a plan to me, shouldn't hold up a merge at all considering all
went well on the code side. Maybe I'm behind on the source tree but I
could've sworn I'm on 1.6 release.
Thanks for the fixes regardless, this is more than enough to get me moving.
I'll try to find some time to dig at what
Because this works for me and passes the CI tests, I'm going to speculatively
merge it. If it turns out that your difficulties are a bug and not something
weird with your setup, we can always patch it.
> On Sep 13, 2016, at 2:28 PM, Larry Gritz wrote:
>
> No match? Wha?
No match? Wha?
Which version of OIIO?
Just for fun, try enclosing the "-attrib:type=float[8]" 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 wrote:
>
> Sure thing, here's
Sure thing, here's what i get in my shell with this command. I'm guessing
it's an argument syntax issue to be honest. (sorry I can't include the
images for legal reasons).
oiiotool input.exr -attrib:type=float[8] chromaticities
"0.680,0.320,0.265,0.690,0.150,0.060,0.3127,0.3290" -o output.exr
Not finding a match? Can you clarify? (Like, with a command line and exactly
what the error says?)
You're right, OpenEXR says the name should be lowercase, I will fix that in the
patch.
> On Sep 13, 2016, at 1:28 PM, Andrew Gartner wrote:
>
> Hey Larry,
>
> Thanks
Yep, sorry, this was subtly broken for OpenEXR.
This patch should fix it: https://github.com/OpenImageIO/oiio/pull/1487
Let me know if you need that backported to a release branch.
> On Sep 13, 2016, at 11:49 AM, Larry Gritz wrote:
>
> I think the correct syntax is:
>
I think the correct syntax is:
oiiotool input.exr -attrib:type=float[8] chromaticities "0,1,0,0,0,0,0,0" -o
output.exr
But upon trying it, I see that it's not quite working. Hang on, let me poke
around a bit. OpenEXR may be particular about how the chromaticities are
declared.
> On Sep 13,
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
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;
I was able to use a custom ImageSpec with ImageInput's open method to set
the gamut. If you need to use any of the ImageBuf algorithms, you can
transfer pixel data to an ImageBuf. If not, you could just write the data
out.
Example code here:
After digging into a bit more, the dcraw flags that the current rawinput
libRaw calls correspond to are:
- -o
- Choose the output colorspace
- -6
- Set up 16 bit processing
- -g 1 1
- Set the gamma curves to 1, 1
I'd suggest we add API calls corresponding to two more
14 matches
Mail list logo