[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: kimgio and qimgio : nonsense.
From:       Andrew Richards <physajr () phys ! canterbury ! ac ! nz>
Date:       1999-05-20 6:52:43
[Download RAW message or body]


I wrote jpeg write support for kimgio and gave it to Taj 
a long time ago but it never made it into the CVS. (Probably because it had an 
ugly hack to set the compression parameters). Since then I've developed an 
extension to kimgio which does this a little more cleanly and also lets you 
send/recieve image parameters parameters. 

I'm still trying to find a nice way to set/read image parameters for new types 
of images without resorting to a specific struct for each image type. I wonder 
of the trolls have any ideas on this one?

Anyway, I'd be happy to work on this again in a week when I have handed in my 
thesis (surreal concept).

Andrew
======


> I think the current situation is nonsense.
> We have kimgio, that can't properly save PNG (colors get screwed) and that
> can't save JPG at all.
> In qt there is qimgio, that does all this very well, but which is not installed
> by default, as it is in extensions/
> This mess makes it impossible to save JPGs from kpresenter / ksnapshot / ...
> which is a terrible situation (a presentation converted in BMPs is awfully huge !!)
> 
> * What are TT's plans about qimgio ? Will it be really part of Qt one day ?
> (cc'ed to qt-interest about this question)
> * It's opensource, dammit. Why can't we borrow the PNG & JPG saving code from qimgio
>  and put it in kimgio ?
> 
> We want to get rid of GIF, ok, but for that we need proper tools able to save PNGs and JPGs !
> 
> David
>  who wonders if there will be a merged [qk]imgio one day, instead of the current nonsense.
> 
> -- 
> David FAURE
> david.faure@insa-lyon.fr, faure@kde.org
> http://www.insa-lyon.fr/People/AEDI/dfaure/index.html 
> KDE, Making The Future of Computing Available Today
> 

[prev in list] [next in list] [prev in thread] [next in thread]