| George Peter Staplin 2006-06-28, 7:03 pm |
| MartinLemburg@UGS wrote:
> Hello,
>
> following problem ...
>
> * we have scanned diagramms we need to digitalize to get the curves on
> this diagramms
> * this diagramms are up to DIN A0 size and so image files are big
> (TIFF, G4, up to 16000x9000 pixels)
>
> I wanted to load the images into Tk, to place them on a canvas and to
> allow the user (us) to point and click on important points of the
> diagramm to get the curve. I wanted this procedure, because I have no
> knowledge about image processing and finding "clouds" of black pixels
> on a white background, that please the rule to be a cross on the
> diagramm curve.
>
> The problem is now, that Tk or Img starts loading the image files, but
> even after hours its not finished and I expect that the Tk application
> (later a starpack) would need too much memory, and would be too slow to
> work with.
> Even loading the image as PBM (now 16MB big) or as PPM (now 414MB big)
> failed through the size. So it would be even impossible to digitalize
> it using algoriths not visualizing it.
$ tclsh8.4
% 16000 * 9000 * 4
576000000
% $that / pow(2,20)
549.31640625
549 MB of RAM just for a single 4 byte RGBA buffer of that size.
So you're going to need at *least* that much memory for such images.
I'd guess about twice of that or more wouldn't be uncommon.
The way the photo subsystem works is that a 32-bit RGBA buffer is
created for every image. Then the instances are dithered for the
display depth from what I understand. So that's another copy of the
image data stored in a Pixmap.
> Any idea to handle it with tcl/Tk?
Use my megaimage and megaimagetk stub-enabled extensions. You can
create a megaimage object, and another blank megaimage object, and then
clipcopy between them. You could then use the previously blank
megaimage object for display with a [megaimage.frame] or
[megaimage.to.photo] or [megaimage.put.on.photo].
Megaimage is over 3 times faster than photo in my image manipulation
tests. Megaimagetk (which currently needs a Windows port
maintainer/developer) is so much faster at image display with the
megaimage.frame widget that it doesn't even compare to the slow
performance of photo/Tk. It uses a runtime attempt of an XShmPutImage
(shared memory transport), or the alternative much slower XPutImage
(that Tk uses) if that fails. It also uses DBE for smooth
double-buffering.
Megaimage runs in a plain tclsh without any display requirement.
Another Tcl extension called pngext2 provides the necessary PNG
read/write capabilities, and it's fairly easy to create an image
handler. Each image handler just creates a megaimage_shared struct
followed by the image bytes. If you're interested in contracting me to
write an image handler for TIFF, or would like some pointers let me
know.
The latest code as of today is here:
http://www.xmission.com/~georgeps/i...pkg-410.tar.bz2
Regards,
George
|