Image Editing slow in Fedora

[Nifty Hat Mitch]

On Fri, Sep 03, 2004 at 12:25:02PM +0000, Jon Shorie wrote:
> On Friday 03 September 2004 07:06, Alexander Apprich wrote: 
> <a.apprich at science-computing.de>
> > Jon,
> >
> > Jon Shorie wrote:
> > > We have some 300 dpi 24x36" greyscale scans of some of our plans.  I am
> > > looking for an image editor that works with linux that is reasonably
> > > quick for working with these images.  The fiels are saved as a tif image
> > > and are about 4 mb in size.
> > >
> > > When I load one of them into gimp, it balloons to about 90mb in size and
...
> > what are your system specs?? FC1 or FC2, which kernel...
> 
> Athlon Thunderbird 1400 512MB Ram.  ATI Radeon 7000 AGP Video Card.
....
> I did try a few more things since posting this question.  I upgraded the 
> memory to 768 mb and adjusted the preferences ...
....
> This seemed to improve matters somewhat, but it still a lot slower than 
> windoze imaging on my windoze box which only has  Athlon Duron 600 512MB 
....
> confidential removed.  I can post it as an attachment, but the size
> of the file is 2.8 mb.
...
> I am also wondering if anyone has any idea why gimp shows the size
> as 300mb internally when the file itself is only 2.8mb.  Any help
> would be greatly appreciated.  

Last part first ... I downloaded your image 
    ..../00015-2.tif
It appears to have its second half munged but
that does not hurt the header.

I inspected it with a tiff tool...
$ tiffinfo  00015-2.tif
....
Image Width: 10800 Image Length: 7221 and 

So some arithmetic...

    10800*7221=77986800pixels

This tells me that the image really is ~78MB (B&W) in size. It
compresses from 78MB to 2.4MB because it is black and white (little
grey) with large regions of white or black (same repeating value easy
to compress).

Now some speculation begins....  If you toss a ~78MB black and white
image at a color screen with millions of colors (24 bit RGB) that
memory footprint might triple (like 3x78MB=233MB) depending on how the
application and X-server elects to manage things.

It seems that "gqview" is smarter about the memory + display
and gives me a quicker look.  Eye of Gnome (eog) is also quicker
try them both.

Things to play with.

       * detune the display to use a small number of colors.
	 yes, as few as  256 if you can.  Not a problem if
	 you are looking at B&W...
       * use a display driver without 3D acceleration.
	 pixel mashing and 3D gfx are in conflict.
       * test the opensource drivers for the gfx card.
       * test the closed source driver for this gfx card.

I am not sure how WindowZ manages the image in memory.  It could be that
they directly render in a clipped region of display memory. i.e. they
only render what you see.

What application are you using on WindowZ to look at this image?

Gimp expect that you will spray paint a layer over the image with all
the colors or the rainbow.... i.e. it is really working RGB at one
level so B&W is as fast as RGB24.

It seems to me that a number of companies are scanning documents for
archival storage.  There could be a market for B&W tools focused at
this task.


-- 
	T o m  M i t c h e l l 
	Just say no to 74LS73 in 2004