There may have been a bad configuration or installation at some point.
It is possible to resume a complete installation.
In this case you must save the filters you have created as well as your filter settings.
Use the packet manager to uninstall G’MIC.
Delete in root mode all that remains of G’MIC CLI, QT, GIMP (files and directories) and which does not need to be saved.
Download the latest ‘Full’ version of G’MIC.
With me it’s ‘GMIC Ubuntu 22.04 Jammy: Full Package’ , then i install the package ‘GMIC_3.2.3_UBuntu22-04_jammy_amd64.deb’.
If the problem persists it will not be linked to G’MIC.
:o)
…bad news… anyway thanks 
@FAb7D
You may be able to create a new user and try.
@FAb7D , could you try this :
$ gmic debug input_cached gmic_denoise_cnn.gmz > log.txt
and copy/paste the content of the log.txt file?
It would help to understand what is wrong.
Thanks!
Of course
log.txt (64.8 KB)
Thanks!
I asked in the Solus forum if anyone has the same problem and it seems so.
https://discuss.getsol.us/d/9182-gmic-repair-denoise-dont-work
Thanks, and could you tell me in which folder the file gmic_denoise_cnn.gmz was located when you run the test?
In this moment there isn’t becouse I removed for this
but if I add on ~/.cache/gmic with:
~/.cache/gmic $ wget https://gmic.eu/gmic_denoise_cnn.gmz
the new
~ $ gmic debug input_cached gmic_denoise_cnn.gmz > log2.txt
become this:
log2.txt (64.9 KB)
(so in this case gmic_denoise_cnn.gmz is located on ~/.cache/gmic)
1 Like
and…I’m sorry… There is already a version prior to the changes made with SAMJ…
Is here
https://discuss.pixls.us/t/machine-learning-library-in-gmic/25746/54?u=fab7d
In subsequent posts there are also other tests… it doesn’t recognize this magic number, everything points to a problem in the package.
Ok, so we are going forward.
Now, the thing we have to make work is simply :
$ gmic gmic_denoise_cnn.gmz
where you run gmic in the folder where gmic_denoise_cnn.gmz is located.
Does this work for you (it should not).
Could you tell me what version of G’MIC you use ?
Also, what gives:
$ gmic it gmic_denoise_cnn.gmz unserialize
?
Here you are!
~/.cache/gmic $ ls gm*
gmic_denoise_cnn.gmz
~/.cache/gmic $ gmic gmic_denoise_cnn.gmz
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ Input file 'gmic_denoise_cnn.gmz' at position 0
[gmic]-0./ *** Error *** Command 'input': File 'gmic_denoise_cnn.gmz' is not in .gmz format (magic number not found).
~/.cache/gmic $ gmic it gmic_denoise_cnn.gmz unserialize
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ Input text-data file 'gmic_denoise_cnn.gmz'.
[gmic]-1./ Unserialize image [0].
[gmic]-1./ *** Error *** Command 'unserialize': gmicList<float>::unserialize(): Invalid specified size (0,0,0,0) for image #1 in serialized buffer.
[gmic] Command 'unserialize' has the following description:
unserialize (+):
Recreate lists of images from serialized image buffers, obtained with
command 'serialize'.
~/.cache/gmic $ gmic
gmic: GREYC's Magic for Image Computing: command-line interface
Version 3.0.2
...
OK, so I think I’ve found what happens.
You are using version 3.0.2 of G’MIC, and there was a name change for value type in the .gmz and .cimgz that has been introduced in G’MIC 3.1.0.
Excerpt from the changelog:
* *[core-310]* Names of pixel types have been normalized. Now, they can be `{ bool | uint8 | int8 | uint16 | int16 | uint32 | int32 | uint64 | int64 | float32 | float64 }`.
In particular, pixel type uint8 replaces old uchar, and float32 replaces old float.
These new names are used in the header of the file gmic_denoise_cnn.gmz because this file has been updated since 3.1.0, and while newer versions of G’MIC are able to read .gmz files with the older type names, the contrary is not true.
I’m then a bit sorry to say this, but you won’t be able to run command denoise_cnn with G’MIC 3.0.2.
Could it be a good occasion for the packagers of Solus to update G’MIC to the latest stable version 3.2.3 ?
2 Likes
Thank you very much!
I ask it right now!
Hello there.
A quick note, to give you some news about my long-term project to create a machine learning library inside G’MIC 
Over the past few weeks, I’ve been trying to get back into it seriously, and I have to say that I’ve made a lot of progress!
- First, I spent a lot of time debugging and completely recoding the convolution module for the neural networks (as well as the convolution itself in G’MIC), and I’m happy to announce today that I’m pretty sure this module works properly inside
nn_lib, including convolution withstride,dilationandshrink(before it was working well only with the basic settingsstride=dilation=1).
Convolution modules are particularly important and used in neural network architectures (esp. for image processing), so checking that I have something that works as the theory says was necessary.
-
I’ve also recoded a specific normalization module from scratch, that appears to work nicely, so that I can manage bigger networks than before (normalization modules help stabilizing the training process, so it’s almost mandatory to put some of these when designing deep neural networks).
-
Then, I’ve implemented and experimented with various Upscale layers : transposed convolution, pixel shuffle, resizing with various interpolations. Upscale layers are used for instance in auto-encoders and U-net architectures, i.e. networks that can generate image data. Using these upscale layers, I’ve been able to train a simple image upscaler (see my post here for more details Attempt for a x2 image upscaler, using CNN). I have a project to train a specific image upscaler for lineart images, with the help of David Revoy. I’ll tell you more when I got the data
-
I’ve also made the changes in the
nn_libso that the library can handle several networks at the same time. This will be useful in my next attempts : training GAN architectures for generating details in images (e.g. in the upscaler). -
So far, I’ve been successful in using the
nn_libto train classifiers (MNIST, MNIST-fashion, Face detection, Celeb-A attributes), up to 10M parameters (the biggest is a Resnet variant I’ve made for the Celeb-A dataset). I’ve also been able to train a simple auto-encoder and a small U-Net, so this means future possibilities for pretty cool filters in G’MIC (like better upscaler, automatic image colorization, neural style transfer, …). -
Next step is to be able to train a GAN to see if the lib can work flawlessly with two networks at the same time (generator / discriminator). But I’m pretty confident it will work one day or another
That’s all for today, but I wanted to share these advances with you. It’s now been 3 years since I started implementing this library, completely from scratch, and I’m starting to see some real and interesting possibilities for G’MIC users!
Having started from scratch, I must say I’ve learned a lot about the algorithms (and all the tricks) used for machine learning, so it’s not all wasted anyway
But if, on top of that, it results in filters that everyone can use, then that’ll be great!
I’ll tell you more when I get new results!
5 Likes
Some news about nn_lib: the machine learning library inside G’MIC, written from scratch, and which is constantly being rewritten! (I wonder if this project is perhaps a little too big for me! ).
Well, I’ve been able to make a lot of progress on it these days:
- Use of cumulative gradients. This allows different layers to be fed with the same input, and to cumulate backward gradients from the loss on these inputs. This allows greater flexibility and easier writing of certain network architectures (particularly those with residual blocks).
- This will also eas the mixing of multiple losses together.
- And of course, various bug corrections and optimizations. I don’t put all the stuff I do in the Changelog though.
As a result, yesterday I’ve been able to successfully train my first autoencoder successfully. Yipee! 
An autoencoder is a kind of networks that tries to “compress” an input image into a shorter code (named latent vector, that’s the role of the encoder), then “decompress” this latent vector into an output that is expected to be close to the input image (that’s the role of the decoder).
I’ve been able to train a small autoencoder (1M parameters, 38 modules total) on a dataset of aligned faces, with a latent vector of dimension 128 (which is quite small).
With such an architecture (and with the simple MSE loss I’ve used), we cannot expect a perfect reconstruction, but at least it reconstructs images that look like faces anyway
And the interesting thing is that you can linearly interpolate the latent vectors to create a kind of “automatic morphing” between faces (see video below and compare how the image structures evolve when using latent interpolation).
Yes, it looks a bit ugly, but clearly, this is a milestone for me, because I found that training an autoencoder is definitely harder than training a regular CNN classifier or an end-to-end CNN (as I did in my previous posts), in part because of the upscale modules that has to create new data and which make the training a bit more tricky.
As always, all these modifications on nn_lib has broken everything that were using it before, so I had to stop the automatic filter updates for version 3.5.0.
I’ll do some more testing and see if I can release version 3.5.1 of G’MIC soon.
Next step will be probably implement a VAE (Variational Auto-Encoder)
This is exciting because lot of cool neural networks have this autoencoder structure (U-Net being one example), and if I can train such network inside G’MIC, I’ll have the potential to make some funny filters (I’m thinking about automatic segmentation or B&W colorization in a distant future).
Thanks for your attention!
2 Likes
Very coils @David_Tschumperle and congrats on the milestone 
1 Like
Hello @David_Tschumperle,
Do you plan to take advantage of the GPUs or it will be “only” CPUs multi-threading code?
I am not an expert (very far from it) but I have read (???) that GPUs perfom extremely fast for this kind of tasks. Please, feel free to correct me…
G’MIC will always be CPU only. Besides, threadripper and other things like it will become a thing.
No, I don’t plan to use GPUs.
Using GPU in nn_lib would basically mean recode everything (e.g. in CImg), using CUDA (or whatever dedicated library associated to each GPU brand). Clearly a huge work and a waste of time considering that there are already several good ML libraries out there (that already know how to use GPUs). Also, I’m not particularly interested in the “hardware” part of GPUs, so I don’t find a personal interest of diving it into this myself.
Of course you are right: GPU is currently the way to go for a developer if he really wants to integrate ML in his piece of software.
But let be honest : Personally, I’ve started writing nnlib above all, as an attempt to learn a lot of stuffs about how ML works (because I do research in image processing in my everyday job, so having this “low-level” algorithmic knowledge can help!).
Actually my plans for G’MIC have never been to add fancy (and performant) ML stuffs in the software.
If my nn_lib leads to a few cool image filters in the future, then good!
But it’s more a personal project than a real desire to add ML features to the software.
Otherwide, the solution would have been to make G’MIC depends on an existing ML library.
I don’t think it would have been very interesting though.
And who knows? Maybe in a few years, CPUs will be as fast a GPUs right now for ML ?
1 Like
Hello @David_Tschumperle
Thanks for your reply!
Just out of curiosity…
As regards the G’MIC filters, which are able to take advantage of the multi-threading code, do you suggest Intel or AMD CPUs?
In short, did you ever made some tests to compares these 2 CPUs?
yeah, there are plenty of them to test but maybe just a few to meausure the different results in terms of the final speed…
Personally, I have always bought Intel CPUs together with Nvidia GPUs…
For instance, reading some posts about VKDT, by hanatos, it looks like it is a better choice (but again, I might be totally wrong…).