Roadmap
After 0.2.x (requiring API brakage)
- Influence selection of best variant in weighting best colors versus best size.
- Influence selection of best variant by defining a prefered aspect ratio (such as landscape versus portrait).
Before 1.0
- Have a stable API.
- Have reasonable ways to deal all possible combinations of features that an image format can provide (that affects viewing the image).
- Have support for stereoscopic 3D.
- Have support for images stored in multiple files.
Development comments
The main focus of the develpment is currently get all the details of the API right. This involves being able to handle all odd corner cases without being too awkward to use. And ideally as simple as possible to use for the common cases. This is IMHO the most important thing to get right from the start since it's the most difficult thing to fix later on.
This involves investigating image formats with odd combinations of features and figure out a sane way to handle them in a generic way. There is already support for features not found in many (if any) other graphics loaders, including:
- Both animation and variants (Windows Animated Cursor)
- Both animation and layers (Aseprite format)
- Both pages and animation (WAD)
- Animated vector graphics (Lottie)
There are a lot of oddities out there. Such as pictures with separately animated parts. Just doing the animation and let it run might not be very complicated. Cut calculating then it loops (as in all parts reach the end at the same time) and translating it into discrete frames (in order to migrate them to a widely supported format such as WEBP) might not be as easy. Some formats may be composed of layers in different resolution. Again, not very difficult to scale all layers to the desired size in order to show them. But what should be considered the actual size? Is it then all layers are scaled up by integers to align? That will probably work fine for most real world examples, but in theory all layers could have different resolutions based on large primes, so not very good for a genereic policy. Strange examples such as these ones keep coming up. And even if abydos can not support every strangeness in the universe, at least I want to know about it and maybe choose to not support it.
After that I plan to add support for stereoscopic 3D pictures. This should include handling multiscopic images in a generic way. I have only begun researching this. And (unsuprisingly) it's not as simple as getting one left and one right image. First of all, they should obviously be swapped in the picture is rotated 180°. But it is also possible allow a more fine grained (but still discrete) rotation. For example by a set of cameras aranged in a circle. But other configurations are also possible.
It's no secret that abydos depends heavily on cairo. And the idea is to closely follow the design decisions cairo follows. This means aiming towards being exactly as portable as cairo. Since cairo now supports a greater bit depth, abydos will too.
The API is going to be broken for every minor version up to version 1.0. After that the API will be stable (until an eventual 2.0 version).
There are experimentation going on to write plugins for abydos in rust. Since they only do some bitshuffling they don't need to drag in a lot of stuff and create multi megabyte binaries. They only become about four times bigger or so, which is reasonable. Currently it's not very feasable to rewrite plugins in rust since it's a bit of a moving target then it comes to interfacing with C. It becomes hackish and most of the benefits with rust gets lost then most of the memory management is done in the main C library anyway. What rust brings to the table is mainly adding implicit range checking code. Which could potentially be useful. There is however not a chance that abydos will be rewritten in rust, or cargo to be used as the main build system. Unless, of course, cairo takes that path.
