Mosfet Contributes Code to KDE (Again)

Many in the KDE community are aware of some rocky history between
KDE hacker Mosfet and other KDE developers.
Fortunately, it looks like things have taken a great turn for the better:
Mosfet wrote in to tell us that "I've decided to donate 20 effects I ported to KDE/Qt
for PixiePlus to KDE3
Waldo Bastian promptly
added them to CVS.
The new effects include normalize, equalize, solarize,
threshold, emboss, despeckle, charcoal, rotate, sample, addNoise, blur,
edge, implode, oil paint, sharpen, spread, shade, swirl, wave, and
contrastHSV. All will be available under a
BSD-type license in the
According to Mosfet, these effects will be useful not only for image viewers
and editors, but also for things like style engines.
Except for the simple rotate, Mosfet ported the effects from
ImageMagick to work directly on
QImages and
Qt scanlines. Nice job, Mosfet!
(For those who have not yet heard the news, PixiePlus is the successor
to Pixie; more information is available

Dot Categories: 


by Benjamin C Meyer (not verified)

Any posiblity of getting the fast thumbnail browser into konq? Speaking of does gnome use .pics also now?


by Mosfet (not verified)

No idea about Gnome but when I was first developing PixiePlus I did code a Konq file view for it. You selected it in the same manner you selected other file view types like "Detailed List View", etc...

by Benjamin C Meyer (not verified)

Is there anyway that that is sitting somewhere that I can grab? With my digital camera I frequently download multi-megabyte files that a fast preview like that would rule.

by Mosfet (not verified)

PixiePlus has the fast thumbnail viewer. Use that to browse your images. For over 5,000 images I could immediately view all perviously generated thumbnails in < 5 seconds. For only a couple hundred it's a second or less. This is considerably faster than anything else. If the images are multimegabyte and you have a few thousand of them they will still take awhile to generate previews, but you only have to do this once. After that it will be < 5 seconds to view all of them.

by Ralf Nolden (not verified)

Hey mosfet,

could you do us all a favour and add gphoto2 support to pixieplus ? :) kamera sucks, you may have a look at the new digikam app on for code.

Happy new year!


by Mosfet (not verified)

Sure, if someone sends me a Linux compatible digital camera ;-) I have a scanner so usually take normal photos and scan them in.

by Ralf Nolden (not verified)

Hmpf, I tried all morning to get gphoto2 to work with my new Olympus over USB - it even refuses over /dev/ttyS0 which I use in gphoto 0.4.3 successfully. I mean, beta3 works as far as it recognizes my camera correctly over usb but resets the number of pictures to 0 - which makes this pretty useless.

But for others, it sure would make sense. Mosfet, you just have to look how digiKam does it (more or less). gphoto2 just is a commandline tool where you write a frontend for; sure there would be testers (I would even help if my camera would work with gphoto2...)


by Mosfet (not verified)

Again, if someone sends me a compatible camera I'll do it ;-) I'm not going to write code for something I cannot test :P

by Ralf Nolden (not verified)

:) I wouldn't either but how do we deal with this *if* my camera works with gphoto2 ?

Could you put pixieplus into a CVS ? BTW does it make use of the scanner dialog in KDE ? (my scanner only has an isa card and I'm too lazy to install it into my other machine to try it, just wanted to know :))


by Mosfet (not verified)

Last time I say it: we deal with this by someone sending my a compatible camera so I can test it. I will not add or accept features I can't even test. If you really want it, donate a camera. I'm not going to spend money on something I don't need for an application I give away for free, nor will I accept patches for things I have no idea that work.

by Ralf Nolden (not verified)

William Shakespeare: As You Like It

Nevertheless, happy new year :)


by Mark Johnson (not verified)

> nor will I accept patches for things I have no idea that work.

Damn good job you're not in charge of the kernel.
"No, I'm not putting that Sparc or IA64 support in lads, I've no idea if it'll work"

by ac (not verified)

>I will not add or accept features I can't even test.

So you don't care about portability fixes or translations then?

by thoreau (not verified)

