gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] artwork handling


From: Sebastian Hilbert
Subject: Re: [Gnumed-devel] artwork handling
Date: Sun, 20 Mar 2005 06:27:53 +0100 (MET)

> Sorry, some clarification needed.
> 
> With images, do we have to contend with the *image* format and the 
> *file* format as well as whether or not a file may contain multiple 
> images?
I don't know what you men by image format vs. file format.
What I mean is:

GNUmed uses icons. These icons can either be *.png images (any directly
supported by wxwidgets directly) or a *.png image converted to a *.py file
by img2py.

If one chooses im2py it is possible to compile libraries of images into one
file. So one *.py file can hold many images. One can combine/split *.py
files at will.

What is lacking (to my knowledge) is a tool that tells you what (how many,
what do they look like, what resolution etc.) images are stored in one *.py
file. 

The only way to find out is to open the file and count or extract single
images and display them seperately.

What I am looking for it some simple graphical user interface that opens a
*.py file. and displays all images in it. It then should let you choose
which which images you want to use (that means it gives you the name of the
function to that image in the *.py file)

Later on it should support exctracting/adding images to this *.py file.

The problem right now is that it is too hard for me to find out which icons
exist already in one of the various *.py file we have in CVS. So if I need 
one I just get one from the net and build my own *.py file from it. This
essentially sucks.  

> 
> Do the same questions need to be addressed for both artwork and 
> actual patient-related images?
I think not. I would store patient images in its original file format in the
database. Much like we do it with archive content right now.
This preserves exif information (date, rotation, shutter speed) from digital
cameras I hope.

 IS the difference only a question of 
> whether the image information is stored (patient-related images in 
> clinical tables, other images in non-clinical tables).
No.
> 
> Can the tables for both needs (clinical and nonclinical) be 
> identified for this thread, to assist the wiki?
Yes. I hope so. Not by me unfortunately.
> 
> >Any media is proposed to be centrally stored in the existing CVS 
> >folder "artwork"
> 
> In what form... that us one of the questions, yes?
Yes.

> - original image and file format?
Yes.
> - original image format, but imported into a python file (?) - is 
> that what is done by img2py or does this change the image format (or 
> both)
Absolutely

> 
> >Once they are there, we will need to either
> >- use a tool able to display content of a *.py file for files that 
> >handle multiple images
> the "tool able to display content of a *.py file " - does a suitable one
> exist?
None that I know of. Can I say mini project (no Gnumed knowledge needed)
All you need is beginner python skills. Use BOA constructor and you could
come up with a usable version within one weekend.

> the word "handles" in "files that handle multiple images" - it means 
> "contains"?
Correct.
> 
> >or
> >- handle known graphics types directly.
No.
> 
> Do wxwidgets, wxpython, python and Postgres permit this?
Postgres doesn't care. wxwidgets/wxpython supports a selection of image
types directly.
> 

Excellent questions. Any takers for such a tool? :-)

-- 
*************************************************************************
*
* help solving the protein folding problem
foldingathome.stanford.edu   
*          
* sign the linux driver petion :
http://www.libranet.com/petition.html
*
*************************************************************************

"Happy ProMail" bis 24. März: http://www.gmx.net/de/go/promail
Zum 6. Geburtstag gibt's GMX ProMail jetzt 66 Tage kostenlos!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]