[Kde-graphics-devel] KImageIO

Greetings,
 This isn't hard core graphics, but I figured it might be of interest to
people.   I have created a ImageMagick based KImageIO plugin, the unit and
validation tests pass, but its missing a few key elements to be generally
useful.  The big one is the QImageIO regexps to determine the image's format.  
The second one is meaningful mime-types for the file load/save dialogs.  If
anyone is interested of capable of helping with these two issues here are the
images that I currently am missing information for:
Magic Regexps
art - PFS: 1st Publisher
avs  - AVS X image file
cgm - Computer graphics metafile
cur - Microsoft cursor icon
cut - Dr Halo
dcm - Digital imaging and communications in medicine (DICOM) image
dcx - ZSoft IBM PC multi-page Paintbrush image
dib - Microsoft Windows device independent bitmap
eps - Adobe Encapsulated PostScript
eps2 - Adobe Level II Encapsulated PostScript
eps3 - Adobe Level III Encapsulated PostScript
epsf - Adobe Encapsulated PostScript
epsi - Adobe Encapsulated PostScript Interchange format
fax - Group 3 TIFF (FAX image)
fig - FIG graphics format
fits - Flexible image transport system
gplt - Gnuplot plot image
mat - MATLAB image format
otb - On-the-air bitmap
palm - Palm pixmap
pcd - Kodak PhotoCD Image (PhotoCD)
pict - Apple Macintosh QuickDraw/PICT file
ps - Adobe PostScript
ps2 - Adobe Level II PostScript
ps3 - Adobe Level III PostScript
psd - Adobe Photoshop bitmap file
rad - Radiance image file
sun - SUN Rasterfile
svg - Scalable Vector Graphics
viff - Khoros Visualization image file format
wbmp - Wireless bitmap
wmf - Windows Metafile
wpg - Word Perfect graphics file
xwd - X Windows system window dump

Mime Types
art - PFS: 1st Publisher
avs   - AVS X image file
dcm  - Digital imaging and communications in medicine (DICOM) image
dcx - ZSoft IBM PC multi-page Paintbrush image
dib - Microsoft Windows device independent bitmap
fits - Flexible image transport system
mat - MATLAB image format
palm - Palm pixmap

Any takers?

Cheers
 -ian reinhart geiser

[Dirk Schönberger]

> This isn't hard core graphics, but I figured it might be of interest to
> people.   I have created a ImageMagick based KImageIO plugin, the unit and
> validation tests pass, but its missing a few key elements to be generally
> useful.

Sounds really interesting.

Some questions:
- Which of these filters are supported by ImageMagick natively, and which
are supported via external helper application?
  I am not sure if a dependency on a helper application would be really
useful. This applies e.g. for the eps KimageIO reader, which IMHO just
  calls Ghostscript, like the current EPS QImageIO filter, too

- which formats are read-only, and which are read write?

- I would be interested in adding file format specific parameters. E.g. if I
have a vector data format, I would like to be able to specify the
  intended width and height

- which external libraries uses your KImageIO filter. E.g I have a SVG
import filter, which unfortunately needs glib, librsvg and a couple other
  libs, which make it rather "politically incorrect"

> The big one is the QImageIO regexps to determine the image's format.

- I think at least in QImageIO the file extension should suffice
- At least in SVG it is rather difficult to find a magic regexp. You can
more or less decide if you have a XML file, but there is no easy way to
  extract the magic "<svg>" tag, because it isn't on a fixed possition in
the file. This applies IMHO for all "text based" graphics format or
"container based" graphics format (e.g. gzipped SVGs or .svgz files)

Regards
Dirk

[ian reinhart geiser]

Dirk Sch?nberger said:

>> This isn't hard core graphics, but I figured it might be of interest to
>> people.   I have created a ImageMagick based KImageIO plugin, the unit
>> and
>> validation tests pass, but its missing a few key elements to be
>> generally
>> useful.
>
> Sounds really interesting.
>
> Some questions:
> - Which of these filters are supported by ImageMagick natively, and which
> are supported via external helper application?

These are all going through ImageMagick, some need helpers supplied via
ImageMagick, but I am using their interface to read and write the images.

>   I am not sure if a dependency on a helper application would be really
> useful. This applies e.g. for the eps KimageIO reader, which IMHO just
>   calls Ghostscript, like the current EPS QImageIO filter, too
>
Yeah, their EPS stuff allows a few more options than the current KDE
version, mostly with funky PS formats.

> - which formats are read-only, and which are read write?
>
The same as image magick.

> - I would be interested in adding file format specific parameters. E.g. if
> I
> have a vector data format, I would like to be able to specify the
>   intended width and height
>
I am not sure if QImage allows this to happen beyond what the image filter
uses.

> - which external libraries uses your KImageIO filter. E.g I have a SVG
> import filter, which unfortunately needs glib, librsvg and a couple other
>   libs, which make it rather "politically incorrect"
>
I link only to image magick's C++ library.  This in turn pulls in:
-lMagick++ -lWand -lMagick -llcms -ltiff -lfreetype -ljasper -ljpeg -lpng
-ldpstk -ldps -lXext -lXt -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lpthread -lm
-lpthread

