During the last period a lot of new guys&girls entered Gimp-chat arena.
So far no one of those did any attempt on using Gimp-G'MIC plug-in and posting results and comments.
Frightened? Not interested? Difficult installation?
This plug-in is so rich....

Maybe later

spes ultima dea...

G'MIC is so beautiful and huge. I first got it from Source Forge and was able to install it easily. I mentioned it in a group chat and got some thanks from others and helped them to install the program. Nobody had a problem with the installation, but then I also found out G'MIC was included in a new GIMP release.

Having used G'MIC a lot now, I realized that I retained only a little about past processes. Many common things I care to do I can generally find, though much comes from experimentation. I began to document filters and parametric observations as applied, but two days ago decided to get existing documentation. That hunt also gave me a link to GIMPCHAT, and here I am.

I suppose what feature would be nice for G'MIC would be to alias saved operations under title with desc, but it is more then awesome now.

Here are some of my fantasy style construction textures processed with G'MIC.

Dinasset
You lost me here.
What do you mean?

@pirate541
Meaning, I believe, that as people join GimpChat, they seem oblivious/unaware/uninterested/already overwhelmed and do not post anything to the G'MIC discussion. Could be he's right; I don't spend much time counting hatching chickens here and what they start pecking at.
Could be there are many like Lissa Fields out there, for whom Gimp-G'MIC Just Worked out of the Box and haven't had much reason to post either questions or problems.
Also, dinasset's concern, could be that newcomers can't be arsed about G'MIC. I don't have an Occam's Razor sharp enough to eliminate contending theories.

@Lissa Fields

Curiously, some form of that aliasing process is actually very intrinsic to G'MIC, in that any sequence of commands may be labeled as a new command. Those of us who routinely use the command line form of G'MIC, which underlies the Gimp-G'MIC filters, commonly redefine frequently used command sequences, making such a sequence of operations a command in its own right. From that juncture, it is fairly straightforward to define a user interface for that new command and turn it into a Gimp-G'MIC filter. Then others may use the new command through Gimp without getting involved in the scripting part.
This is a common evolutionary pathway that those who are adept with the command line tool follow. Turn a oft-used sequence of commands into a single command. Then wrap that single command up as a Gimp-G'MIC filter so that non-scripters can share. Repeat as often as one likes.
Becoming adept at the command line tool is not a course that very many follow, however. G'MIC is a terse language. That terseness is a profound convenience once one has mastered the language because so much can be accomplished with very small scripts (not much actual writing), but at the outset, the language's terseness make it hard for a newcomer to read and understand the code.
Since any sequence of commands can be turned into a new command, it is conceivable that you can take two or three Gimp-GMIC filters that you commonly use in a well-known combination and combine these - "aliasing" them - as a new single Gimp-G'MIC filter. Unfortunately, it is not as simple as dragging-and-dropping existing filters into a 'filter definition pocket', but it is straightforward. You need to identify the commands behind the existing filters you use frequently, then wrap those in a new Gimp-G'MIC filter definition, your 'alias' filter. To someone who has never used the command line before, this process sketch would be full of uncertainty, but once one becomes capable of reading G'MIC script, at least a little, and has had practice using the command line tool, the way to combine Gimp-G'MIC filters into new, "alias filters" is not hard to follow.

