Thank you dinasset. In light of that, then, two diagrams, done somewhat tongue-in-cheek, but also true, I think.

The reason why I think these diagrams, for all their humor, touch upon a truth stems from what happens in peoples' minds when I write the glyphs 'G'MIC.' What happens, I assert, are the emergence of some thoughts about a rather large Gimp plug-in that houses -- what? -- four hundred filters (and more) which do an amazing array of things, and if-only-I-can-understand-half of it. There is nothing 'wrong' about this. It is a matter-of-fact reality that 95%+ who inhabit Gimp Chat have a world view of G'MIC that distinctly looks like the diagram on the bottom.

How can it be otherwise? People fire up Gimp mainly to fix photographs or do digital illustrations. Necessarily that makes Gimp the big circle going off to infinity. Now and again, they stumble over (or are told of) this immense plug-in called G'MIC, and, lo-and-behold, it is immense - but some of the filters are incomprehensible. What the hell is this 'Bandpass' thing in 'Spectral Filters?' It's got Low Frequency and High Frequency, but I twist the knobs around and what I mostly get for an output is a lot of grey with some kind of waviness going on. Will Somebody Explain This To Me? Huh? Where's The Documentation? (the filter doesn't have a tutorial link) Well, F**k it. At least in this G'MIC mess the Dream Smoothin' filter seems useful.

In spite of such frustrations (which I'm sure drives a large number of people away from G'MIC) a few people have found Gimp-G'MIC useful in aggregate, and among that subset, an even smaller number press on to what seems to be the well-spring: the G'MIC interpreter. It was in that setting, you may recall, that we forged our Gimp Chat relationship; not without its own turbulence -- in the thread G'MIC - tips and curiosities. What you wrote there in those 20 or so tips spread across one hundred posts (well, 99, but some could be profitably split into two or three) was an attempt at 'G'MIC for the common person.' It remains a noble effort, however, I must side with Ronounours when he writes



I remember in that thread where we became acquainted you characterized yourself as 'pigheaded' (the Italian word you taught me was "cocciuto") so this sentiment of Ronounours must clang to the floor as a kind of a challenge. I happen to think that pigheadedness is a very valuable asset. As a person who has been a project manager for software design and development, pigheadedness is a necessary virtue if one is to bring a project home in or under budget, and on time. But I am also sure that during this phase of your life, you encountered the word 'tirage' (or its Italian equivalent). A powerful, poignant word: given too little resources, deciding what can go forward and what cannot.

This is a far bigger thing than Gimp or G'MIC, but a thing with which Gimp and G'MIC must content: there are not enough people to enact all the possibilities manifest in Free and Open Source Software. The various projects are generally understaffed. Ronounours is the principle (and only) maintainer of the core code upon which G'MIC relies. Gimp may have more than a million users worldwide, but how many maintain it? I don't know, but if I had to hazard a guess, I would bet the number of consistent, weekly commiters are probably closer to ten than a hundred. Those of us who contribute to FOSS have to do some sort triage on what the focus of our contributions should be. That means, figuring out a priority stack.

Priority stacks stem from world views, and the world view on the top is my somewhat whimsical notion of what is in Ronounours head. It is also what is in my head. To me, the most accurate description of G'MIC is that of a specialized (but still general purpose) computer programming language that furnishes the research scientist specializing in computer vision a comprehensive, and highly accessible, computer graphics toolkit. A very important facet of its everyday use is that it runs entirely in a command line shell, and that the enormous overhead of paint programs and GUI's aren't cluttering memory. Now if my business was digital imaging, I'd rather like my computer memory cluttered with GUI's because they make the interactive process of illustrating easier. If, instead, one's work concerned testing various ideas about computer vision algorithmically, an image, per se, is not of prime importance. An algorithmic sketchpad which permits pretty quick and informal ways to probe an idea is more important, and Ronounours designed a tool that doesn't need the overhead of an interactive paint program. Five years ago, when I wanted to do G'MIC-like investigations of computer graphical ideas, I used various mixtures of shell programming, Perl, Python, C and C++ and linked to libraries like OpenCV and SciPy. Nowadays, it is almost entirely G'MIC command line in a shell. It really is one-stop shopping, and I can work pretty fast because there is not a whole lot of context switching that has to take place. I seem to recall that a few years ago Ronounours gave an interview to (I think) LibreGraphics World, and he spoke a little bit about the emergence of Gimp-G'MIC, which was not a part of his initial effort. Somebody suggested, however, that a plug-in to Gimp would expose G'MIC to a much larger user base, exercising the code that much more vigorously. Indeed, we saw an example of that in the last day or so. About this time 24 hours ago, Issabella hit a bug in gimp-spotify, and a number of other Gimp-Chatters confirmed the existence and extent of it across various platforms. How long would have that bug lurked had G'MIC been only in the domain of specialized users? I am quite sure there is no disagreement that the best code base is the one that gets thoroughly used.