>> The big one is the QImageIO regexps to determine the image's format.
>
> - I think at least in QImageIO the file extension should suffice
Not for loading, only for saving.

> - At least in SVG it is rather difficult to find a magic regexp. You can
> more or less decide if you have a XML file, but there is no easy way to
>   extract the magic "<svg>" tag, because it isn't on a fixed possition in
> the file. This applies IMHO for all "text based" graphics format or
> "container based" graphics format (e.g. gzipped SVGs or .svgz files)
Yeah, currently ImageMagick just scans for <svg> in the file, but QImageIO
is limited only to 14bytes.  This is annoying for PhotoCD that uses an
offset of 2048 bytes.

Cheers
    -ian reinhart geiser

[Mosfet-2]

I agree you may want to skip the ones that require external applications for
delegates. I do for MImage. They are big time slow.

[Mosfet-2]

Few more notes on ImageMagick.

On Wednesday 12 January 2005 02:46 pm, Ian Reinhart Geiser wrote:
> Dirk Sch?nberger said:
...snip...
> > - I would be interested in adding file format specific parameters. E.g.
> > if I
> > have a vector data format, I would like to be able to specify the
> >   intended width and height
>
> I am not sure if QImage allows this to happen beyond what the image filter
> uses.
>
...snip...

You can set the size in ImageMagick before you load it, but as you said I am
not sure how you'd specify this w/ Qt.

> > - which external libraries uses your KImageIO filter. E.g I have a SVG
> > import filter, which unfortunately needs glib, librsvg and a couple other
> >   libs, which make it rather "politically incorrect"
>
> I link only to image magick's C++ library.  This in turn pulls in:
> -lMagick++ -lWand -lMagick -llcms -ltiff -lfreetype -ljasper -ljpeg -lpng
> -ldpstk -ldps -lXext -lXt -lSM -lICE -lX11 -lbz2 -lxml2 -lz -lpthread -lm
> -lpthread
>

This is dependent on how you built ImageMagick and what you linked it to.

Also, note that if there is already a KDE KImageIO handler I believe should be
preferred. It will be much more efficent. ImageMagick internally uses a
rather complex 64bpp cache that you translate to Qt 32bpp RGBA scanlines, I
assume by calling something like ExportImagePixels() or iterating through
scanlines. This isn't particularly fast and consumes a lot more memory, (not
only a temporary image, but one that uses 16bpp pixel components at that ;-)

As for mimetype identification. I wrote my own. Better than going through the
entire MagicInfo list, which can be large.

>     -ian reinhart geiser
>
> _______________________________________________
> Kde-graphics-devel mailing list
> Kde-graphics-devel@...
> https://mail.kde.org/mailman/listinfo/kde-graphics-devel

[Dirk Schönberger]

> > I am not sure if QImage allows this to happen beyond what the image
filter
> > uses.
> >
>...snip...

> You can set the size in ImageMagick before you load it, but as you said I
am
> not sure how you'd specify this w/ Qt.

You can specify the size before QImageIO::load, e.g. by specifying QImageIO
parameters

QImageIO iio;
iio.setParameters("width:100;height:100");
QPixmap  pixmap;
iio.setFileName( "vegeburger.bmp" );
if ( image.read() )        // ok
   pixmap = iio.image();  // convert to pixmap

and honor these parameters in the QImageIO handler
About ideas how to extract the information in a QImageIO handler you could
look at http://bugs.kde.org/show_bug.cgi?id=84050

Regards
Dirk

[Mosfet-2]

Okay, that should work.

The only concern I would have is, as I said, native KImageIO handlers still
need to be preferred for the memory/speed reasons I noted. That's the whole
reason I am spending considerable time doing the not-so-fun task of writing a
ton of format handlers for MImage even tho it can natively utilize
ImageMagick >:/ ImageMagick is useful, but I personally believe only as a
fallback and if the slow external decoders aren't used. But that doesn't
really apply to the ones that were listed ;-)

On Wednesday 12 January 2005 05:08 pm, Dirk Sch?nberger wrote:
...snip...

> You can specify the size before QImageIO::load, e.g. by specifying QImageIO
> parameters
>
> QImageIO iio;
> iio.setParameters("width:100;height:100");
> QPixmap  pixmap;
> iio.setFileName( "vegeburger.bmp" );
> if ( image.read() )        // ok
>    pixmap = iio.image();  // convert to pixmap
>
> and honor these parameters in the QImageIO handler
> About ideas how to extract the information in a QImageIO handler you could
> look at http://bugs.kde.org/show_bug.cgi?id=84050
>
> Regards
> Dirk
>
>
>
>
> _______________________________________________
> Kde-graphics-devel mailing list
> Kde-graphics-devel@...
> https://mail.kde.org/mailman/listinfo/kde-graphics-devel

[Dirk Schönberger]

> ton of format handlers for MImage even tho it can natively utilize
> ImageMagick >:/ ImageMagick is useful, but I personally believe only as a
> fallback and if the slow external decoders aren't used. But that doesn't
> really apply to the ones that were listed ;-)

Doe there / should there exist some kind of Quality of Service meachnism?
Basically you should be able to install multiple QImageIO handler for a
given image type, with specification about its quality (internal, external
library , out of process), und it should be able to get the best handler
according to the installed handlers.

Regards
Dirk