oiiotool silently extracts thumbnail instead of raw image

[jedfrechette]

Problem

If oiio is built without libraw attempting to read a raw file will silently extract the embedded thumbnail instead of the raw data. This behavior was observed using oiiotool from a Windows build of 1.8.5 to read Canon .cr2 files.

You can tell that the thumbnail is being output because the resulting image is a different sized than it is when extracting the raw data using a libraw enabled build. Passing options such as use_camera_wb also do not affect the output as the white balance is baked in to the thumbnail.

Expected behavior:

Extracting the thumbnail could be useful, but is probably not the desired behavior in most cases. If OIIO can't read the raw data because libraw isn't present the user should be warned.

Actual behavior:

Currently, oiiotool provides no indication of what has happened, even if run with the -v or --debug options.

[lgritz]

Right, so just to clarify what's going on, it's important to know two things:

1. If libraw is not found at build time, the raw format reader plugin won't be built at all.

2. What OIIO does to open a file is (a) first, look to see if any of its supported formats seem to correspond to the extension, and try that first (e.g. the raw reader will be tried first for a .cr2 file if it's built, but if no raw reader is built, no plugin will say that it corresponds to that extension); (b) but if no plugin exists for that extension, OR if the plugin that appears to correspond nonetheless fails to open the file, then EVERY plugin is tried in succession, to see if any will open it (e.g. maybe it's got the wrong extension, or a nonstandard extension for that file); (c) only if no plugins will successfully open the file, then it's a total failure.

So what's happening is that you have no raw-reading plugin (because no libraw at built time), and when it goes though step (b) it turns out that the raw file is purposely structured to "look like" a TIFF or JPG or whatever, so that plugin is able to "successfully" open it (unaware that it's only the head of the file, containing the thumbnail, that looks like that other format).

I do understand how this can lead to confusing situations.

So I can think of a number of possible remedies. These are not mutually exclusive, I'm just throwing out a number of ideas for discussion:

• We could have an option (build time, or run time, or per "open" call?) that turns off the "try every plugin" behavior, so that if the extension is unrecognized, it gives up immediately.

• If libraw is not found, instead of not building a raw-reading plugin at all, we could build one that always fails.

• We could make oiiotool (always, or when in --debug or -v mode?) detect and report when the initial guess failed.

• We could make libraw a required dependency, so this case would never happen. (Perhaps with a non-default build option to disable raw support, if you know you don't need it or have libraw available.)

What behavior would be most helpful? I don't think that we want to completely jettison the "try all plugins if the best guess didn't work" strategy, since people do want OIIO to be fairly robust when encountering strangely or incorrectly named image files.

For clarification, is it oiiotool specifically that you are concerned about? Or is that just an example and it's your own app (that uses OIIO APIs) that is important to you?

[jedfrechette]

That makes sense. To answer your questions in reverse order.

I'm interested in both oiiotool and the API. In this specific instance I hit the behavior while prototyping functionality for an app using somebody else's build of oiiotool. I didn't realize it had been built without libraw and ended up spending a lot of time trying to figure out why everything seemed to be working but I wasn't getting the results I was expecting.

Arguably, by not failing-fast the 'try all plugins' system ended up being less robust in this case. That being said, I don't really have a strong opinion about whether or not it's a good idea generally. If it is desirable behavior for the other plugins my inclination is that raw probably shouldn't be a special case.

I do think oiiotool should detect and report when the initial guess failed (bullet 3). My vote would be to always report failures. I think that would be useful beyond this specific use case. If I'm getting files that are something other than what they're claiming to be then something has probably gone wrong somewhere else in the pipeline and I want to know about that sooner rather than later.

[lgritz]

OK, this gives me some ideas to try. Stay tuned.

[lgritz]

By the way, oiiotool --help should show you all the formats supported and libraries built against (at the bottom), if you're ever wondering if a pre-built OIIO has raw support or not.

[jedfrechette]

That's what eventually clued me in to the fact that libraw was missing. Originally though, I just thought I was getting the --iconfig syntax wrong since the parameters I was trying to pass to the raw decoder weren't having any effect.