After digging into a bit more, the dcraw flags that the current rawinput
libRaw calls correspond to are:

   - -o <gamut>
      - 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 flags

   - -W
      - Turn _off_ auto exposure
   - -w
      - Use the camera white balance

The code to make those API calls is copied below. I've tested this on an
OSX build from the current repo head and found it to have the intended
effect.

Kevin, Alex, (whoever else is a dcraw guru): Any suggestions on other flags
to use. Those are the flags I've used.

It would be nice to be able to configure more of the raw processing options
before an image is opened.

Hope that helps,
HP

Additions to rawinput.cpp starting at line 137
    // Turn off automatic exposure correction
    m_processor.imgdata.params.no_auto_bright = 1;

    // Turn on camera white balance
    m_processor.imgdata.params.use_camera_wb = 1;









On Mon, Sep 12, 2016 at 10:07 AM, Larry Gritz <l...@larrygritz.com> wrote:

> There are certainly some things we want a reader to do automatically
> before the data is passed through OIIO to the calling app -- uncompress,
> de-bayerization, making equal resolution for all color channels, converting
> to some kind of RGB-based color space, converting to one of the standard
> (whole-byte) data types, etc.
>
> But given those constraints, the general approach in OIIO is usually to
> get as close to raw data as possible. So if libraw is capable of giving us
> photometrically linear and relatively unprocessed data without losing
> precision, that's what we should be asking for and giving to the app. At
> least by default -- it's fine to have a "config" parameter that requests
> other functionality that libraw is capable of, such as the auto_bright or
> gamma correction. But I don't think that should be the default.
>
> Is Mark or anybody else from DNeg reading this? Would that be ok for you
> if we changed the default, and you would use the configuration options if
> you had been intentionally using auto-bright all along? Or are we
> overlooking something?
>
> It would probably be a good thing for somebody to read the libraw docs in
> detail, and make sure that we have ALL the defaults set sensibly, with
> 'config' overrides for any particularly interesting functionality that it
> can do upon reading.
>
>
> On Sep 10, 2016, at 7:45 AM, Haarm-Pieter Duiker <l...@duikerresearch.com>
> wrote:
>
> Hello,
>
> I've been running into an issue with the OIIO libRaw support and wanted to
> see if anyone else had run into the same problem and found a workaround.
>
> The issue
> Raw files read and developed by OIIO using libRaw are automatically
> brightened.
>
> The potential cause tl;dr
> The RawInput::open method doesn't set the 'no_auto_bright' flag
> https://github.com/OpenImageIO/oiio/blob/master/
> src/raw.imageio/rawinput.cpp#L130
> like dcraw does when using either the '-4' flag or the '-W' flag.
> https://github.com/LibRaw/LibRaw/blob/master/samples/dcraw_emu.cpp#L337
> https://www.cybercom.net/~dcoffin/dcraw/dcraw.c - line 9963 or 9965
>
> Context
> If you use dcraw, or libRaw's dcraw_emu, to convert raw images to Tiff,
> and you want to produce linear 16 bit data for your exposures, the '-4'
> flag is often used. That is a shorthand for the flags '-6 -W -g 1 1'. '-6'
> set up 16 bit data processing. '-g 1 1' sets the gammas to 1.0, 1.0. '-W'
> turns off dcraw's 'auto_bright' functionality. The last flag is especially
> important if you want to merge exposures or otherwise treat your data as a
> more exact measurement of the world.
>
> Suggestion
> Add the line:
>     m_processor.imgdata.params.no_auto_bright = 1;
> around line 137 of rawinput.cpp
> https://github.com/OpenImageIO/oiio/blob/master/
> src/raw.imageio/rawinput.cpp#L137
>
> Open question
> For general OIIO usage, is there a good reason to be able to turn
> 'auto_bright' on?
>
> Will be testing that out this weekend but figured I'd see if there was an
> alternate approach to solving this problem.
>
> Thanks in advance for your help,
> HP
>
>
>
>
> _______________________________________________
> 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

Reply via email to