Dear James, first of all my apology for replying so late. I needed to do more detailed tests to be sure of my statements.
second, let me reassure you, in case it is necessary, that my mail, and my patch, are not about shortcomings of the Fast Preview. Your Fast Preview is one of the best features ever added to Hugin. A lot of the great responsiveness of Hugin is to your credit. That said, there are parts of Hugin, notably the Loading and the Image Cache, that come *before* the Fast Preview and make the experience less enjoyable than it could be, in my opinion. James Legg wrote: > On Fri, 2009-10-02 at 23:57 -0400, Yuval Levy wrote: >> Hi all, >> >> One thing that bothers me about Hugin is how slow it is in opening the >> fast (pun intended) preview. Start Hugin. Load a project. Click on the >> fast preview icon and wait. Wait. Starr at the status bar with the (not >> yet localized ;-) ) "Loading image:" messages, while one image after the >> other is loaded. And the Ubuntu equivalent of the sandglass trying to >> hypnotize me... let me be clear: The waiting is not for the Fast Preview. It is the same Waiting as when I go to the control points tab and the images are loaded for the first time; or the crop tab; or any tab that shows the images. > This doesn't help me for large projects. I knew there were trade-off. I implemented an aggressive caching policy, to trade off some memory, disk access, battery drain in exchange for user time. My findings are that performance is at least equal to an unpatched version in my test cases. > Big images take a long time to load. Since you do this in the idle loop, > the UI actually gets less responsive. Yes - this is bad design of my implementation. Using a separate, low priority thread; as you and Lukas suggest, would be the right thing to do. Bear in mind that the writer has zero formal training in computer science and is just dipping the toes into C++. I welcome any help / improvement from experts like yourself. The way it is implemented now, I can interrupt the loading of the images during the idle loop after every image. Which, I agree, makes it choppy. When I load TIFF files over the network the choppiness is worse than when I load JPEG files from the local hard disk; and in both cases I would prefer a background thread, a smoother feeling, and the Fast Preview available from the beginning of the loading process with placeholders instead of the actual images, filled progressively. But even the choppiness is less disturbing to me. Usually I start the Hugin GUI loading a project that was previously set up via a batch run on the command line with autooptimiser. It's equivalent to using the Assistant's step 1 and 2. After loading the project, I head out to either the CP-panel to set up vertical control lines because the autooptimiser can not (yet) automatically guess where is up and where is down; or to the Fast Preview (I'm an instant gratification guy, and the Fast Preview is as addictive as sugar for me). In both cases, I have to wait for the Image Cache to do it's job - on two images if I go CP-panel; on all images if I go Fast Preview. Even worse with the CP-panel: when I switch to the next images pair, I have to wait for one additional image to load. This is the kind of time I want to save. My findings are: * for my typical 360°x180° full spherical, six fisheye shots panorama, the aggressive cache loads everything into RAM and clicking through to the next image pair on the CP tab is faster; accessing both the CP tab or the Fast Preview is equally fast or faster than withouth my aggressive caching. * for larger projects that do not fit in memory (2GB on my dynobook, 8GB on my workstation), the CP tab is faster; the Fast Preview will take as much time without the cache. > Ideally, one would solve this problem by loading the images in another > thread with a lower priority. as I said, it is just a proof of concept and a wet toe into C++ - improvements are welcome, and I am sure that a crack like you can get much better performance out of my rough quick and dirty fix. > Another issue I see is that it eats memory. If I load a project where > all the decoded images don't fit into RAM, this makes my whole system > unresponsive as it eventually it starts moving stuff I'm trying to use > to swap memory. While I have experienced that it eats memory, and I expected there to be trade-offs, I've not experienced it that dramatically as you describe below. > If I try to load the fast preview while this is going on, the following > happens: > * The preview gets the first image from the image cache. It is now > loaded, where it wasn't before, saving a file load. > * The preview tries to free up some space, in case there are more > images in the cache than fit the allowed memory. There is, so > the image cache frees most of the images that have been > preloaded. > * The preview tries to get the second image from the image cache. > There is a high probability it was freed by the last step, so it > loads it off the disk again. > * The preview again asks the image if it would like to free some > memory. It is likely to free the image accessed the earliest, > which is another preloaded one. > * ... > So it only saves one file load if left too long to preload images. I "interrupted" the loading at different stages and did not experience that chaos. The Image Cache shows nicely in the status bar what is it at exactly. I've used a 40 images project, and interrupted it at 10; 20; 30; "pre-loaded" images with a click on the Fast Preview button. In all cases, I have counted only 40 changes in the status line, means nothing has been loaded twice. But given how it is implemented I can imagine potential conflicts, it depends a lot on the machine's specs; the project at hand; the user's behavior. Hence I think that it is best: (a) improved with a low priority thread (b) added as a preference - or (c) kept as a private patch. I am currently not proficient enough to do (a), and I don't know how much time it will take. I'd appreciate any help, pointers, guidance. I know the conpcepts, I just lack the practical C++ experience. For the choice between (b) and (c), it is up to the community. I can keep the patch here, and apply it privately to my instance of Hugin. I did publish it here because it may be useful to others; and because I believe that the next thrust of development should go into improving the user interface, making it more responsive and bring it up to par with the Fast Preview. I want fast, predictive pre-loading. I want to use all the memory and all the power that the machine can yield. Others may prefer it to be more economical (and who knows, maybe I'll find myself on battery power and will switch the aggressive caching off too). > I have some suggestions to get around these issues: > 1. Load images in a low priority thread separate to the GUI thread > if possible. yes, please, do! > 2. Load the small images from the small image cache. These are not > freed, as they occupy a small amount of memory each. They are > used in the images tab and the traditional preview. I've tried your patch on my dynobook. It's 1.6GHz 2GB RAM and fast preview is always maximized to occupy the whole 1400x1050 high resolution display. It was actually slower, and I saw on the status bar the Loading and Resizing messages running. My explanation is that even to use the small images, the full sized ones need to be loaded. so resizing is an extra cost. My observations are for both a 6 pictures and a 40 pictures project. I should try with a 300 pictures project but did not have the time. And in best multi-tasking tradition (bad habit!), I tried the 40 pictures project while building Hugin in the background (better leave the machine alone and do other things in the meantime). No problems. > I wrote the fast preview to use the large image cache to create the > textures it uses. This is so that if you are, for instance, just > remapping an equirectangular pano to a little planet, the image is > sharper as it knows it can allocate more texture memory to it. I love the Fast Preview. It is sharp and clear on the 1400x1050 of the dynobook and on the 1920x1200 of the workstation. > We could make the fast preview use the small image cache for the smaller > textures so that the above routine has a better effect on performance of > displaying the fast preview: All the textures could be derived from the > small image cache on a sufficiently large project. I tried your patch and I did not feel any improvement. Because the bottleneck, at least on my settings, is not the Fast Preview. It's disk access to the image files. I welcome any improvement in the cacheing. The current cacheing is very basic and waits for the user to ask for something before providing it. I want a more proactive cacheing, and my patch was just an initial proof of concept. I shared it. It is good enough for me. The question is: should I keep it for myself and those who have downloaded and tried the patch? or should it be made available for everybody, in binary form? How would you feel if I add this as a preference (disabled by default)? Others with more C++ experience than me can improve on it with the low prio thread and smarter caching strategies. 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 -~----------~----~----~----~------~----~------~--~---
