Once the image data is stored as a variable in Scilab, it is possible to do all kind of things with it…e.g.: add transparency as an 4th channel.
Over the years I worked (and appreachiated) with various image processing toolboxes (IPD, SIVP, SIP, scicv, IPCV), so this post is meant to be an excursion in terms of “back to the roots”.
Thank you for this initiative. Can you improve your contribution by creating a standalone function, e.g. with protoype function mat=readbmp(path) and a documentation page (using the xml style of Scilab help pages) ? Then it would be possible to create a merge request in order to add your contribution in Scilab
It’s been a while since I was working on a Scilab toolbox, providing also help pages. Let me have a look, it may take a while, but: Yes, I can do that.
I was also thinking: If it is possible to use core Scilab functions to read a bitmap file, it should also be possible to use a similar approach for writing a bitmap
Following your suggestion it should be possible to do a function retVal = writebmp(path, mat) with retVal beeing a return value if the bitmap was successfully created or or not.
In case you are interested I also write pure scilab code for reading and writing TIFF file image (very basic cases of the specifications). I can share the code with you if you want.
Maybe your question can be placed in a seperate topic linking to this topic?
Absolutely I do not have any problem using the available toolboxes and my aim is not to replace them in any way. To me the whole thing is based on interest.
I do use IPCV and scicv a lot … although I sometimes run in issues like: imread() is defined in both toolboxes.
I just recognized some things:
Toolboxes have to be rebuild for every Scilab major release.
Hello philipp
In case you are interested I also write pure scilab code for reading and writing TIFF file image (very basic cases of the specifications). I can share the code with you if you want.
This need (updating packages when the main software updates) is common to almost any software. Before 2023.0.0 version the release frequency was lower, which explains why users did not realize that the need of rebuilding packages (particularly for those using C/C++ gateways) was already there. For almost each major release we had ABI changes, which implied to recompile toolboxes with compiled gateways, and also other API changes or removals (after years of deprecations) of Scilab features.
Having an automatic recompilation of toolboxes would need to redesign the whole atoms stuff or to replace it with a toolchain like the one used in rolling distributions like conda.
I completely agree that the actual system is not optimal, but maintining the Scilab toolboxes ecosystem is not 3DS priority, and many toolboxes which are still used are not maintained by their authors. For IPCV I made important simplifications in the build process which will allow to easily rebuild for each major Scilab release (for Windows, macOS and Linux).
In fact there is a limited number of toolboxes which are still used and maintained and if I had the rights on Atoms portal, I would make all legacy/unmaintained unavailable in the atoms gui.
This would allow to advertise the actually working and maintained packages.
I have no problem with toolbox when I can use them. I’m using IPCV a lot, but it’s is not reading my TIFF images that why I have develop a scilab function to open them. I’m not too concern with speed that is why I prefer pure scilab toolbox over toolbox with gateway.
I really appreciate the new developpement pace of scilab by 3DS, that’s why I tend to switch to new release immediatly, with toolbox compatibility problem following.
Some time ago I wrote a function that reads a BMP into a matrix, but I’m afraid that it allows, so far, up to 256-color maps. My motivation was to convert the graph of an empirical x-y relationship such as might appear in books or papers into numerical data. You can find it here:
Thank you @philipp I will have a more precise look at your files. To ease the process I have created a merge request so that we can work on the inclusion of these into Scilab:
In fact Scilab rather misses the whole image input/output subset of OpenCV particularly for image types handling transparency. But to me, setting the alpha channel of an image is done before. I think it is better to focus on the improvement of i/o and a function such as mat2rgba() should be part of IPCV or scicv.
Those that are too specific and are meant for dealing with some user’s particular problem, who then decides to contribute their work to the community just in case somebody finds it useful. Pobably they will not be maintained after the problem has been successfully solved, and probably very few people will really download it, preferring to develop their own solution. The learning curve of a toolbox often makes me choose the latter. Another potential problem is that the ATOMS library is quite liberal, so there is no guarantee that the offered solutions really work and are reasonably bug-free. Finally, often you can find several toolboxes that offer similar resources. Which is the best choice in those cases? Hard to know…
Those that solve a very frequent task, such as reading and writing an image file, or opening and saving a sound. If the type of file were a very seldom used one, particularly pertaining to applications which usually don’t involve numerical computations, I agree that it is better to include the tools in a toolbox. Otherwise it is preferable to include them in the main program.
I think that the whole model of toolboxes is a way that many commercial applications such as Matlab apply to be able to sell more things. You work with signal processing? Your basic application is then useless, buy the signal processing toolbox! You make research on artificial vision? Buy the artificial vision toolbox! I don’t believe Scilab needs this approach.
