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

List:       koffice
Subject:    Re: kimageshop native file format and koffice filter framework
From:       Werner Trobin <wtrobin () carinthia ! com>
Date:       2000-02-22 19:40:10
[Download RAW message or body]

Matthias Elter wrote:
> 
> Hi
> 
> 1) I'm currently implementing a native KImageShop file format using
> KoStore and QDom. I'm basically saving image/layer/channel attributes in
> the XML file (see kimageshop.dtd) and the actual image data in binary
> files, all stored using KoTarStore. This gives me
> LayerCount*ChannelCount binaries. All in all this is a easy to handle
> and more important easy to write import filters for file format. Any
> suggestions regarding the file format?

I don't know if KTar is able to handle that, but by default it compresses
the binary data (=images). If I save a png image I loose some time because
it is compressed already. Am right? Is the "performance hit" big enough to
optimize for that case? David?

> 2) I had a deeper look into the KOffice filter framework recently. Great
> work, Werner!

Thank you! Now we only need some filters :)

> While I like the current implementaion I'm a bit concerned
> wether it's going to work for KImageShop. The problem is, while KWord
> and KSpread documents are (relatively) small text files and (relatively
> ;-) fast filtered with the current approach, importing a large TIFF
> image into KImageShop would be quite slow because of the indirect nature
> of the filters.

BTW: Last time I checked QDom was dog-slow. Any news on that, David?

> Just think of a 30MB TIFF loaded from disk, converted to
> a temporary KIS image which is saved in a tmp dir and then opened by
> KImageShop. What I want to say is that it might be better (faster! :-)
> for KImageShop to import foreign file formats directly. On the other
> hand a direct-loading filter framework for KIS would of course be
> incompatible with the KOffice filter framework, KIS filters would have
> to know about KIS internal data structures and link to libkiscore.
> Opinions, suggestions?


I can think of a very nasty hack to get both, but I'm not sure if that
will work so please don't beat me for that foolish idea:

Let's assume you use the "normal" KOffice filter interface and optimize
by:
- allocating a huge chunk of memory (that your KIS image data fits into
  that chunk)
- converting the file to the KIS format
- creating a file which contains some XML (the additional information
  and ... yes ... the address of that chunk of memory  >:->>> )

KIS opens that temporary file and sets a pointer to that address :-P
Now you have got the data of your image. All the additional data is
stored in the remaining XML of the file...

Werner,

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