Dev:Source/Image/Image Refactoring

This page describes a proposal to rewrite the entire image formats and internal image handling capabilities within Blender.

Note: This page is definately a work in progress page. I've added this page already because this could be discussed (informally) during the upcoming conference.

Goal 1 - Experiment with technologies for future restructure possibilities

The current image handling is quite stable in Blender - not much activity is going on in this area at the moment. It is already a pretty separated section in the source tree. The image formats are already nicely grouped together in source/blender/imbuf. It allows for nice experiments without touching too many files througout too many source trees.

Goal 2 - Changes must be applied to current source tree

The proposed changes involve a complete rewrite and even an architectural difference over the current implementation. A proposal has been (at least for Blender 3) to start over from scratch. The problem with such an approach would be that it takes too much time to get the new implementation reach the same level of stability and features as the current source base. It would be really nice if the rewrite could be done incremental - and in the current source tree. The proposed module would not fit within the current architecture, but it should be possible to somehow integrate the module. The advantage is that new development can go on as it currently does.

Goal 3 - Make it as extensible as possible

The current imbuf part has support for many file formats. Each of these formats could (optionally) be implemented as a seperate plugin. The foundation should be laid out such that it would be easy to add a new image format as a plugin without even needing to recompile Blender.

Goal 4 - Python all the way

The image module will have some functions that allow other part of Blender to communicate to the module. Each single function must be opened up to Python. The image module should also be compilable as a Python module. This would mean that the image module can be called directly from the Python prompt without starting Blender. Future extension could be to let the image module work together with the Python Image Library (PIL). It should be possible to write an image importer/exporter in Python and connect it directly to the image module.

Goal 5 - Use 1 API file

Currently there is an API for C and a seperate one for Python. Since goal 4 is about specifying one common API it would be really helpful for all developers if the API calls to the image module would be written in a generic file format from which the .h files for C, C++ and Python can be generated. I don't propose to specify a new format here. I would propose to use something that's already on the market - think (a simplified version of) IDL for example. Generating API documentation should be done from that generic file as well and the documentation would be a combined C, C++ and Python API description - no duplicate work with regards to API docs here.

Goal 6 - Add support for Verse

Loading and saving images is one of the things blender currently is capable of and should remain to do so. Using Verse to import/export images should be added as well. Much has been said about this in the past - I'm not going into much detail here.

TODO: add image how this could be represented visually.

Goal 7 - Design for the future

Although I don't know what the future will bring, we should make the image module as flexible as possible for future requirements. Things to think of is adding 16 bit channel support.

TODO: add image to show how this could be represented in UML.

Goal 8 - Fast compilation

Now this isn't a functional requirement. One of the things heard quite often is that it would be nice to only compile the part you're working on. The build system(s) will need to be expanded to support this. The developer should be able to specify how he wants to build blender: - The image module should be compilable as a module. As long as the interface is not changing, only a recompilation of the module should be enough to make use of the updates within the module. - It should be possible to include the module in the blender binary.

The module should specify which external libraries it depends on. For the image module examples would be the jpeg lib, tiff lib, png lib, etc... If a graphic lib is not available on a platform, it should be possible to disable support for such a format - but only through the image module. Any other part of Blender isn't supposed to know what kind of graphic formats are supported.

-- MichelSelten - 19 Oct 2004

---

Python Image Module

I have been working on improving this module substantially. This wiki page is where I have opened my discussion on it. Basically, stable pixel I/O ops need to be written for this module before even attempting to support the PIL. I noticed while going through the code that the imbuf class is quaint and antique. Half of the variables in it have question marks after them, which is not a good sign.

Code Refactoring

In refactoring the code for the internal image handling it should all be written in C++, so as to add support for future advancements. Ture Object Oriented code will allow for much expanded capability as well as usability. Another aspect that should be considered is the ability to add support for future advancements. Here's one proposal:

• Make standard typedefs for all the different types in the image classes
• Use an XML format for users to easily "describe" an image format and load it into Blender
• Allow users a preview before opening an image
• Add more image editing capabilities within the program
• Allow users to define their own image methods with Python

Those are just a few of my ideas.

-- AustinBenesh - 02 May 2005

---

Error Handling

The current image editing capabilities in Blender have limited (if any) way of handling exceptions. One thing that should be implemented in the refactored code is a good debug system. This will help the user know the exact problem _and_ let the developer know where they went wrong. Here's one way to implement this:

• EVERY method returns a char - if no exception it returns ""
• The main process is an error handling process so that exceptions can be caught early on in the game
• Provide a way for the user to deal with an error without recompilation

-- AustinBenesh - 06 May 2005