LoadEXR/SaveEXR from/to memory
xelatihy opened this issue · 7 comments
Describe the issue
While LoadEXR
and SaveEXR
are deprecated functionality, they are very useful is one wants to quickly put together applications. This is in the same vein as stb_image
. It would be helpful I think to have this functionality not deprecated and add a simple to use SaveEXR to memory option. In fact, it would be great to have even simpler functions that have an API that is the same as stbi_load
and stb_write
.
Expected behavior
Three things:
- Do not deprecate the simple-to-use interface
- Add Load/Save from/to memory
- Consider an even simpler interface that matches
stb
headers to make integration trivial.
@xelatihy Rather than extending existing legacy LoadEXR/SaveEXR
API, we can propose new simple API based on stb
interface, for example:
exr_load_from_file
exr_load_from_memory
,
exr_load_half_from_memory
(e.g. Load fp16 image as fp16 data)
exr_write_to_memory
,
exr_is_half
(check if images in .exr have all fp16)
...
And example code is something like:
int w, h, c;
if (exr_is_half(exrfile)) {
uint16_t *img = exr_load_half_from_file(exrfile, &w, &h, &c);
} else {
float *img = exr_load_from_file(exrfile, &w, &h, &c);
}
This proposal is actually might nicer! And we could deprecate the old ones.
I would love to have both the _from_file
and _from_memory
options.
Would be also great to have the stb
requested number of channels on load that is very helpful when putting together apps quickly.
You can propose API based on my draft idea and send PR. Contribution is always welcome.
Ok, I'll try to prepare a PR.
I took a look and it is that as simple. The easiest thing to do is to wrap into a coherent API what you have already implemented. But that would have some limitations in the API itself. I guess it may be better than nothing, but still not as nice as one would like.
I might take another look later as I get more time.