Re: [Oiio-dev] Reading only Image Metadata

[Larry Gritz]

I took a stab at this:  https://github.com/OpenImageIO/oiio/pull/1741 


Works for me, but I'm concerned about potentially breaking something 
(especially with no longer calling adjust_sizes_info_only().  So if you depend 
on raw reading, please try this patch on my end and comment on the PR about 
whether it seems to work.

I won't merge for a few days, to give people a chance to thoroughly vet this.

-- lg



> On Aug 7, 2017, at 3:51 PM, Larry Gritz  wrote:
> 
> I feel confident in saying that there is NO ONE who would prefer that the 
> whole file be read inside open(). It would definitely be better to only read 
> metadata in open(), and read/decode the pixels only upon the first call to 
> one of the read_*() functions.
> 
> If you're not intending to do it and send in a patch, I will as soon as I get 
> a chance.
> 
>   -- lg
> 
> 
>> On Aug 7, 2017, at 10:01 AM, Kenny Carruthers > > wrote:
>> 
>> Larry,
>> 
>> Thanks for the follow-up. I guess any chances to the RawInput plugin could 
>> affect current users with regards to when they might expect the performance 
>> hit of opening a raw file. Right now, they would expect it on the call to 
>> open(), but if that was changed, the they’d have to expect it somewhere else 
>> within their pipeline. (Whether OIIO calls one of the read_{} methods…) 
>> 
>> I’m still exploring how best I might be able to use OIIO (and by extension 
>> libraw) into my app so any changes I’d be making right now would be very 
>> specific to my use-case and not beneficial to other OIIO users, 
>> unfortunately.
>> 
>> I must say though, that efforts currently put into OIIO are fantastic. The 
>> PDF documentation rivals a commercial app, so a big thank you to those 
>> involved in all of it. 
>> 
>> Kenny
>> 
>>> On Aug 7, 2017, at 11:12 PM, Larry Gritz >> > wrote:
>>> 
>>> 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 > 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  wrote:
> 
> Generally speaking, you can read JUST THE HEADER with the 

Re: [Oiio-dev] Reading only Image Metadata

[Larry Gritz]

I feel confident in saying that there is NO ONE who would prefer that the whole 
file be read inside open(). It would definitely be better to only read metadata 
in open(), and read/decode the pixels only upon the first call to one of the 
read_*() functions.

If you're not intending to do it and send in a patch, I will as soon as I get a 
chance.

-- lg


> On Aug 7, 2017, at 10:01 AM, Kenny Carruthers  
> wrote:
> 
> Larry,
> 
> Thanks for the follow-up. I guess any chances to the RawInput plugin could 
> affect current users with regards to when they might expect the performance 
> hit of opening a raw file. Right now, they would expect it on the call to 
> open(), but if that was changed, the they’d have to expect it somewhere else 
> within their pipeline. (Whether OIIO calls one of the read_{} methods…) 
> 
> I’m still exploring how best I might be able to use OIIO (and by extension 
> libraw) into my app so any changes I’d be making right now would be very 
> specific to my use-case and not beneficial to other OIIO users, unfortunately.
> 
> I must say though, that efforts currently put into OIIO are fantastic. The 
> PDF documentation rivals a commercial app, so a big thank you to those 
> involved in all of it. 
> 
> Kenny
> 
>> On Aug 7, 2017, at 11:12 PM, Larry Gritz  wrote:
>> 
>> 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  
>>> 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  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.
 

Re: [Oiio-dev] Reading only Image Metadata

[Kenny Carruthers]

Larry,

Thanks for the follow-up. I guess any chances to the RawInput plugin could 
affect current users with regards to when they might expect the performance hit 
of opening a raw file. Right now, they would expect it on the call to open(), 
but if that was changed, the they’d have to expect it somewhere else within 
their pipeline. (Whether OIIO calls one of the read_{} methods…) 

I’m still exploring how best I might be able to use OIIO (and by extension 
libraw) into my app so any changes I’d be making right now would be very 
specific to my use-case and not beneficial to other OIIO users, unfortunately.

I must say though, that efforts currently put into OIIO are fantastic. The PDF 
documentation rivals a commercial app, so a big thank you to those involved in 
all of it. 

Kenny

> On Aug 7, 2017, at 11:12 PM, Larry Gritz  wrote:
> 
> 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  
>> 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  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 

Re: [Oiio-dev] Reading only Image Metadata

[Larry Gritz]

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  
> 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  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  
>>> 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 
>>> 

Re: [Oiio-dev] Reading only Image Metadata

[Kenny Carruthers]

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  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  
>> 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  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 
>>>  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 

Re: [Oiio-dev] Reading only Image Metadata

[Larry Gritz]

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  
> 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  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 
>>  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

Re: [Oiio-dev] Reading only Image Metadata

[Kenny Carruthers]

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  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 
>  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

Re: [Oiio-dev] Reading only Image Metadata

[Larry Gritz]

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  
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

[Oiio-dev] Reading only Image Metadata

[Kenny Carruthers]

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