Consider using OpenImageIO for reading and writing images

[ttddee]

Hi there!

Very cool project! I am working on something similar.

Maybe it would be beneficial to replace PIL with OpenImageIO.

It has support for lots of formats, color space conversions and can work with 32 bit floating point images.

[Correct-Syntax]

Hi @ttddee,

Thank you for your suggestion!

I have looked into openimageio and it seems like it could be implemented into Gimel Studio. It would allow for higher-res images, etc which is a big advantage over Pillow.

Are there any pre-built binaries on PyPI? I couldn't find any.

Thanks again.

[ttddee]

I am not sure. What platform are you on?

Building on Linux is straight forward and on Windows you can get a semi-recent version through vcpkg.

[Correct-Syntax]

O.k. After a bit of looking I was able to find binaries here

Thanks again!

[ttddee]

Great!

Also if you want to check out what I have been doing, see here: https://github.com/ttddee/Cascade

Still very early stage though ;)

[Correct-Syntax]

Hi @ttddee,

After looking at OpenImageIO, I'm leaning towards going to https://github.com/libvips/libvips. Do you have any experience with libvips vs OpenimageIO? I'm not really sure how they differ. Obviously, you went with OpenImageIO I am guessing, but is there a specific reason why? Libvips seems to be faster based on the benchmarks. (?)

Hope you're having a great day!

[ttddee]

That seems like a viable option too. OpenImageIO is kind of the industry standard in Visual Effects and it integrates with OpenColorIO, so you get IO and color space management all in one.

I have no experience with libvips but it would give you a lot of image processing functionality out of the box by the looks of it. From having a quick look at it I couldn't see if it supports 32 bits per channel.

[Correct-Syntax]

From what I can see it does support 32 bit images, as well as openexr, etc. How is openimageio? Is it low-level or does it come with

a lot of image processing functionality out of the box

like you mentioned (and I can see) for libvips?

The only thing I dislike about libvips is the Python bindings are a bit harder to install than openimageio. Openimageio has pre-built wheels but libvips doesn't seem to have any.

[Metallicow]

Maybe it would be beneficial to replace PIL with OpenImageIO.

Actually, No it wouldn't be beneficial. PIL/Pillow has been around a long time and is probably the best supported image lib for python. A better request would be since this is plugin based is to port whichever nodes you have to whatever other library you are suggesting.
For example, there could be one of a zillion implementations for blur.
The optimal way to do this would for example have multiple bla blur nodes that do "the same things" but the naming scheme would just append (wxPy, PIL, OIIO, OpenCV, GMIC, ImageMagick, etc..., etc..)
At which point the manager(which is wipz atm) would allow the user to see which lib implementations that they want to play with and install for use.

[ttddee]

From what I can see it does support 32 bit images, as well as openexr, etc. How is openimageio? Is it low-level or does it come with

a lot of image processing functionality out of the box

You can see here what it does for processing: https://openimageio.readthedocs.io/en/release-2.2.8.0/imagebufalgo.html

It is mostly an IO library but covers the basics of processing.

There might be other options in Python-land that I don't know about. Maybe I should have worded this differently, I am only talking IO, you could use something else for processing.

[ttddee]

Maybe it would be beneficial to replace PIL with OpenImageIO.

Actually, No it wouldn't be beneficial. PIL/Pillow has been around a long time and is probably the best supported image lib for python. A better request would be since this is plugin based is to port whichever nodes you have to whatever other library you are suggesting.
For example, there could be one of a zillion implementations for blur.
The optimal way to do this would for example have multiple bla blur nodes that do "the same things" but the naming scheme would just append (wxPy, PIL, OIIO, OpenCV, GMIC, ImageMagick, etc..., etc..)
At which point the manager(which is wipz atm) would allow the user to see which lib implementations that they want to play with and install for use.

I wasn't talking about how to implement image effects, I was talking IO. Sorry if that was not clear.

OIIO/OCIO is just what everybody uses (including Blender) and it makes it easy to be "compatible" with other software packages. I think PIL lacks support for PSD, EXR, color spaces(ACES, lin, log, etc...)?

I might be wrong though, since I don't know PIL very well and I am sure other libraries are fine too.

[Metallicow]

