OIIO only guarantees that the file has been opened and the metadata read, upon
open(). Ideally, the pixel data would be read only as each read_scanline or
read_tile call is made, and only as much as that call needs. Less ideally, the
pixel data would be read in blocks or upon the first request for the pixels.
The pixel data is only read in open() itself if the underlying format library
has a single call to read the whole thing and we don't have a good way to read
the metadata separately.
So if there is a way to read just the metadata with libraw (as it appears, and
perhaps we overlooked when rawinput.cpp was written), then the correct solution
is to do that as part of open(), and then only the first time
read_{scanline,tile} is called should it call the function that reads and
decodes the image pixels.
Do you want to take a stab at this? Or should I?
-- lg
> On Aug 7, 2017, at 1:15 AM, Kenny Carruthers <kennycarruth...@gmail.com>
> wrote:
>
> Based on a forum post over on libraw.org, libraw is able to extract the
> header information from a RAW file without unpacking it:
>
> https://www.libraw.org/node/2302
>
> But in OIIO, what would be the correct way of telling RawInput::open() that
> unpack does not need to be called? Is there a way to pass in a flag of sorts
> when calling ImageInput::open() to indicate that only metadata is required?
>
> If I modified RawInput.cpp for my own use-case to not call unpack() and to
> only load the metadata, what expectations does OIIO have as to the state of
> the ImageInput and its ImageSpec after open() has been called? (And,
> subsequently, which other call would be the right place to actually start
> unpacking the RAW data?)
>
> Ultimately, for me, it might make more sense to just manually detect a RAW
> file and use LibRaw directly for extracting the header information rather
> than modifying OIIO, but I’m curious nonetheless because OIIO is looking
> really promising for my intended use case.
>
> Or… Another idea I had would be to create my own, custom plugin that only
> loads metadata data. Could I then use the ImageInput::create() technique and
> use some custom identifier like ‘META’ to load my plugin? That plugin would
> know to only load the metadata for whatever files it supports, which might be
> done by calling libraw’s methods or passing through to the JPEG or TIFF
> plugins… Such a technique might keep my code as close to OIIO APIs without
> having to modify existing plugins…
>
> Cheers,
> Kenny
>
>> On Aug 7, 2017, at 1:16 PM, Larry Gritz <l...@larrygritz.com> wrote:
>>
>> Generally speaking, you can read JUST THE HEADER with the following sequence:
>>
>> ImageInput *in = ImageInput::open(filename);
>> ImageSpec spec = in->spec();
>> // Note: NO read_scanline* or read_tile* calls here!
>> in->close ();
>> ImageInput::destroy (in);
>>
>> I would like to tell you that this will always work in a high-performance
>> way, but it depends on the format reader, which in some cases may be
>> dependent on a 3rd party library that doesn't really have any easy way to
>> read just the header without reading the whole file (libraw, I'm looking at
>> you!), in which case the whole thing may be read when you open(). In those
>> cases, you're mostly stuck, unless there is a header-only-read API call in
>> the dependent library that we didn't know about or neglected to use properly.
>>
>> It just so happens that NEF is a variant of TIFF (at least for the header
>> info), so you *can* force the TIFF reader to be used, like this:
>>
>> ImageInput *in = ImageInput::create ("tiff"); // note: use format name
>> rather than filename
>> ImageSpec spec;
>> in->open (filename, spec);
>> in->close ();
>> ImageInput::destroy (in);
>>
>> This is a trick that happens to work with NEF, but I think it only works for
>> reading the header, because the TIFF reader certainly doesn't know how to
>> de-bayerize the image data or perform any other transformations that libraw
>> is expected to do with true raw data. The header-only-reading trick might
>> work with other RAW formats that happen to use the TIFF header conventions,
>> but I don't know exactly which those are. You certainly shouldn't assume
>> it's the case for all RAW formats.
>>
>>
>>
>>> On Aug 6, 2017, at 12:59 PM, Kenny Carruthers <kennycarruth...@gmail.com>
>>> wrote:
>>>
>>> Larry,
>>>
>>> This is in C++ and using ImageInput.
>>>
>>> I did notice after sending my original email that in rawinput.cpp, the
>>> method read_tiff_metadata() shows how to create a new ImageInput of type
>>> ‘TIFF’ and then load data into that directly from a filename. That method
>>> completely bypasses all of the libraw code. Not sure how I overlooked that
>>> earlier.
>>>
>>> But that would appear to be working because of the (reasonably sound)
>>> assumption that most RAW files have a TIFF formatted header. Can this
>>> technique be extended to all image formats that contain embedded metadata?
>>>
>>> Thanks,
>>> Kenny
>>>
>>>> On Aug 7, 2017, at 2:54 AM, Larry Gritz <l...@larrygritz.com> wrote:
>>>>
>>>> Before I give a full answer...
>>>>
>>>> C++ or Python? Or command line?
>>>>
>>>> ImageInput or ImageBuf or ImageCache/TextureSystem?
>>>>
>>>>
>>>>
>>>> On August 6, 2017 11:34:12 AM PDT, Kenny Carruthers
>>>> <kennycarruth...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I’m using OpenImage IO and extracting the metadata from an image using the
>>>> extra_attribs() method on ImageSpec. Is there a way to tell OpenImage IO
>>>> that I’m only going to be accessing the metadata and that no image loading
>>>> or decoding needs to occur?
>>>>
>>>> In particular, the RawInput class, which uses libraw, calls unpack() which
>>>> is a very slow method because of the RAW decoding that needs to take
>>>> place. However, that call to unpack() is being made at the start of the
>>>> ImageInput::open() method and there doesn’t appear to be any flag one can
>>>> set to disable that. Further down that method, it calls through to
>>>> read_tiff_metadata() which is really all that one needs if they are only
>>>> interested in the metadata.
>>>>
>>>> If I disable libraw support in OpenImageIO, then OIIO defaults to opening
>>>> a Nikon NEF file with another plugin that only loads the metadata since it
>>>> can’t load the raw data. That code path is very fast but I don’t know how
>>>> to trigger it if raw support is built-in (or how to tell the raw plugin
>>>> itself).
>>>>
>>>> Thank you.
>>>>
>>>> Kenny Carruthers
>>>> macOS Developer
>>>> Corduroy Code Inc,
>>>>
>>>>
>>>> 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
>>
>> --
>> 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
