I took a stab at this:  https://github.com/OpenImageIO/oiio/pull/1741 
<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 <l...@larrygritz.com> 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 <kennycarruth...@gmail.com 
>> <mailto:kennycarruth...@gmail.com>> 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 <l...@larrygritz.com 
>>> <mailto:l...@larrygritz.com>> 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 <kennycarruth...@gmail.com 
>>>> <mailto:kennycarruth...@gmail.com>> wrote:
>>>> 
>>>> Based on a forum post over on libraw.org <http://libraw.org/>, libraw is 
>>>> able to extract the header information from a RAW file without unpacking 
>>>> it: 
>>>> 
>>>> https://www.libraw.org/node/2302 <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 <mailto: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 <mailto:Oiio-dev@lists.openimageio.org>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> 
> --
> Larry Gritz
> l...@larrygritz.com <mailto: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

Reply via email to