Why not just add a simple 'Open from Camera' or something that uses the gphoto kioslave (if present). If the kioslave works, then PixiePlus shouldn't have a problem. This brings up another issue altogether as KDE should allow a user to 'create' devices in the sense that Floppy, CDROM, Digital Cameras, MP3 Players, etc. can be more easily accessed by application and browsed via Konqueror. kioslaves provide the grunt work, but I believe there is some definite UI work that could make them easier to use. I know, the general response will be 'just type gphoto:/' and stuff, but I think it would be cool for KDE to have a way to 'create' these so that there is an actually system item that is browsable directly in all file dialogs and is named according to the system administrator/user's preference... (i.e. browsing to 'Hitachi Digital Camera' in FILE / OPEN to get pictures from a digital camera)

One of these days, I'll get around to actually creating and using in order to SHOW what I mean :)

Any way.. these are just my point. HAPPY NEW YEAR!

by Roberto Alsina (not verified)

Well, if pixieplus used ioslaves, and supports d&d, then al you have to do is drag
the image from a konqueror view.

by Srinivas Rao.M (not verified)

Is there any tool(along with C sources) available for automatically converting the images in the directory while it is browsing and showing its thumbnails when a preview option is selected. I am trying to write a lightweight tool to browse my directory which has multiple jpg/gif images in it.

Srinivas Rao.M

by Thorsten Schnebeck (not verified)

Yes, kio-kamera in HEAD seems to be in a very bad shape :-( A configuration of my IXUS crashes the whole control center - ok - it's beta...

BUT here is my wishlist feature: panorama picture merging.
Many digicams have a feature of making a sequence of pictures showing you an overlapping area during the shot. Canon has a tool for this merging stuff but -of course- its Mac and M$-Win only. The job is more than an easy crop&merge: you need some gamma-ticks and maybe morphing-things in the merging-zone.
That sounds like fun, or? ;-)

Happy New Year


I can't spend a camera, but a sequence of such pics ;-)

by Thorsten Schnebeck (not verified)

Yes, kio-kamera in HEAD seems to be in a very bad shape :-( A configuration of my IXUS crashes the whole control center - ok - it's beta...

BUT here is my wishlist feature: panorama picture merging.
Many digicams have a feature of making a sequence of pictures showing you an overlapping area during the shot. Canon has a tool for this merging stuff but -of course- its Mac and M$-Win only. The job is more than an easy crop&merge: you need some gamma-ticks and maybe morphing-things in the merging-zone.
That sounds like fun, or? ;-)

Happy New Year


I can't spend a camera, but a sequence of such pics ;-)

by Benjamin C Meyer (not verified)

Is there anyway that that is sitting somewhere that I can grab? With my digital camera I frequently download multi-megabyte files that a fast preview like that would rule.

by John Ericson (not verified)

What is .pics?
Is it the name of a hidden directory where the thumbnails is placed?

by dr88dr88 (not verified)

Menu Transparency support is in KDE3 CVS. And its finally the real XRender one!

by anonymous (not verified)

But that doesn't seem to mean it's updating what's beneath it in realtime?

The KDE CVS code uses the exact same code to perform translucency as Liquid. It's actually based on MegaGradient and uses QPixmap::grabWidget() to take a "snapshot" of what is behind the menu before displaying it. What it *does* do is use XRender instead of KPixmapEffect to lighten, darken, or otherwise modify the resulting image if available, but this doesn't speed up the code visibly or change the translucency at all, that is the same. In fact, it will be slower on non-accelerated XRender implementations. So I don't know what you mean by "real XRender one". Not to rain on the parade but I think it's unfair to imply that this provides a different translucency than is already available - it doesn't - otherwise I'd be using it ;-)

by hash (not verified)

no matter what you do in X, you can't get real translucent windows. it's only an illusion.

by anonymous (not verified)

I think Mosfet gets too much attention/publicity compared to others hard-working KDE developers.

by not me (not verified)

