Hey!
My image IO/manipulation library, Inumon, is now available on Nimble. I am aware that there are existing libraries that wrap libpng and libjpeg-turbo, and even implement basic image manipulation; but a combination of poor documentation, inelegant or unstable APIs, unresponsive developers, and lack of community have made me fall back to Python's PIL. So, that's why I've been working on making Inumon.
My short term goal is to implement (and document!) a good set of manipulation/CV features, and refine/stabilize the API. My hope is that Inumon could become a standard of sorts within Nim that helps the language be adopted by developers/projects/teams/businesses who need this kind of functionality. Of course, long term maintenance is also a primary goal.
So if you have any need for image IO/manipulation/CV functionality that falls outside of what existing libraries can do, I would greatly appreciate if you could work with me to implement them in Inumon. General contributions out of kindness are cool too! To be clear, this is not about wrapping existing C libraries (that's only needed for IO with libpng and libjpeg-turbo, which I've already done), but designing our own nimonic/nimsy/araqal library.
https://github.com/dizzyliam/inumon
I hope everyone is doing well despite this crazy year so far :)
but a combination of poor documentation, inelegant or unstable APIs, unresponsive developers
hey, im trying
Note that I have started some image manipulation low-level primitives and also benchmarks in Impulse https://github.com/SciNim/impulse
For example to apply an image filter I have benchmarked 5 low-level primitives here: https://github.com/SciNim/impulse/blob/26e25e70/benchmarks/image_filters/filter2d_separable.nim, and the same with parallel implementation via Weave here: https://github.com/SciNim/impulse/blob/26e25e70/benchmarks/image_filters/filter2d_separable_parallel.nim
Besides, I've also added a RGB to YUV420 / Y'CbCr conversion to Trace-of-Radiance here with BT601 color matrix support (Jpeg and BT.709 for HD video is straightforward) https://github.com/mratsim/trace-of-radiance/blob/99f7d85d/trace_of_radiance/io/color_conversions.nim
In general I don't mind adding pure Nim primitives, potentially parallelized and vectorized for high-level image libraries provided I know what you need ;) (though my ultimate goal is to have something like Halide in pure Nim https://halide-lang.org/ instead of 2 stages code-generation).
I.e. you can raise an issue on your need in Impulse https://github.com/SciNim/impulse.
I've also wrapped PocketFFT C++ which provides multidimensional parallel FFTs (complex and real), DCT and DST (Discret Cosine Transform and Discrete Sine Transform) here though still wondering about the high level API: https://github.com/SciNim/impulse/blob/26e25e70/impulse/fft/pocketfft.nim I tried to implement a FFT in one weekend™ but it's too complex for a weekend task. If you're interested in resurrecting that code, that commits has a skeleton and plenty of documentation to build your own high performance FFT: https://github.com/SciNim/impulse/tree/49b81323/impulse/fft
I do think there is quite an interest in image procesing in Nim so maybe a new channel on the Discord or a Gitter channel might have enough interest?
Currently I'm learning Nim and have some little projects in mind that involve image manipulation. For my needs it doesn't have to be anything advanced. There are already packages on Nimble for reading and writing JPEG and PNG files, conversion between different color spaces etc.
But it would be great to have something similar to Go's image package. That would provides a unified way of representing images of different formats, colors and procedures to manipulate them.
Hello.
@Voltist, thanks for this library in pure Nim to open Jpeg and PNJ file and made some simple manipulation. If your objective is to made a big lib there is a wrapper for OpenCV (https://github.com/dom96/nim-opencv) and for me it a better idea to make every effort required for improve compatibility.
OpenCV is very used in computer vision and machine learning, it's a reference in this field. OpenCV is already bind in Java, Python and Javascript, why not Nim.
Bindings are good until they are not.
Typically for my own tensor library I used bindings for optimized matrix multiplication but people have difficulties installing those dependencies on Linux.
Also for Nim, you could do a lot of precomputation at compile-time which you cannot do for bindings.
Many of the recent languages: Go and Java but even Python have their own pure image manipulation library.
And lastly, if you want to do image manipulation in production, sure use OpenCV, but a lot of Nim developers are here because they find the language fun and they don't have something to ship in 2 months but they have time and the willingness to learn both a language and an application domain.
It's a lot more fun (usually) and obviously better for learning to write something from scratch than to wrap something already ready.
@mratsim I agree with you but I'm a little frustate because I love Nim and in my job I use OpenCV. I would like use both in my free time :(
The binding is not the best choice especially if it is not official but it allows developpers of others languages to reuse his favorit library (when the binding works well). It is easier to use a language when you can use popular library or similar but that's another debate.
Nim is young, ecosystem grows up and welcome inumon.