I recall you can do stuff with it, but psd is a closed format so pil may not spend much time on it. I personally use psd-tools here on github when I'm doing psd conversion stuff in my program stuff. It does fine for me snaking the full thumb image for display. Other than that, ever since Krita finally got around to implementing the selections right/and bug fixing started with 4.2 I have since abandoned Photoshop pretty much completely for everything basically in favor of .kra open format. I might actually use old photoshop7 for like editing maybe 3 pictures a year with, and other than that I still use it for text layout as krita still has that not exactly polished. And personally I never really liked photoshops implementation the best either. Text is hard thing to wrangle.
As far as EXR, or other color files, you might look at the Pillow source/readthedocs or ask over there depending on what formats you need. I managed to bump up support to get some of the others in the community to finally work on supporting dds a while ago. And since that's basically a direct link to the gpu rendering with directx/opengl, that's the prefered format for rendering most times if you need a lot of em compressed and need speed also. But alas there are many other compressed texture archive types that deal with dds also so you may be hit or miss with anyone of them. One thing to note is that krita oftentimes can open a psd, that has been corupted that even photoshop can't anymore. which is a nice plus.

[Correct-Syntax]

Actually, No it wouldn't be beneficial. PIL/Pillow has been around a long time and is probably the best supported image lib for python.

True. I'd really like to stick to Pillow for those reasons (plus since it's well-known in the Python community, it would be easier for users to script custom nodes with than OpenImageIO or libvips, etc),

but...

Pillow doesn't have full support 16 or 32 bit images -only 8-bit is fully supported from what I could find. Plus, it would be nice to have EXR and color spaces support, etc too.

A better request would be since this is plugin based is to port whichever nodes you have to whatever other library you are suggesting.

This is a good idea. This is similar to an idea I was thinking about: possibly edit things a bit to where we can have different "renderers" (e.g: "pillow", "libvips", "openimageio", etc, etc...) and (like you said) different nodes specific for that "renderer". Or maybe, just try to "smooth-out" the differences between the image libs and do it that way (in that case some nodes would support 16-bit (for example) and others would not.

I think this is what you're saying here (which are great ideas, BTW):

For example, there could be one of a zillion implementations for blur.
The optimal way to do this would for example have multiple bla blur nodes that do "the same things" but the naming scheme would just append (wxPy, PIL, OIIO, OpenCV, GMIC, ImageMagick, etc..., etc..)
c would allow the user to see which lib implementations that they want to play with and install for use.

[Correct-Syntax]

@ttddee

I wasn't talking about how to implement image effects, I was talking IO. Sorry if that was not clear.

Yes, that was clear. I was just wondering if it could be used for processing as well. :)

I think PIL lacks support for PSD, EXR, color spaces(ACES, lin, log, etc...)?

Yes, I think you're right, sadly. :(

[Correct-Syntax]

I recall you can do stuff with it, but psd is a closed format so pil may not spend much time on it.

Yeah, I was able to get a working prototype of opening a PSD image with pillow. It doesn't seem to have the best support, but it works. I don't personal use Photoshop (and never have, past launching it and closing it....), so I don't see PSD support as a feature that needs to be implemented, but others might (?).

As far as EXR, or other color files, you might look at the Pillow source/readthedocs or ask over there depending on what formats you need. I managed to bump up support to get some of the others in the community to finally work on supporting dds a while ago. And since that's basically a direct link to the gpu rendering with directx/opengl, that's the prefered format for rendering most times if you need a lot of em compressed and need speed also. But alas there are many other compressed texture archive types that deal with dds also so you may be hit or miss with anyone of them.

Not sure about dds. Pillow doesn't seem to have full support for 16/32-bit images, etc. Correct me (Please) if I am wrong (which I really hope I am -on that)!

I agree -Krita has really come a long ways.

[Correct-Syntax]

Just to update, I've currently been testing and looking into:

• Using numpy arrays as the base (instead of Pillow Image), which enable us to still allow for Pillow support via conversion, etc. My plan would be to use OpenCV as IO, which has support for (at least) 16-bit and exr file support. If I needed to later, I could always implement OpenImageIO instead.
• Adding the option to write GLSL shaders for GPU processing via the Node Evaluation in the API. I already have a working example of the GLSL shader GPU image processing (via ModernGL) with numpy array compatibility -though some things still need to be worked out...especially figuring out how to integrate it into the API as-is.

The main reason I am not keen on implementing OpenImageIO right now, is I am not sure it would add that much (vs. OpenCV for IO), except another dependency.....

If anyone would like to join in helping with these two objectives, feel free to contact me and/or respond to this comment. :)

[Correct-Syntax]

UPDATE: We're now using OpenImageIO in the new development version at https://github.com/GimelStudio/GimelStudio. Thanks for suggesting this @ttddee as now nearly a year later I've figured out a way to implement it correctly. 😅

[ttddee]

Good to hear! I have been completely absorbed by another project but hope I can do some work on Cascade soon again. Maybe, after all, we will have our shared shader library at some point :)

[Correct-Syntax]

Yes, I still like that idea. ;)