I suppose, in light of this clear software testing service that the Gimp Community performs for the G'MIC Community, that there should also be some kind of payback to the Gimp Community in the form of G'MIC Documentation for the Common Person. It is a reasonable request. It is a credible request. In fact, it is an important request. I do think, at least in so far as the Gimp-G'MIC filters are concerned, it is entirely possible to write just that kind of documentation. The user-centric, problem-solution oriented process to explain how various Gimp-G'MIC filters may be harnessed to reduce (or artistically enhance) noise is an excellent example, and the project plan you composed for it is one that any professional technical writer can appreciate and run with.

Will I be the one to do it. Probably not. I made my decision on my aims and targets nearly a year ago and I am quite steadfast in my workings (These are stated in the Tutorial Introduction). I really don't write for Ronounour's sake, but perhaps for the Ronounours of twenty or twenty five years ago, not a research scientist, but a technically-oriented undergraduate trying to figure out aims and ambitions. If those run toward computer vision, perhaps some of my scribblings will pull them in the G'MIC direction where they will find, I fully believe, a tool that will crystalize their thinking and accelerate them forward in an intellectual adventure. That also coincides with my own personal interests. I like computer algorithms. I still remember with especial pleasure, now maybe a quarter century ago, when I **got** deCastlejau's pyramid algorithm for generating spline curves. Hot damn, it's beautiful -- a work of art. So I think, given my own personal predilections and inclinations, the audience of potential proto-G'MIC coders is the best audience I can be writing for. And since I only have so many hours for FOSS (the triage thing again), they are the ones for whom I write and probably the ones for whom I can write most effectively. For efficiency's sake, that is the best use of my time.

So what of the common person, currently hitting the wall with Spectral Filter --> Bandpass? There really ought to be a tutorial link there to get that poor sod on the clue train. There ought to be something like that on every Gimp-G'MIC filter. There ought to be a way for us to live for ten thousand years and learn everything we'd like to learn. Ah -- what did you write near the top of this thread? spes ultima dea...? Perhaps someone will come through the door with the inclination and the expertise and with an itch to scratch to do the Gimp-G'MIC centric writing. There's more than enough to keep them busy. We can hope, now, can't we?

I agree Garry, what you point out is clearly that G'MIC has already a quite large range of interfaces and applications, and that ideally, having a documentation targeted for each audience would be nice. And surely, a good documentation for the plug-in wouldn't contain the same level of details about the G'MIC language or the image processing algorithms as your tutorial. As the main coder (98% ) working on this small project, I sometimes don't realize that it slowly becomes not so small, that's why I feel there should not be a need for additional documentation, but I may be wrong.