Just my $2 worth (inflation don't you know),

Many of the technical threads I've been reading are written at a very high level — wonderful for understanding the guts of the tools etc., but likely difficult for many without extensive backgrounds in the relevant areas…

I'm a SMET grad (many moons ago) and spent most of my career in academia (including a fair amount of programming), nonetheless the level of math and code references has me regularly straining my memory and reaching for references just to follow (probably ) the discussion.

This is not a complaint, some of what I've (more or less) understood is fascinating, but — with limited time — the likelyhood of being able to make inntellectual contribution seems small… (And no one would want to make an inquiry along the lines of asking why the circumference and diameter of a circle are directly related.)

Hopefully, all you wonderful people who actually code these toys will keep doing what your doing & realize you efforts are appreciated even when only vaguely understood

I use Gmic to be sure, but I don't really know enough to discuss it other than to ask how to achieve a particular result, and that is usually in the gimp help area.

Lissa,
I'm still learning textures. Would like to be able to make a lot but there seems to be much work involved to make them seamless. I have followed tuts for gimp seamless but it doesn't work on every pattern.




I am with you 2-ton, I don't even know a real lot about gimp yet, only to do a few things, let alone the mathematics side of G'MIC

last posts on this topic brings me back to my first comment to David related to G'MIC documentation:
- it's made by mathematicians for mathematicians (or high-level fans)
(and that's true -sorry- also for the excellent details made by Garry on his posts)

there is a big lack of explanations on its use written in a language easy to understand by everyone who knows and uses software like Gimp

it's a pity...

dinasset, honestly, I think there is no ways someone with no or very few experience in
1. Image processing (I mean "the algorithmic of image processing").
2. Computer programming languages (especially script language).
can hope mastering all the G'MIC commands and concepts.

G'MIC is the result of more than 15 years of experience in these two domains, and it implements a lot of high-level stuffs (no brag, I swear!).
I know many people sees it just as a few-Mb filter box for GIMP. But it's really more complex than this. It is actually a complete framework for image processing.
Indeed, it provides quite simple interfaces to use its features (the GIMP plug-in, and even the command line tool are affordable), but writing image processing scripts to solve particular problems is something that requires another level of knowledge. I think all the necessary documentation is here, Garry Osgood does a tremendous work in writing his tutorials, and what he is doing is already more than just a description of using G'MIC. His tutorials cover some advanced image processing concepts.

The learning curve for writing G'MIC is steep, very steep particularly if you don't have the necessary theoretical bases in image processing. I'm afraid more documentation on G'MIC won't change anything for such users.

David,
more or less I was expecting such a reaction from you:

- you have done all the efforts on inventing and creating G'MIC
- more or less G'MIC has been -and maybe still remains- a one-man-job
- G'MIC is a tremendously outstanding image processing system
- you are continuously enhancing G'MIC with always excellent additions
hence, critics like mine are at least disturbing, if not more

but please consider:
- if I make critics it's because I love G'MIC
- I would like to be more capable to understand it better and use it better
- and I would like to see more people entering into this treasure island

please consider also that:
- I worked for a big company in the area of software development for 30 years
- I know what it does mean project, design, implement, discuss, test software and present it to the users
- as much as possible I tried to let each user understand how to use my software
this only to explain to you that I don't like to enter critics for critics (per se)

I am only hoping that someone else -not you- could take in his hands the challenge to let the user understand G'MIC, assuming only the same knowledge required to understand Gimp.
Garry writes excellent pieces of documentation, but he also remains in your "style".

I'm not willing to be right, maybe a counter-check could be to ask:
- how many of the Gimp users (and maybe also scripters) consider G'MIC easy to understand and use as Gimp?

As a final statement: I sincerely admire you and appreciate a lot your work, be sure!

Hello dinasset,
I accept critics, I don't think they are disturbing at all.
It is often a good way to make people think in a different way, so please go on


I've noticed that you appreciate G'MIC, I've read all your posts and questions with interest, please trust me (even if I don't answer all the time).
It's very interesting to see what your thinking process is and how you try to apprehend this software. I appreciate all the efforts you've put in it.

Thanks dinasset. But, there is obviously something about what we don't agree together :
I'm maybe a bit pessimistic, but I think that G'MIC is definitely not easy to master, even if more documentation is available.
For me, it's not a matter of having more documentation.
I'm probably the more experienced in G'MIC programming (let suppose that at least ), and even for me, there are some really tricky stuffs to find when I want to do a particular piece of G'MIC script. Sometimes, I need to think a lot of time (let says one hour) in order to be able to do something that I could do in few minutes in C++. This means the thinking process to have to code some G'MIC stuffs (that could be considered as quite simple sometimes) can be very hard.
This is the case for instance, if you want to perform very specific local operations on image pixels, and sometimes you need to deal with the integrated G'MIC math parser or even harder, you need to do it through the use of 3d vector objects. In short, this is not always natural to do.

What surprises me is, that at the end, I often find an acceptable solution (i.e. concise) written as a G'MIC code.
And day after day, this trains my mind to adapt itself to the best way coding stuffs in G'MIC. But this is definitely not easy. This requires time and experience.
I don't think this is the kind of things you can get instantaneously by reading some documentation.
So, I'm probably a bit less enthusiastic than you for this project


Dinasset, I didn't say you were not experienced. I was just talking for the general case of G'MIC users.
I don't think the average G'MIC user has enough scientific background to be able to write complex G'MIC script.
I do think they can however enjoy using the different provided interfaces (plug-in, CLI tool, Gmicol, ..)



That's the other thing I don't agree with. I find that what Garry does is exceptionally clear and easy to read compared to what I write in my reference documentation. Really, to me Garry's tutorial are very educational, and I don't think someone can do something easier to read.



The G'MIC plug-in is easy to understand, isn't it ? Maybe one cannot understand precisely what each filter does, but for someone with a little background on image processing, I guess this becomes trivial. The G'MIC language is not easy to apprehend for the average user, and it probably never will be.
This is something I accept and I don't think more detailed doc can help.


Thanks Dinasset, please don't do it This is just a personal and professional hobby I've been able to express as pieces of code. Fortunately, my employer allowed me to do that. And please, let me know what you think about that

Cheers,

David.

I've been using Gimp with G'Mic for a long time now, but will never fully understand what exactly is going on. However, I do know what I see and this plays a big part of how I use G'Mic. Seeing the results that other G'Mic users have achieved, also helps me to understand what some of the filters are capable of.
With out an example of what a filter can potentially produce, I'm left with trial and error when it comes to choosing a G'Mic filter for use it my work.

@dinasset
Thank you for raising this issue, to wit:

1. "Before one can use 'X', one needs to comprehend 'X';
2. before one can comprehend 'X', someone needs to communicate about 'X' in a comprehending way."

I don't think I have to convince you of the paramount importance of the second point, for certainly no one will use 'X' if they cannot understand what 'X' is for, and no will understand what 'X' is for if someone doesn't undertake the effort to communicate the premise, purpose, and operational aspects of 'X.'

And I think I'm not mistaken that you started this thread in a sincere, and even loving frame of mind, observing that since there seems to be quite a low level of discussion in the G'MIC Discussion area in relation to Gimp Chat at large, that perhaps few people are using G'MIC, because few can comprehend what G'MIC is for, because the aggregate body of information available about G'MIC is at such a high technical level it is really beyond common understanding, consequently it is not commonly used, and concomittantly engenders few comments, questions or discussion.

I think you might ask -- indeed, I believe you are asking -- is it possible to write a body of G'MIC documentation that can be understood by a 'common' person.

I do not wish this characterization of a 'common' person to be taken in a perjorative way. We all would like to be highly skilled in everything, but almost all of us, in one lifetime at least, have only so many hours in the day and as a practical matter, have become pretty skilled at one or two matters, and are vastly underskilled in most areas required by modern society. Nobody trusts me to do eye surgery, for example, but I am glad that there are eye surgeons around. In the vast majority of technical areas, I too am a 'common' person. I suppose so are you and would find no shame in such an appellation.

So I'll stop here, for now. I do have further thoughts in this matter, but choose to wait, because you might warn me that I'm off the mark or are not worrying about the problem that you are worrying about. However, if you do think that I understand the issue you raise, post a reply. As someone who makes a living at writing - and technical writing - comprehension is a topic I am always keenly interested in.

Take care,
Garry

Garry,
I think you got perfectly my point, when you write:
I think you might ask -- indeed, I believe you are asking -- is it possible to write a body of G'MIC documentation that can be understood by a 'common' person
That's it.
Difficult?
Absolutely, yes.
Needed to spread G'MIC use?
Again (IMO) absolutely, yes.
I know, David has a different opinion.
How to do it?
I don't know, but one thing I could recommend to the documentation writers:
- change the starting viewpoint, it should be the user goal
- from that, detail the technicalities of the filter(s) to use
Just as an example (very generic):
Main title: how to enhance a photo which is evidently noisy
First section should only explain what is meant by a noisy image, describe the possible different kinds of noise (this will introduce the user's mind to the subsequent description of the various parameters of the G'MIC filter(s)), show some example ....
Second section: the G'MIC filters available to perform this task.
First an introduction to the different techniques used.
Then for each filter detail the options and how they affect the result, per se, and in combination ...

now me too I stop here...not to be tedious

thanks for sharing your point, Garry

I've lately been applying Gmic filters on photos and I love the transformations one can get on them. At least it's very interesting for me, but it's only a starting in a huge world of possibilities.
Lissa, nice textures.

Dinasset, I never said I don't want G'MIC to become more spread (and optionally popular)! I just believe that mastering G'MIC requires mandatory knowledge on algorithmic image processing and programming, which are two general fields covered by other software than G'MIC.
So to me, a sufficient G'MIC documentation should not particularly focus on these external fields, because all the information can already be found by typing the right keywords on Google for instance. What I like in the Garry's documentation is that it covers more than the G'MIC syntax, he also explains the basic image processing theory behind. But really, I consider this is a fantastic work, and this is probably too much for G'MIC.
I don't think we can have a better and simpler documentation for people who wants to master G'MIC features.

David,
sorry, you didn't understand my wording.
you reported these sentences:
Difficult?
Absolutely, yes.
Needed to spread G'MIC use?
Again (IMO) absolutely, yes.
I know, David has a different opinion.
The subject of both question marks is implicitely (from previous sentences):
- a documentation written so that it can be understood by "common" people
Hence the following two questions are :
- is that difficult? yes!
- is that needed to spread G'MIC? IMO yes!
and I added: David has a different opinion, and that's what you always said:
- a better documentation (more understandable in common language) will not help
our two ideas on that are each other opposite (i.e. contrary)
Sure you want G'MIC more diffused! nobody can negate it, not certainly me.
What I said is that for you a better documentation does not help!
IMO, it does!

Ok dinasset, finally we agree on what we don't agree with