Change Details

//Note, this is a summary of the discussion with @sergey on IRC after it was requested that pillow be included with Blender. While I don't intend to work on this near term, I'm happy to help someone else take on this task - @campbellbarton .// --- (NOTE) Update: A very basic image API has been committed to master & 2.8 branch rB409cfba1a3cdec228c7f93aa8c1fbc912a6d6525, this was done so we can more easily accept incremental improvements. There are cases where it's useful to manipulate image data in Python, outside of Blender's image data-blocks (which are user data that's saved to file). The Python module [[ https://python-pillow.org | 'pillow' ]] is a capable module, however we would prefer to expose Blender's internal image operations, instead of bundling pillow with Blender. Reasons include: - 100% compatibility with Blender's file formats, so all files that load in Blender load through Python (including details like compression methods, meta-data and particular color-management settings). - Bundling pillow adds more burden for platform maintainers, also increases download size. - Image support can be buggy (security CVE's, bugs in one image loader not in another). - Using Blender's image support means any improvements here will benefit Blender too. - Potential for better integration with the rest of Blender //(so passing images from Python can be used in Blender as-is)//. We could initially support a basic API: - load/save - rotate/scale/crop - simple color operations (brightness contrast) - direct pixel access using Python buffers. Once basic support is working well we might consider: - more advanced effects (perhaps de-duplicate with the sequencer effects/modifiers). - color management access & conversion. - text drawing (using the `blf` API, which already works in C, use for text in the sequencer). - blitting content between images. ... others cold be added, these are just suggestions. Note that additions to this API would mean some refactoring & improvements to `ImBuf` since the Python API would be a thin wrapper on `ImBuf` operations.

//Note, this is a summary of the discussion with @sergey on IRC after it was requested that pillow be included with Blender. While I don't intend to work on this near term, I'm happy to help someone else take on this task - @campbellbarton .// --- (NOTE) Update: A very basic image API has been committed to master & 2.8 branch rB409cfba1a3cdec228c7f93aa8c1fbc912a6d6525, this was done so we can more easily accept incremental improvements. There are cases where it's useful to manipulate image data in Python, outside of Blender's image data-blocks (which are user data that's saved to file). The Python module [[ https://python-pillow.org | 'pillow' ]] is a capable module, however we would prefer to expose Blender's internal image operations, instead of bundling pillow with Blender. Reasons include: - 100% compatibility with Blender's file formats, so all files that load in Blender load through Python (including details like compression methods, meta-data and particular color-management settings). - Bundling pillow adds more burden for platform maintainers, also increases download size. - Image support can be buggy (security CVE's, bugs in one image loader not in another). - Using Blender's image support means any improvements here will benefit Blender too. - Potential for better integration with the rest of Blender //(so passing images from Python can be used in Blender as-is)//. We could initially support a basic API: - ~~load/save~~ (done) - rotate/scale/crop - simple color operations (brightness contrast) - direct pixel access using Python buffers. Once basic support is working well we might consider: - more advanced effects (perhaps de-duplicate with the sequencer effects/modifiers). - color management access & conversion. - text drawing (using the `blf` API, which already works in C, use for text in the sequencer). - blitting content between images. ... others cold be added, these are just suggestions. Note that additions to this API would mean some refactoring & improvements to `ImBuf` since the Python API would be a thin wrapper on `ImBuf` operations.

//Note, this is a summary of the discussion with @sergey on IRC after it was requested that pillow be included with Blender. While I don't intend to work on this near term, I'm happy to help someone else take on this task - @campbellbarton .// --- (NOTE) Update: A very basic image API has been committed to master & 2.8 branch rB409cfba1a3cdec228c7f93aa8c1fbc912a6d6525, this was done so we can more easily accept incremental improvements. There are cases where it's useful to manipulate image data in Python, outside of Blender's image data-blocks (which are user data that's saved to file). The Python module [[ https://python-pillow.org | 'pillow' ]] is a capable module, however we would prefer to expose Blender's internal image operations, instead of bundling pillow with Blender. Reasons include: - 100% compatibility with Blender's file formats, so all files that load in Blender load through Python (including details like compression methods, meta-data and particular color-management settings). - Bundling pillow adds more burden for platform maintainers, also increases download size. - Image support can be buggy (security CVE's, bugs in one image loader not in another). - Using Blender's image support means any improvements here will benefit Blender too. - Potential for better integration with the rest of Blender //(so passing images from Python can be used in Blender as-is)//. We could initially support a basic API: - - ~~load/savee~~ (done) - rotate/scale/crop - simple color operations (brightness contrast) - direct pixel access using Python buffers. Once basic support is working well we might consider: - more advanced effects (perhaps de-duplicate with the sequencer effects/modifiers). - color management access & conversion. - text drawing (using the `blf` API, which already works in C, use for text in the sequencer). - blitting content between images. ... others cold be added, these are just suggestions. Note that additions to this API would mean some refactoring & improvements to `ImBuf` since the Python API would be a thin wrapper on `ImBuf` operations.