Hi Lukáš Lukáš Jirkovský schrieb: > Hi Stefan, > > > Here are my thoughts. Could anyone verify them? > 1. the problem occurs when image cache is disabled or the limit > exceeds (or almost fits almost exatly) memory size > 2. the problem occurs when image cache is enabled but there is not > enough memory to write temporary to disk.
I'm still investigating, but I don't think it has something to do with the image cache. Form what I have seen yet, the way the files are read and written seems to be the main culprit: In my tests, a 1.2 GByte Tiff for the resulting output file is created and accessed in its full size using mmap. This requires 1.2 GBytes of memory allocated to the application. Additional memory is required for every of the source files. And, of course, the application itself will need some memory, too. If physical memory gets tight, the system will start to swap. This leads to the unresponsiveness you mentioned. And in some cases, this swapping leads to thrashing: If the OS permanently is occupied with swapping in / out of pages, not much CPU performance is left over for the application. The effect I noticed is worsened by using MP: There, the memory requirements occur in parallel whereas a nonMP application allocates memory resources sequentially. Therefore, nonMP compiled enblend versions will allow larger output files without breaking. I have enabled the image cache only because I read that it has to be disabled when using OpenMP. I'd like to have a closer look at the image handling functions (which I think are implemented somewhere in the vigra library. If there es a way to switch this from "full size access" (you have the full file accessible at the memory region used for the mmap) to "floating window access" (you only have a certain amount of the file mapped into the memory map of the application), the possible final size of the image would almost be infinite, but requiring only the amount of memory for the window size. Of course, performance would most probably suffer due to the fact that the window has to be shifted into the position required for the next write. It actually may be that I'm on a totally wrong trace. Most information I try to explain here rely on some strace runs of enblend --compression NONE -v --fine-mask --fine-mask \ -w -f12018x6009 -o Village_Hotel.tif \ Village_Hotel0000.tif Village_Hotel0001.tif Village_Hotel0002.tif\ Village_Hotel0003.tif Village_Hotel0004.tif Village_Hotel0005.tif\ Village_Hotel0006.tif Village_Hotel0007.tif Village_Hotel0008.tif\ Village_Hotel0009.tif Village_Hotel0010.tif Village_Hotel0011.tif\ Village_Hotel0012.tif Village_Hotel0013.tif Village_Hotel0014.tif\ Village_Hotel0015.tif Village_Hotel0016.tif Village_Hotel0017.tif\ Village_Hotel0018.tif Village_Hotel0019.tif Village_Hotel0020.tif\ Village_Hotel0024.tif Village_Hotel0025.tif Village_Hotel0026.tif One notable issue may be that the mmap for Village_Hotel.tif is roughly 1.26 GBytes in size on my notebook according to strace, on the desktop with 4GB of memory, where the above command does finish without an error, the size of the final Village_Hotel.tif is only 551MBytes. You see, I will have to keep investigating. If someone else has some insight into this area, I'd be delighted to be corrected or informed. BTW, George, what amount of memory and swap space does your OSX installation have? Did you encounter unresponsiveness, too? Cheers Stefan Peter --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