Don't worry about it! He gets that much attention because he
_needs_ it (methinks). And I like this behaviour. In german you`d
say Paradiesvogel, what means he just don't want to be an ordinary man.
This does not say other coders are ordinary people, just different in
their style...

by Mosfet (not verified)

Yep, I'm loud and noisy >:) Hell, I'm doing this for free and for fun, and I've never shyed away from making waves :)

Anyways, I hope these effects will be put to good use by other developers and helps KDE3. This time instead of making waves I'm trying to show some goodwill to the KDE core team. Hopefully we can start working together on some stuff more often. Honestly, working solo has suited my style more and I'm getting lots more done these days, but that doesn't mean there has to be any conflict and that stuff I code on my own can't be contributed to the KDE project now and then. I've cooled down a lot now.

by Bojan (not verified)

I think that if someone does something for free, even if he/she gets all the publicity in the world, nobody should complain. So thanks Mosfet and thanks to all the other KDE developers! Oh, and BTW, happy new year to all. ;-)

by Linux4Green (not verified)

Cooled down a lot is understatement! :-P

Thank you, very glad you and KDE peoples are getting back together somewhat.
It's all common goals. Make the Windows killer!

Happy New Year all of KDE!!!!!!

by Timothy R. Butler (not verified)

Thanks for contributing the code Mosfet! :-) Like others have said, it's nice to see you and the KDE Core team are working together again. Keep up all the great work, your Liquid style is wonderful, and these contributions sound very good too.

by Jérôme Loisel (not verified)

Perhaps that suits your style better: code by yourself, then give it to someone with CVS access. Hopefully it will work out like that more and more for you. Only a fraction of the people who have KDE ever download and install add-on software. These effects will reach a lot more people this way and that is great.

Thanks for the great work! I hope the same happens with Liquid some day. :-)

by Edward Rataj (not verified)

Welcome Home, Herr General Feld Marshal Mosfet,
No progress in any field is paossible without the
:"dreamer or loner".
Your outstanding code for KDE stands on it's own.

I for one, who is nauseated whenever the mighty
M$ raises it's head, am very happy to see you
back. I know now that the elegant KDE will not
fade away.

Ein froehliches Neu Jahr...


by Dan (not verified)

I don't think it takes much brains to realize this is pretty nice of Mosfet. Thanks man.


by Craig (not verified)

Thanks a lot Mosfet this is very cool of you.


by KDE User (not verified)

Thanks Mosfet! We love you.

by Rob (not verified)

All the Linux graphics programs I've seen make it a pain to initialize a slideshow from 'all the files in a directory'.

This very nice feature is the way irfanview (windows only, though) works by default. Open any image, and you can use the spacebar/backspace keys to sequence through the directory. Or open a thumbnail window and click the thumbs to seed the image window, after which the spacebar/backspace trick continues to work.

The biggest pain is using Konqueror to view images. The thumbnail listing isn't TOO slow (once you've got .pics set up), but clicking on a thumbnail to 'open' it means that you need to regenerate the thumbnail list when you close it.

Which brings me to my Konqueror complaint... Why must all the 'open' actions default to an embedded KPart? I find myself right-clicking all the time to avoid this. Is this configurable? Bye MIME type?

Sorry to sound so bitchy. Just some suggestions..

by David Bishop (not verified)

Yes, it's configurable, yes it's by file/mime type. Open up the config dialog, go to "file browsing", "file associations", find the file type you want, and then select the "embedding" tab. Go to town :-)

by Mosfet (not verified)

Left and right cursor keys go back and forth through the filelist, up and down keys go back and forth through all the images in the current browser folder (exactly what you described :) The fullscreen view mode also has buttons for this.

The slideshow feature can use either the filelist or all the images in the current folder.

Thumbnail viewing is also much better and faster.

No need to use Windows anymore ;-)

by antialias (not verified)

PixiePlus is very fast, nice and stable :) so I don't know why you've chosen '0.1' as release version?
The only thing I miss in PixiePlus is right click on image and 'Edit with...(for example Gimp)' option (hm, wishful thinking maybe?).

by Ralf Nolden (not verified)

Why not use the KDE functions for that in KRun or KOpenWith like in Konqueror ?


by Mosfet (not verified)

Yes, makes sense, especially since I already use KRun for executing non-image files.

by reihal (not verified)

After I have clicked on an image in Windows (with ACDSee installed) I can slideshow through all images in the folder/directory with the mouse scrollwheel (or the scrollwheel on my new Logitech keyboard).
No need to use the thumbnail browser since it loads the full images doublequick.

by raindog (not verified)

It's a gtk program, not Qt or KDE, but gqview makes it pretty easy to do a slideshow. Two menu clicks or just type "sv" while viewing a picture, and it starts a fullscreen slideshow of the current directory. If you mean an interactive slideshow, you can go into fullscreen mode with "v" and left or right click to go forward or back (or arrow up/down.) It preloads images in whichever direction you're browsing to minimize rendering time (which is slowed down a bit when you use their best quality scaling method to stretch images to fill the screen, as I do.)

PixiePlus looks closer to the comfortable ACDSee mode of image browsing, which I miss a lot, but gqview is quite fast and nice to use, and has a "find similar" mode no other Linux image browser seems to have (ACDSee didn't either last I checked.) gqview also just went 1.0 and is pretty stable.

Currently I have to patch each new version to make multiple image selection in browse mode work the way I was used to in ACDSee, but sooner or later my patches will get accepted ;)

I think much of gqview and PixiePlus's functionality may also be found in XnView, which is crossplatform and a little ugly in its X incarnation but works fine and is very mature.

by Mosfet (not verified)

Similiar image finding will be in 0.2, due next week. It is based on findimagedupe's excellent algorithm and uses a persistant database. It's quite fast :)

by raindog (not verified)

Thanks, looking forward to trying it out. It'll be nice to see an implementation of my algorithm that doesn't take 18 hours :) (The gqview guys used their own algorithm, it's fast enough but the results are a little different...)

by Mosfet (not verified)

Hiya, nice to see you here! I found the algorithm in findimagedupes more accurate. It's really rather clever. The algorithm I used is virtually identical to yours. As a matter of fact, the reason I started porting effects from ImageMagick was to get the necessary blur, normalize, and equalize effects as fast as possible ;-) You'd think it would be slower than averaging blocks of pixels like GQView, but actually it's not. In PixiePlus it's way fast :)

Findimagedupes performs quite well with a small amount of images, but really suffers from a small hash table size. For 47 images PixiePlus takes 11 seconds while findimagedupes takes 20. That's really not bad since it's compiled C++ vs. interpreted code. But when you increase the number to 5,049 images PixiePlus only takes 23 minutes while findimagedupes takes 1hr 16min.

PixiePlus also uses a persitant database, but it's not compatible with findimagedupe's. It's a binary database that also includes timestamps so you know if an image is modified and needs to get a new fingerprint. I could write an import and export to findimagedupes if you think it would be useful. I certainly can see value in a commandline utitlity for this as well as Pixie :)

Here's a comparison of the different methods I wrote for the Pixie docs. I also did a quicky screenshot of the comparison results which uses a nifty tree view (double click on the image to view, right click for a menu). It's at Of course there is also a 2 step progress dialog for generating/loading fingerprints and comparing ;-)


Notes on simularity comparison algoritm and performance

Much attention was spent on making finding similiar images perform as
fast as possible while still being accurate. Compared with other Unix
offerings PixiePlus performs quite well in this aspect.

There are two main algorithms for finding similiar images. One is used
by GQView and ShowImg. It is based on averaging blocks of color
channels and comparing the result. This is the obvious algorithm and
the one I was originally going to adopt. In GQView it performs with
acceptable speed, in ShowImg it does not. I'm not sure why this is
since the code is pretty much directly copied from GQView. Either way,
it tends to miss some matches found in the other available algorithm.

The other algorithm isn't based on colors at all but identifying the
general patterns in the image. This is the method used by the Perl
utility findimagedupes and is the method I adopted for Pixie. What it
does is sample an image to a standard size, apply a couple effects to
get rid of abnormalities, scale it down again, then convert it into a
string of bits suitable for use as a thumbprint. While it sounds like
it would take much longer than the above method, in reality it
doesn't, and it finds similiar images the other algorithm misses.

Like findimagedupes and unlike GQView and ShowImg a persistent
database of fingerprints is used so you don't have to regenerate
fingerprints or calculate image blocks each time you compare images. A
binary database is used in order to avoid parsing ASCII
representations of the binary thumbprint. Unlike findimagedupes the
database also contains timestamps so it can tell if an image has been
modified. A large hash table is used and should perform well for
folders up to 6,000 images. After that expect performance degragation.
Findimagedupes especially suffers from this. On my test machine,
(AMDK6 450MHZ/128M), initially comparing 47 large images takes 11 sec
on Pixie and 20 sec using findimagedupes. This is really good speed
for findimagedupes considering it's in Perl. But when the number of
images is increased to 5,049 findimagedupes slows down to 1hr 16min
while PixiePlus only takes 23min 14 sec (the fastest of the bunch).

by raindog (not verified)

Oh, I don't mind incompatibility if it means PixiePlus can compare 5000+ images in 23 minutes. Mine was originally meant as a lazy reference implementation and it turned out to be good enough for my mostly small image collections. Maybe with QT3 the local database file won't even matter anymore if its built in database functionality is worth anything.

But I may try to do a C++ command line version that uses your database format; someone emailed me C++ compare code using my format (built it but never benchmarked it) so it'd really be a matter of teaching it about your database format and tying in Magick++ support to build the DB. I've had complaints about my kludgy attempts at providing an interface for GUI programs but now it won't be necessary. Thanks again. Neat looking result interface by the way.

by Asif Ali Rizwaan (not verified)

First a Very Happy and Bugfree, Stable, and i18n_ed New year to you all :)

Welcome Mosfet, I know you were not gone from KDE but just took a break; like every developer you are also kept at high esteem by the users. Thanks.

by Bill Soudan (not verified)

I'm very disappointed to see this on the dot. I'm hoping the only reason this was posted is for lack of better news. This story is really quite thin, at best it's a quickie - don't people contribute code all the time? Should every new contribution be accompained by a dot story? My gut feeling is no, of course not, then the dot would be kde-cvs. It seems to me the case here is that because it came from Mosfet, it's news, and that's very sad to me.

He's a good coder and has made very worthwhile contributions to KDE, I don't disagree. I'll even be more than happy to say that I'm glad you're making contributions again, Mosfet.

However, his contributions are certainly no different than any of the other MANY individuals who dedicate their time and energy to the project. I'm much more interested to read Tink's excellent 'People of KDE' series about the contributors who you DON'T hear about, you know, the ones who aren't in the news all the time because they are mature adults. Mosfet has long since had his fair share of KDE publicity.

This whole Mosfet-KDE thing is just turning into an endless soap opera, and I honestly feel keeping it alive is bad for the dot and the KDE project. I think the risks (i.e. pissing off other contributors who feel slighted because Mosfet gets a lot of very undeserved attention, tainting KDE's reputation as well as OSS as a whole with the negative publicity) far outweigh any benefits (i.e. get a news story up for more traffic, more publicity is always good). I hate to even feed into it by posting this reply, but I feel it's time to speak up so the editors hear some more opinions.

Please, please, keep the dot as clean and professional as it usually is, and stop with the Mosfet stories. If there's merit in them, fine, I'm by no means trying to say he should never be mentioned again. Instead, in the future, please use the same measure that any other story in the queue receives.

Anyway. Just MHO. Flame away, everyone, I'm *very* interested in responses.

by Anonymous Ed (not verified)

Write stories. Submit them. The dot is what you make it.

Mosfet was nice enough to write us with details of his work. It was found interesting and posted to the dot.

Where are those individuals who are being slighted? *Please* stand up. Submit your news to the dot. Write a story, write us. You will get just as much consideration as Mosfet did when he submitted this news.

-Anonymous Editor.