Rogier Wolff wrote: > Really, showing previews should be almost instantaneous. But why > aren't they?
now this one was an excellent piece of analysis. I agree 100%. > As soon as we get told about an image, we should start off this is what I tried to approximate with my primitive use of the idle time (assuming that immediately after loading an image the software goes in idle mode, which is where modern CPU spend most of their time) > a thread a separate thread would be more efficient indeed. > 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. this is a very interesting strategy. disk space is cheap nowadays and does not suffer the addressing limitations of RAM. however we can't assume that disk space is unlimited, especially when people work with very large projects. And we need to leave enough disk space for later stages of the process (enblend). So add to it some disk space calculations to prevent errors like "could not write to file". also, aren't there intermediate image formats that are faster to load from disk into memory than TIFF and JPEG? that said, caching on disk the images, even at full resolution, would be very helpful to me. I often stitch from a network drive just because I am too lazy to copy the files from the network drive to the local drive and back (and because the local drive is not backed up like the network drive is). for the resolution scaling, wouldn't it make sense to go powers of two from the initial scaling? > 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. I love this kind of thinking; and I hope that one of our student turned master wizards on this list will pick up on it and make it come true. Yuv --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
