Some information can be found in the README file within the distribution. You should read the REMARKS file about format and site specific code settings.

            $> ./configure
            $> make
            $> sudo make install

This will install to /usr/local/xmedcon; without messing up any system directories. You 'll have to make sure the shared library ($LD_LIBRARY_PATH) and executables ($PATH) can be found.

If you prefer to install into a system directory, you could run for example:

            $> ./configure --prefix=/usr/local
            $> make
            $> sudo make install

<<Index>>

* What to do with problems?

Send your e-mail to enlf(at)users.sourceforge.net

<<Index>>

* Why (X)MedCon?

As a novice system administrator on a nuclear medicine site in the nineties, we spended some time in the search for that specific tool to do this proper conversion between those formats. Hey, at the time we needed other things to read/learn/edit/configure/debug/install/patch/hack/tune/play. With proper we mean: conversion between commonly used formats in (freely available) research tools, while preserving valuable medical parameters like patient information, slice orientation, voxel dimension or pixel quantitation.

After trying some utilities we decided we would be better off writing things ourselves in order to meet our requirements. At the same time, the world wide web helped us tremendously in our network administration tasks through the availability of profound documentation and handy tools. We felt we owed the web, therefore the time came to give something back to this Internet community.

We hereby hope to lower the conversion barrier in many research projects.

<<Index>>

*Can (X)MedCon convert my vendor 's format?

No. And we don't want to. Our focus is on conversion between widely used medical formats. Today many vendors are capable of DICOM exchange. If not, perhaps (X)MedCon can assist as in between. When you haven't heard of the dicom3tools yet, then you should take a visit at David Clunie's site for more vendor specific conversions.

<<Index>>

*Can (X)MedCon do backwards conversion?

If all you need to do is going from point A to B and then come back to A, you 'd better stay in A. Always preserve your original image format. Ofcourse, a reconversion is possible but even between the small number of formats (X)MedCon supports, no two formats have a one to one relation. In the cases where a backwards conversion is necessary you should consider that each conversion will result in the loss of information. Here are a few examples of format incompatibilities:

	Dicom 3	AcrNema 2.0	InterFile 3.3	Analyze(SPM)	ECAT
centre-centre slice separation	yes	yes	yes	no	no
quantitation factors	slope & intercept	one global	none	one global	two for each image
slice thickness	yes	yes	TOMO only	yes	yes
different time frames	yes (PT)	no	planar only	yes	yes
modality distinction	yes	yes	yes	no	yes
patient name	yes	yes	yes	no	yes

Tabel 1.: (un)available features for most common formats.

<<Index>>

* How come (X)MedCon's GUI is based on Gtk+?

On a historical note: We were all too lucky to be surrounded by a pack of UNIX machines (Digital, SUN, HP, IBM, ...) on which we did the initial development and porting of our command-line utility. The use of reputable Xv had some serious limitations. So we were looking for a way to display images ourselves. On proprietary UNIX machines this required learning something like Xlib or Motif. A first glance at a daunting X Window System version of "Hello World" discouraged us immediately. No way we were going to type all that! In our search for an easier way to deal with image display we came across the Gtk+ toolkit and its promising specifications: C, free, open and ported. After the easy unpack, configure, make, install sequence, running the 'testgtk' program was a true revelation. Displaying images wasn't that simple yet. Here the formerly used GdkImlib library written by Rasterman was our saviour in need. In less than three days we got a working GUI front-end without any previous knowledge of X-programming, rendering nor callbacks. That still speaks for the *lousy & leaky* code. ;)

The use of the open source Gtk+ toolkit is / was a true blessing: others are porting your code. Gtk+ is available on every Linux distribution. But the best proof however was the amazing GtkWin port (originally done by Tor Lillqvist) which enabled us to compile our UNIX utility on to the widespread Windows platform at a "minimum" of efforts. Ofcourse, our previous decision to use the widespread and free GNU C compiler on any *nix flavour at our disposal, made this transition ever so smooth.

Nowadays ranting: the tedious API changes between or during Gtk+1 (superb) -> Gtk+2 (oké, made it more or less) -> Gtk+3 (deprecation hurdles) -> Gtk4 (bloody hell) introducing ever more dependencies and deprecated functions upon deprecated functions without any documentation on how to properly replace, doesn't speak for Gtk lasting usage by free time developers ...

<<Index>>