On Sat, Oct 10, 2009 at 09:07:47PM -0400, Yuval Levy wrote:
> ... we'll have to get around this. Lukas suggested a second, lower
> priority thread (in another ML-thread I have yet to answer). The UI
> should be functional / responsive even when the images are not loaded in
> the preview, with placeholders being filled as time passes by.
Really, showing previews should be almost instantaneous. But why
aren't they?
I have a computer running several CPUs at several billions of
operations per second per CPU.
I (the human) can only process about 2 Mpixels at about 1 FPS (unless
they are highly correlated as in a movie).
With 4 bytes per pixel, we're talking about 10Mbytes per second of
throughput to create an almost instantaneous feedback! Should be no
problem with almost 10 billion operations per second available? No?
Waiting minutes for a preview to open is totally unneccesary.
So where does the difference come from? A large project has a
destination resolution of several gigapixels. Several billion pixels!
This is usually stored as jpeg which is CPU intensive to decode.
Or it is stored as a TIFF, which is disk-intensive to load. (*)
The preview however only deals with up to two megapixels of visual
information. Why process billions of pixels when only just over a
million matter?
How can we implement this?
As soon as we get told about an image, we should start off a thread
that decompresses the jpeg, reduces the resolution by half, and caches
the result (on disk!) somewhere. Repeat until the images are very
small. Say less than 64 pixels in both directions. (in JPEG there may
even be shortcuts you can take if you want to just find out the sum of
each 4 adjacent pixels! You can skip decoding all higher-freqency
coefficients)
This should happen just once.
Now, for a preview, a quick calculation will tell you that the two
opposite corners of an image in the preview window lie for example 200
pixels apart. Then grabbing the 256x192 thumbnail for the preview is
going to be adequate.
Similarly, showing the whole image in the control-point editor,
requires only access to a lower-resolution version of the
image. Zooming in to 100%, actually only requires access to PART of
the full image. So even then it could be made unneccesary to decode
the whole 10 megapixels of my camera.
Roger.
(*) the tiffs are so large, we should assume they do not fit into
memory.
--
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
*-- BitWizard writes Linux device drivers for any device you may have! --*
Q: It doesn't work. A: Look buddy, doesn't work is an ambiguous statement.
Does it sit on the couch all day? Is it unemployed? Please be specific!
Define 'it' and what it isn't doing. --------- Adapted from lxrbot FAQ
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at:
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
