Fwd: My KImageEffect code

[Mosfet]

On Friday 26 November 2004 11:15 am, Frerich Raabe wrote:
> On Fri, Nov 26, 2004 at 03:09:13PM +0100 or thereabouts, David Faure wrote:
> > ----------  Forwarded Message  ----------
..snip..
>
> For what it's worth, KImageEffect seems to work good enough for the
> majority, no? I bet you as the author are aware of a number of issues, but
> I cannot remember any threads about it being insufficient, nor did I notice
> too many (any) bug reports about it.
>

No, this is definitely not true. The ImageMagick-based effects never got much 
use, (hence bug reports from users), because they never worked right ;-) I 
got complaints from several developers about this a long time ago. They need 
to be either fixed, (which I have already done for my library), or to go. 
They are wrong and do not produce nearly correct results. As I said I haven't 
used QImage for awhile and I can't believe how borked that old code of mine 
is :P I've already found dividing by the wrong divisor because of different 
pixel scales, using the wrong HSV values, and other stuff that is way 
inefficent. Maybe I've improved while I've been away, but damn that's bad 
code ;-)

Note I am only talking about stuff I ported from ImageMagick, (contrastHSV, 
blur, enhance, equalize, normalize, etc...). Not the rest of KImageEffect 
that I and many others written from scratch. That of course works fine, 
(except the fast contrast(), which apparently Waldo already noticed ;-).

..snip...
>
> The main issue is maintainership. From what I gathered, Maksim is the only
> one works on that stuff every now and then (I apologize in advance in case
> I overlooked anybody :-), so the last call is probably his. I for one am
> not aware of any problems with KImageEffect which would justify rewriting
> the image effects from scratch (and then finding a poor soul who has to get
> into the new code).
>

Probably because you've never seen an app use the parts that need to be 
fixed :P

> On a sidenote, I suspect the 'Standard C++' part is just doomed to get
> dragged and drowned into the "How standard is The Standard really?"
> discussion.
>

No. Have you actually looked at this code? There is "nonstandard" then there 
is "totally screwed up". My thinking was that if I replicate parts of how 
ImageMagick works it would be easier to update, but this was wrong. It just 
ended up being both nonstandard C++ and borked :/

> > The other option would be to drop the ImageMagick based effects from
> > KImageEffect. I think this would be a shame since I have better code, but
> > since I am no longer working with QImage it may make sense. It's also
> > questionable if the base libraries really need things like equalize, or
> > if it would be better for developers to use a second library if they need
> > the more sophisticated effects.
>
> You imply a third option which is to leave things in kdelibs as they are
> (and continue living with whatever flaws there are) and make people who
> need more sophisticated support for image effects aware of your stuff
> (which presumably is available as a $OSS_LICENSE licensed library
> somwhere?). And this is what I vote for.
>

I don't really consider that a valid choice. The effects I am talking about 
are broken in KDE, (not limited or flawed), so never seen much use. If you 
core developers decide to keep them I need to know so I can submit patches 
for them to be fixed for KDE4.0. Why would you vote for keeping broken code 
in KDE?

If your worried about maintainership taking them out is a totally valid 
solution as well. As I said, no one really used them in the first place. If 
you want to keep them cool, but I need to know so I can start backporting 
fixed versions to KImageEffect.

> - Frerich