hugin-bug-hunters team mailing list archive

[Yuv <681263@xxxxxxxxxxxxxxxxxx>]

On November 26, 2010 05:04:25 am rew wrote:
> Each time I open Hugin, the cache needs to be built. Takes a lot of
> time. Hugin really becomes a hog when you have 40, 100 or 200 images to
> stitch. Things should be cached on offline storage.

Agree for some projects / cases.  Then for others the above would become a hog 
(when storage is limited).

Suggested solution:
* a project setting: "store intermediate pyramid" (Y/N, default N; or default 
set by a preference which defaults to N).
* if a project PROJECT.PTO is set to Y, then create a folder .PROJECT.PTO in 
the same location as the project file, and a Makefile to generate the pyramid 
inside that folder

 importance: wishlist

-- 
preview and fast preview load/scale the images separately. 
https://bugs.launchpad.net/bugs/681263
You received this bug notification because you are a member of Hugin Bug
Hunters, which is subscribed to Hugin.

Status in Hugin - Panorama Tools GUI: Won't Fix

Bug description:
After watching the "fast preview" load the images in the background and slowly updating the preview window, I clicked (normal) "preview panorama", and again was waiting for the images to load. 

The idea should be that the loaded/scaled images should be stored somewhere for the whole project to use. These should be cached across invocations. This will cost some, but not a lot of disk space.

Suggestion: create .s-1_dsc_3021.jpg as the 2x scaled version of dsc_3021.jpg, Create .s-2_dsc_3021.jpg as the 4x scaled version (4x horizontal, 4x vertical, so 16x less pixels). This (usually) means less than 1megapixel images. This should be quick to load, but even the 8x scaled version can be useful in previews(loading even faster). (s-1 stands for scaled to 2^ -1 ). 

When an image is added to a pto, create a Makefile that will scale all the images to their smaller version. Possibly kick off the make in the background. 

Now, in my preview window, the images show up about 200 pixels high. Loading the s-3 versions would suffice and give me an almost-instant preview. 

Design choice to make: Do we store .jpg (smaller), or do we store uncompressed (faster). Personally I'd prefer the jpgs: The smaller jpgs are so small they load almost instantly anyway. On larger panos, the individual images will be shown so small that you can even use s-3, s-4 or s-5 images. The preview windows should become smart enough to only load the appropriately scaled image.

design choice to make: Hide the scaled images in the current dir, or unhidden in a (hidden) subdir?

Todo: make "autopano-sift-c" and its friends skip the scaling step because hugin has done it already. Just run it on the appropriately scaled image (about 700 pixels in the largest side, 500-1000 pixels on the largest side will do, there is always a scaled image in this range).