Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Modify ImageInput/ImageOutput APIs to directly support IOProxy #2434

Merged
merged 1 commit into from
Jan 7, 2020

Conversation

lgritz
Copy link
Collaborator

@lgritz lgritz commented Dec 20, 2019

Make it a first class thing the API knows about, not the very weird back
door of passing via configuration hint.

For the sake of backward compatibility, the "old" method of passing
config attribute "oiio:ioproxy" with a PTR data will continue to be
supported for at least a couple major releases. But moving forward
for 2.2+ (which, remember, won't be a supported release for many
months), the preferred and documented way will be through these new
API calls.

It is still the case that only some format readers/writers support
IOProxies -- it is not only lots of work to extend support to more
formats (volunteers?) but since we rely on 3rd party libraries for
some of our important formats, if they don't have support for some way
to supply custom low level I/O function overrides, it would be very
hard to have a way for OIIO client applications to use proxies for
those formats. So callers should always check supports("ioproxy") on
the format before relying on it.

Make it a first class thing the API knows about, not the very weird back
door of passing via configuration hint.

For the sake of backward compatibility, the "old" method of passing
config attribute "oiio:ioproxy" with a PTR data will continue to be
supported for at least a couple major releases.  But moving forward
for 2.2+ (which, remember, won't be a supported release for many
months), the preferred and documented way will be through these new
API calls.

It is still the case that only some format readers/writers support
IOProxies -- it is not only lots of work to extend support to more
formats (volunteers?) but since we rely on 3rd party libraries for
some of our important formats, if they don't have support for some way
to supply custom low level I/O function overrides, it would be very
hard to have a way for OIIO client applications to use proxies for
those formats.  So callers should always check supports("ioproxy") on
the format before relying on it.
@lgritz lgritz merged commit 4bcce0f into AcademySoftwareFoundation:master Jan 7, 2020
@lgritz lgritz deleted the lg-ioproxy branch January 7, 2020 00:17
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

1 participant