This document aims to explain the feasibility of image processing using GTK. The document scratches the surface when it comes to explaining the nook & corner of Image processing theory. It shows examples of pixel based filters and convolution filters. Developers are asked to rewrite the doc to GTK#.
Image Processing using GTK+
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
see subject, but where are the tex sources ?
Hei, mates :
today everything goes for vectorial graphics, give me a good-finished toolkit that is not bloated and has all the basic vectorial graphics specifications.
do we have any svg player for linux, standalone or plugin(yuk ->batik related)
something like a COM component , nothing.
and we are still remakeing gd – gd2 – etc …
What’s so much wrong with Batik?
“today everything goes for vectorial graphics,”
You don’t get vector graphics from a digital camera or a scanner. Bitmap images and structured graphics, separately or in combination, are suitable for different tasks.
An image processing program is for manipulating existing bitmap images. A paint program is similar but is slanted toward the creation of bitmap images from scratch.
Vectors are useful in both for defining selection regions, or curved paths for brush traces, but the result is still a bitmap image.
A “drawing” program is for creating vectors. Illustrator, Freehand and Corel Draw are examples.
CAD programs are different again, as they are based on exact measurement rather than judgement by eye.
Well, much as I appreciate the attempt to introduce people to image processing, aren’t there existing functions for this sort of thing in GTK?
I’ve used QT to write image processing applications in the past, and it does do all of that stuff for you, including convolutions, scaling (with resampling), colourspace conversions, masking (alpha and custom), altering bit depths, mirroring, inversions, dpi mapping, offsetting and meta-data management. Not only that, but it also supplies a pointer to the start of the image data (32bit per pixel, 1D array) should you wish to manually manipulate the image at a per-bit level or perform complex operations.
This is the sort of level that a modern toolkit should perform, realistically. If you look at Java, you’ll see that the JAI and JFC perform these functions. VB6 didn’t (and a decent IP library was a pain to find), but I can’t speak for the .Net stuff.
For the writer’s benefit, the best way to adjust the brightness of an image in a linear fashion, is to convert to HSI, increase the Intensity for all pixels and then convert back to RGB.
I’ve used QT to write image processing applications in the past, and it does do all of that stuff for you, including convolutions, scaling (with resampling), colourspace conversions, masking (alpha and custom), altering bit depths, mirroring, inversions, dpi mapping, offsetting and meta-data management. Not only that, but it also supplies a pointer to the start of the image data (32bit per pixel, 1D array) should you wish to manually manipulate the image at a per-bit level or perform complex operations.
If QT can do all that, then wht is the GIMP writed in GTK?
“If QT can do all that, then wht is the GIMP writed in GTK? ”
thats unrelated. qt is a library. gtk stands for gimp toolkit and gimp itself was the reason gtk is written and to answer you qt was not open source earlier. now its gpl/qpl license
“For the writer’s benefit, the best way to adjust the brightness of an image in a linear fashion, is to convert to HSI, increase the Intensity for all pixels and then convert back to RGB.”
Or even better, do it in Lab space.
But what most people think of subjectively as “brightness” is nearer to gamma than to the overall lightening you mention, which gives a washed out effect. A quick way to adjust gamma is with the middle pointer in Photoshop’s “Adjust->Levels” control. The GIMP has a similar adjustment.
If QT can do all that, then wht is the GIMP writed in GTK?
That might be a lot of capability for a toolkit, but its not that much capability for a high-powered image processing app like GIMP. Most of GIMP’s code for image processing is probably custom to the application. In any case, the first GIMP versions with GTK came out around 1996, only a year after the first *commercial* version of Qt.
That might be a lot of capability for a toolkit, but its not that much capability for a high-powered image processing app like GIMP. Most of GIMP’s code for image processing is probably custom to the application. In any case, the first GIMP versions with GTK came out around 1996, only a year after the first *commercial* version of Qt.
In any case, I see GTK better for the image rendering than QT.
And the GIMP is the perfect example.
How so? What APIs does GIMP use in GTK+ that aren’t available in Qt?
Re: Don Cox
>Or even better, do it in Lab space
True
But HSI equations are a little easier for a lay programmer (or if your toolkit converts for you).
Re: Anon
>In any case, I see GTK better for the image rendering than QT.
>And the GIMP is the perfect example.
The question of image rendering is nothing to do with image processing, and GIMP doesn’t form a reasonable example of either. GTK is the Gimp ToolKit, designed in advent of the post-Motif age as a UI toolkit for use with the GIMP as a package. The use by Gnome and subsequent development is tangential and not important here.
The essential point, is that GTK was made for the early GIMP to build windows and present images. It does not do image processing, as the GIMP leaves that for the GIMP core application, rather than the toolkit. A GIMP-style application could be written using QT or wxWindows, or many other toolkits, because the core is not truly toolkit-specific. The only reason that the GIMP has not had the user interface reimplemented using another toolkit, is because the code at present is too tightly bound together to make that possible. The next iterations of the GIMP are designed to segment the core from the GUI, which will allow this more readily.
In terms of this coversation, the point is whether the GTK toolkit itself has good image processing functions, that a person writing a new application can take advantage of. From the looks of things, if a person wanted to write a new application that simply opened an image, flipped it, rotated it and did a convolution, they would be better off using QT, unless they decided to use GTK and write the operations themselves, or add a dependency on the whole of the GIMP. This is an exageration, since they could use ImageMagick or another IP library, but you get the idea.
By that reasoning the win32 api would be the unchallenged best: Photoshop is written in it. There was a QT port of the gimp in the works a while back, but the gimp dev’s were appalled by this and sadly, the project was stoped.
That’s an illogical stance to take. By your “logic,” Motif is the best toolkit for graphics applications, because Maya uses it!
Since there is also a photoshop version for macOS i think adobe as the app code itself abstracted from the toolkit.
In terms of this coversation, the point is whether the GTK toolkit itself has good image processing functions, that a person writing a new application can take advantage of. From the looks of things, if a person wanted to write a new application that simply opened an image, flipped it, rotated it and did a convolution, they would be better off using QT, unless they decided to use GTK and write the operations themselves, or add a dependency on the whole of the GIMP. This is an exageration, since they could use ImageMagick or another IP library, but you get the idea.
Did you bother to download and read the pdf? Even the topic, “Image Processing Using GTK+”, should have given you clues.