And of course, I'd like to thank again all the GIMPchat member for all their testing, bug reports and help. They surely deserve a better documentation, but as you know I already spend entire days and lot of my everyday evenings coding and maintaining G'MIC, so I don't think I'd have so much time for it, sorry about that (plus, I'm not a big user of the plug-in myself!).

Cheers,

David.

I like that Gary; yup, it appears to be the conflict of the two universes. lolol

You make some very good points Gary and one of the major ones I take away is in the terminology.

G'MIC vs GIMP-G'MIC

It may have helped levels of understanding if the distinction between the two were clearer, but I think it's rather too late now - that horse has already bolted.

The best you do now is be consistent in using the two names in a distinct way. In fact while I am typing this, David has me, and I don't know if he's talking about G'MIC or GIMP-G'MIC.

Perhaps it would be helpful to re-name this part of GimpChat to GIMP-G'MIC, unless it's here to talk about G'MIC rather than GIMP-G'MIC ?!?




So go on then, explain it In this context I'm not a "common person" as my day job is creating software to test radio frequency equipment, so I understand what a bandpass filter does in the rf domain, but "Spectral Filter --> Bandpass"??? is it filtering the spectrum? - i.e. colours, so low frequency light (i.e. the red end) and the high frequency light (the blue/violet end) are removed? Or is it doing something spacial instead?

Kevin

@paynekj : I was talking about G'MIC as a whole, i.e. all currently existing interfaces (except the Krita plug-in). Honestly, it takes *a lot* of time to develop, and the plug-in takes maybe 5% of that time.
'Spectral filtering' to me means 'filters that works in the frequency domain to achieve their result, basically Fourier or DCT'.

Maybe late in the game, but maybe we need to change the moniker when referring to the GIMP plugin as GG'MIC. Just an idea.

Thank you for clarifying what you meant in that instance by G'MIC, but the fact I had to ask illustrates the confusion.

And frequency of what? colour values? (are the r g & b treated as orthogonal?) luminance? rows? columns? It doesn't actually matter to me but does show the complexity of documenting a simple term like "Spectral filtering".

Kevin

@paynekj : the frequency spectrum of the original input image, viewed as 3 continuous 2d functions (one by channel).

@paynekj
My go. This particular Gimp-G'MIC filter wraps a simple GUI around the G'MIC -bandpass command.

It takes an ordinary and every day image of a dog, cat, house, landscape, what have you and rewrites it as an equivalent array of coefficients for sinusoidal waves - the spectral domain. It uses the discrete Fourier analysis transform, which you are probably very familiar with.

For an image, there is one coefficient multiplier for the 'DC level', the overall brightness of the image, a set of four coefficients for the one cycle wave forms (which have two orientations, and each orientation has a left hand and right hand circularly polarized member) a set of four coefficients for the two cycle waveforms, and so on, up to the Nyquist frequency, for the waveform that has the two pixel wavelength. Of course, their positions in the spectral domain map to their frequency, those close to the DC level representing low frequency coefficients, those far away the high. As Ronounours noted, this transform is applied to each color channel independently. We're not playing with the light spectrum, but we are playing with the sinusoidal basis functions in which images may be expressed.

All of these coefficients are in a two dimensional array which we can imagine as being centered on the DC coefficient, the origin of the spectral domain. The -bandpass command plots a mask, could be a filled in circle or an open ring. Coefficients outside the mask are zeroed-out, those within are kept: hey, presto! a two dimensional spectral band pass filter!

That, of course, is the context of the low and high frequency widgets. The low frequency widget sets the lower frequency of the filter, the high frequency widget sets the upper frequency of the filter, and the filter re-synthesizes the image manifest in the surviving coefficients. Ronounours has written a very nice demo. type "gmic -x_fourier" in your favorite shell, or, in Gimp, start up the Gimp-G'MIC plug in, scroll down to the "Various" section and kick off the "Games and Demos" filter. Pick "Fourier Filtering" from the selector widget and hit OK. You'll see exactly how the Gimp-G'MIC bandpass filter operates.

The crux of the issue is, none of this backstory that I've laid out about the bandpass filter is manifest when the 'common person' first encounters the filter. They tweak the knobs, can't see much immediate use in its funny grey output, and move on, muttering that of the four hundred or so filters in the plugin, a bunch of them (most of them?) seem to be like the same kind of junk the bandpass filter is -- some weird toy a geek wrote.

In fact, the bandpass filter used in concert with other filters is capable of sublime effect. Quite early on in my G'MIC documentation effort I wrote a tutorial of its use in a stained glass effect. Dinasset is quite right in observing that unless somebody lays out the backstory for the Gimp-G'MIC bandpass filter, written in 'common language' (none of this 'spectral domain' or 'circularly polarized' stuff) it will never be used in interesting ways. And yes, the case can be broadened to the filter set in general.

I concur, but in doing that, I also raise the 'triage' red flag. I am already busy in writing entry-level documentation for people who would use the command line tool itself -- sans any paint program -- which really puts me in the top diagram. It would be nice if someone from the bottom diagram world view could actually do the Gimp-G'MIC centric approach. Dinasset has done a good job specifying the remit, but, as often is the case in FOSS, we really have to wait, hoping, for the day when someone comes by, and thinks: 'Hey, presto! I can make this piece work!' and signs herself up. It has happened before, and it will happen again. It's just that we can't wave a magick wand and make it happen when we would like.

Take care.
Garry

I think the easiest documentation for user is by example. I use the spectral filter to remove repetitive pattern in an image. eg scan old photo comes with pattern from the paper texture. The theory behind probably is less of a concern.

I can't help feeling that this whole category of "Spectral filters" (in Gimp-GMIC) would be better named "Spatial frequency" .. because that is fundamentally what we are dealing with here. (The word "filter" is unnecessary.)

In the mind of the average not-particularly-technical user, the word "spectral" is always going to be associated with colors first and foremost, not s..p....a.....t.....i..a.l disposition.

(It even had me fooled when I first started using GMIC some months ago, and I come from an electronics engineering background ..well versed in FFT, z-transforms, etc. It was only when I had a look at the Fourier Watermark that I realised it was spatial frequency we're dealing with here, not colour channels!)

Hi all, fascinating discussion, I use g'mic with trial and error method. and use g'mic to get a "look" I want in my paintings. again ,very nice discussion.

All I ever want to know is what results the sliders will make on my picture. I know the interactive preview helps tremendously, but it would be even more helpful if we knew more about the changes the sliders make, especially when using multiple sliders. Sometimes the picture is almost how I want it, but then I don't know which of the sliders will make the further changes I am looking for. Trial and error is what I use now, but then sometimes I can't remember where I started to get a particular slider back to where it was, without resetting the whole thing.

Hi 2-ton, What you can do is write down on paper or make a note where "sliders" are set before you make changes. but this is a little extra work.