OpenGL slow because of reloading [was: hugin-0.8.0_beta3 released]

View: New views
7 Messages — Rating Filter:   Alert me  
< Prev | 1 - 2 - 3 | Next >

Re: OpenGL slow because of reloading

by RueiKe :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


I have just tried out SVN 3929 on a large project with 161 images and
~12k control points.  I found that image reloading was improved for
the images tab.  When I selected Align from the assistant tab, I found
that during the "Leveling the Panorama" stage, hugin was reading in
every image.  When it was done reading all of the images, it started
to read them in again, and gave an unhandled exception fault.  Hugin
memory usage in this test was 1.6GB, which is more than what I have
seen in the past.

Regards,
Rick

On Jun 10, 5:05 am, David Haberthür <david.haberth...@...>
wrote:

> Hello Guido.
>
> On 09.06.2009, at 22:38, Guido Kohlmeyer wrote:
>
>
>
> > The additional option is only a workaround that may work, but as you
> > already percieved it will yield to higher memory consumption to  
> > generate
> > the mask in a higher resolution.
> > I guess the process runs out of memory.
>
> > Guido
>
> I suppose that must be the problem, since it crashes with the same  
> complaint in the logfile:
> ----
> DSC_24160117.tif DSC_2284-DSC_24160118.tif DSC_2284-DSC_24160119.tif  
> DSC_2284-DSC_24160120.tif DSC_2284-DSC_24160121.tif DSC_2284-
> DSC_24160122.tif
> enblend(815) malloc: *** mmap(size=2097152) failed (error code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> enblend(815) malloc: *** mmap(size=2097152) failed (error code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> enblend(815) malloc: *** mmap(size=2097152) failed (error code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> enblend(815) malloc: *** mmap(size=2097152) failed (error code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> terminate called recursively
> gnumake: *** [DSC_2284-DSC_2416.png] Abort trap
> gnumake: *** Deleting file `DSC_2284-DSC_2416.png'
> ---
> even for the newest build from Harry (0.0.0-svn3923)
> I guess I'll have to try at work, on a machine with 16 GB of RAM and  
> not on my puny laptop with 2GB :)
> Habi
>
> David Haberthür schrieb:
>
>
>
> >> Dear Guido,
> >> That only helped a bit, now enblend crashes lateron in the process.
> >> The relevant lines of the stitching window are below:
>
> >> ---
> >> DSC_2284-DSC_24160114.tif DSC_2284-DSC_24160115.tif
> >> DSC_2284-DSC_24160116.tif DSC_2284-DSC_24160117.tif
> >> DSC_2284-DSC_24160118.tif DSC_2284-DSC_24160119.tif
> >> DSC_2284-DSC_24160120.tif DSC_2284-DSC_24160121.tif
> >> DSC_2284-DSC_24160122.tif
> >> enblend(5937) malloc: *** mmap(size=2097152) failed (error code=12)
> >> *** error: can't allocate region
> >> *** set a breakpoint in malloc_error_break to debug
> >> enblend(5937) malloc: *** mmap(size=2097152) failed (error code=12)
> >> *** error: can't allocate region
> >> *** set a breakpoint in malloc_error_break to debug
> >> enblend(5937) malloc: *** mmap(size=2097152) failed (error code=12)
> >> *** error: can't allocate region
> >> *** set a breakpoint in malloc_error_break to debug
> >> enblend(5937) malloc: *** mmap(size=2097152) failed (error code=12)
> >> *** error: can't allocate region
> >> *** set a breakpoint in malloc_error_break to debug
> >> terminate called recursively
> >> gnumake: *** [DSC_2284-DSC_2416.png] Abort trap
> >> gnumake: *** Deleting file `DSC_2284-DSC_2416.png'
> >> ---
> >> using hugin svn-3888, will try tomorrow with harrys freshly  
> >> compiled rc3.
> >> have a good night.
> >> habi/david
>
> >>> David Haberthür schrieb:
>
> >>>> On 07.06.2009, at 18:45, Harry van der Wolf wrote:
>
> >>>>> 2009/6/5 David Haberthür <david.haberth...@...
> >>>>> <mailto:david.haberth...@...>
> >>>>> <mailto:david.haberth...@...>>
>
> >>>>>   i could help with providing a test-case, the panorama i shot  
> >>>>> last
> >>>>>   saturday evening [1] contains +100 images and +7000 control  
> >>>>> points
> >>>>>   generated with pan-o-matic. i'm still struggling with  
> >>>>> stitching it
> >>>>>   with full resolution, somehow i chokes at the fusing-step when
> >>>>> trying
> >>>>>   to stitch it in sizes bigger than 10000px wide, now i've  
> >>>>> stitched it
> >>>>>   in "only" 2694 x 635 px (os x, with harrys newest svn-builld).
>
> >>>>> Hi Habi,
>
> >>>>> Nice pano.
> >>>>> You are saying that it chokes on 10000px wide (10000 by ?).
> >>>>> What error message do you get?
>
> >>>>> Harry
>
> >>>> Hoi Harry.
> >>>> Thanks, i've tried to make a night-version of the panorama i've  
> >>>> shot
> >>>> some weeks ago.
> >>>> I've failed to thorougly investivate it, but the panorama fails to
> >>>> stitch for sizes 10000x4122 and 12000x4946 px. It actually fails  
> >>>> with
> >>>> an enblend warning:
> >>>> "enblend: warning: failed to detect any seam
> >>>> enblend: mask is entirely black, but white image was not  
> >>>> identified as
> >>>> redundant
> >>>> gnumake: *** [DSC_2284-DSC2416.png] Error 1"
> >>>> are the last entries in the log window. The complete log is  
> >>>> attached
> >>>> to this mail as "log.txt"
>
> >>>> I'm a bit confused, since the stitch to the smaller size worked
> >>>> without a hitch...
> >>>> Have a nice start into the week.
> >>>> Habi
> >>>> ---
>
> >>>> ------------------------------------------------------------------------- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by Harry van der Wolf-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Habi,

(I missed these posts, so I kick in a little late).

It is not a problem of your laptop. George Row experiences exactly the same problems with large panorama's. It has to do with the way OSXes malloc badly deals with memory.
That's also why I built a Hugin version against dmalloc instead of OSXes malloc. Unfortunately that didn't help George and probably won't help you either.

I assume you are on a dual-core Intel macbook. That's a 64 bit machine. You might give the older 0.7 final version a go. It's a 64bit version and that might help but ONLY on Leopard. It didn't help George as George also used masks in his tiff's which was another reason for enblend to crash (and that's why I built a hugin with the latest enblend from Christoph Spiel that has much better mask handling, but that one crashed again on the malloc allocation error.)


Harry

2009/6/9 David Haberthür <david.haberthuer@...>

Hello Guido.

On 09.06.2009, at 22:38, Guido Kohlmeyer wrote:

>
> The additional option is only a workaround that may work, but as you
> already percieved it will yield to higher memory consumption to
> generate
> the mask in a higher resolution.
> I guess the process runs out of memory.
>
> Guido
>

I suppose that must be the problem, since it crashes with the same
complaint in the logfile:
----
DSC_24160117.tif DSC_2284-DSC_24160118.tif DSC_2284-DSC_24160119.tif
DSC_2284-DSC_24160120.tif DSC_2284-DSC_24160121.tif DSC_2284-
DSC_24160122.tif
enblend(815) malloc: *** mmap(size=2097152) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
enblend(815) malloc: *** mmap(size=2097152) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
enblend(815) malloc: *** mmap(size=2097152) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
enblend(815) malloc: *** mmap(size=2097152) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
terminate called recursively
gnumake: *** [DSC_2284-DSC_2416.png] Abort trap
gnumake: *** Deleting file `DSC_2284-DSC_2416.png'
---
even for the newest build from Harry (0.0.0-svn3923)
I guess I'll have to try at work, on a machine with 16 GB of RAM and
not on my puny laptop with 2GB :)
Habi

David Haberthür schrieb:
>> Dear Guido,
>> That only helped a bit, now enblend crashes lateron in the process.
>> The relevant lines of the stitching window are below:
>>
>> ---
>> DSC_2284-DSC_24160114.tif DSC_2284-DSC_24160115.tif
>> DSC_2284-DSC_24160116.tif DSC_2284-DSC_24160117.tif
>> DSC_2284-DSC_24160118.tif DSC_2284-DSC_24160119.tif
>> DSC_2284-DSC_24160120.tif DSC_2284-DSC_24160121.tif
>> DSC_2284-DSC_24160122.tif
>> enblend(5937) malloc: *** mmap(size=2097152) failed (error code=12)
>> *** error: can't allocate region
>> *** set a breakpoint in malloc_error_break to debug
>> enblend(5937) malloc: *** mmap(size=2097152) failed (error code=12)
>> *** error: can't allocate region
>> *** set a breakpoint in malloc_error_break to debug
>> enblend(5937) malloc: *** mmap(size=2097152) failed (error code=12)
>> *** error: can't allocate region
>> *** set a breakpoint in malloc_error_break to debug
>> enblend(5937) malloc: *** mmap(size=2097152) failed (error code=12)
>> *** error: can't allocate region
>> *** set a breakpoint in malloc_error_break to debug
>> terminate called recursively
>> gnumake: *** [DSC_2284-DSC_2416.png] Abort trap
>> gnumake: *** Deleting file `DSC_2284-DSC_2416.png'
>> ---
>> using hugin svn-3888, will try tomorrow with harrys freshly
>> compiled rc3.
>> have a good night.
>> habi/david
>>
>>>
>>>
>>> David Haberthür schrieb:
>>>>
>>>> On 07.06.2009, at 18:45, Harry van der Wolf wrote:
>>>>
>>>>>
>>>>>
>>>>> 2009/6/5 David Haberthür <david.haberthuer@...
>>>>> <mailto:david.haberthuer@...>
>>>>> <mailto:david.haberthuer@...>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>   i could help with providing a test-case, the panorama i shot
>>>>> last
>>>>>   saturday evening [1] contains +100 images and +7000 control
>>>>> points
>>>>>   generated with pan-o-matic. i'm still struggling with
>>>>> stitching it
>>>>>   with full resolution, somehow i chokes at the fusing-step when
>>>>> trying
>>>>>   to stitch it in sizes bigger than 10000px wide, now i've
>>>>> stitched it
>>>>>   in "only" 2694 x 635 px (os x, with harrys newest svn-builld).
>>>>>
>>>>>
>>>>> Hi Habi,
>>>>>
>>>>> Nice pano.
>>>>> You are saying that it chokes on 10000px wide (10000 by ?).
>>>>> What error message do you get?
>>>>>
>>>>> Harry
>>>>
>>>> Hoi Harry.
>>>> Thanks, i've tried to make a night-version of the panorama i've
>>>> shot
>>>> some weeks ago.
>>>> I've failed to thorougly investivate it, but the panorama fails to
>>>> stitch for sizes 10000x4122 and 12000x4946 px. It actually fails
>>>> with
>>>> an enblend warning:
>>>> "enblend: warning: failed to detect any seam
>>>> enblend: mask is entirely black, but white image was not
>>>> identified as
>>>> redundant
>>>> gnumake: *** [DSC_2284-DSC2416.png] Error 1"
>>>> are the last entries in the log window. The complete log is
>>>> attached
>>>> to this mail as "log.txt"
>>>>
>>>> I'm a bit confused, since the stitch to the smaller size worked
>>>> without a hitch...
>>>> Have a nice start into the week.
>>>> Habi
>>>> ---
>>>>
>>>> ------------------------------------------------------------------------
>>>>
>>>>
>>>
>>>
>>>
>>>
>>
>>
>>>
>
>
> >





--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To post to this group, send email to hugin-ptx@...
To unsubscribe from this group, send email to hugin-ptx+unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx?hl=en
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by RueiKe :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


I am still using SVN3811 due to align crash issues, so maybe this
image loading problem has been fixed in later builds, but this is
something I have just discovered.  I am working with a large project
that includes 125 images which includes 5 shot brackets.  The project
aligned with no problem and I had stitched a low resolution trial
image.  The sky was a bit over exposed so I decided to remove the most
exposed shots from each bracket.  With the Quick Preview screen
displayed, I chose 10 images from hugin's "Images" tab and selected
"Remove Selected Images".  It then started reloading images.  I then
went to work and came home 5 hours later to find it still actively
reloading images with no indications of any errors.  It was still
actively loading from files on disk.  It appeared to be stuck in a
loop.

Regards,
Rick

On Jun 13, 12:34 am, Harry van der Wolf <hvdw...@...> wrote:

> Hi Habi,
>
> (I missed these posts, so I kick in a little late).
>
> It is not a problem of your laptop. George Row experiences exactly the same
> problems with large panorama's. It has to do with the way OSXes malloc badly
> deals with memory.
> That's also why I built a Hugin version against dmalloc instead of OSXes
> malloc. Unfortunately that didn't help George and probably won't help you
> either.
>
> I assume you are on a dual-core Intel macbook. That's a 64 bit machine. You
> might give the older 0.7 final version a go. It's a 64bit version and that
> might help but ONLY on Leopard. It didn't help George as George also used
> masks in his tiff's which was another reason for enblend to crash (and
> that's why I built a hugin with the latest enblend from Christoph Spiel that
> has much better mask handling, but that one crashed again on the malloc
> allocation error.)
>
> Harry
>
> 2009/6/9 David Haberthür <david.haberth...@...>
>
>
>
>
>
> > Hello Guido.
>
> > On 09.06.2009, at 22:38, Guido Kohlmeyer wrote:
>
> > > The additional option is only a workaround that may work, but as you
> > > already percieved it will yield to higher memory consumption to
> > > generate
> > > the mask in a higher resolution.
> > > I guess the process runs out of memory.
>
> > > Guido
>
> > I suppose that must be the problem, since it crashes with the same
> > complaint in the logfile:
> > ----
> > DSC_24160117.tif DSC_2284-DSC_24160118.tif DSC_2284-DSC_24160119.tif
> > DSC_2284-DSC_24160120.tif DSC_2284-DSC_24160121.tif DSC_2284-
> > DSC_24160122.tif
> > enblend(815) malloc: *** mmap(size=2097152) failed (error code=12)
> > *** error: can't allocate region
> > *** set a breakpoint in malloc_error_break to debug
> > enblend(815) malloc: *** mmap(size=2097152) failed (error code=12)
> > *** error: can't allocate region
> > *** set a breakpoint in malloc_error_break to debug
> > enblend(815) malloc: *** mmap(size=2097152) failed (error code=12)
> > *** error: can't allocate region
> > *** set a breakpoint in malloc_error_break to debug
> > enblend(815) malloc: *** mmap(size=2097152) failed (error code=12)
> > *** error: can't allocate region
> > *** set a breakpoint in malloc_error_break to debug
> > terminate called recursively
> > gnumake: *** [DSC_2284-DSC_2416.png] Abort trap
> > gnumake: *** Deleting file `DSC_2284-DSC_2416.png'
> > ---
> > even for the newest build from Harry (0.0.0-svn3923)
> > I guess I'll have to try at work, on a machine with 16 GB of RAM and
> > not on my puny laptop with 2GB :)
> > Habi
>
> > David Haberthür schrieb:
> > >> Dear Guido,
> > >> That only helped a bit, now enblend crashes lateron in the process.
> > >> The relevant lines of the stitching window are below:
>
> > >> ---
> > >> DSC_2284-DSC_24160114.tif DSC_2284-DSC_24160115.tif
> > >> DSC_2284-DSC_24160116.tif DSC_2284-DSC_24160117.tif
> > >> DSC_2284-DSC_24160118.tif DSC_2284-DSC_24160119.tif
> > >> DSC_2284-DSC_24160120.tif DSC_2284-DSC_24160121.tif
> > >> DSC_2284-DSC_24160122.tif
> > >> enblend(5937) malloc: *** mmap(size=2097152) failed (error code=12)
> > >> *** error: can't allocate region
> > >> *** set a breakpoint in malloc_error_break to debug
> > >> enblend(5937) malloc: *** mmap(size=2097152) failed (error code=12)
> > >> *** error: can't allocate region
> > >> *** set a breakpoint in malloc_error_break to debug
> > >> enblend(5937) malloc: *** mmap(size=2097152) failed (error code=12)
> > >> *** error: can't allocate region
> > >> *** set a breakpoint in malloc_error_break to debug
> > >> enblend(5937) malloc: *** mmap(size=2097152) failed (error code=12)
> > >> *** error: can't allocate region
> > >> *** set a breakpoint in malloc_error_break to debug
> > >> terminate called recursively
> > >> gnumake: *** [DSC_2284-DSC_2416.png] Abort trap
> > >> gnumake: *** Deleting file `DSC_2284-DSC_2416.png'
> > >> ---
> > >> using hugin svn-3888, will try tomorrow with harrys freshly
> > >> compiled rc3.
> > >> have a good night.
> > >> habi/david
>
> > >>> David Haberthür schrieb:
>
> > >>>> On 07.06.2009, at 18:45, Harry van der Wolf wrote:
>
> > >>>>> 2009/6/5 David Haberthür <david.haberth...@...
> > >>>>> <mailto:david.haberth...@...>
> > >>>>> <mailto:david.haberth...@...>>
>
> > >>>>>   i could help with providing a test-case, the panorama i shot
> > >>>>> last
> > >>>>>   saturday evening [1] contains +100 images and +7000 control
> > >>>>> points
> > >>>>>   generated with pan-o-matic. i'm still struggling with
> > >>>>> stitching it
> > >>>>>   with full resolution, somehow i chokes at the fusing-step when
> > >>>>> trying
> > >>>>>   to stitch it in sizes bigger than 10000px wide, now i've
> > >>>>> stitched it
> > >>>>>   in "only" 2694 x 635 px (os x, with harrys newest svn-builld).
>
> > >>>>> Hi Habi,
>
> > >>>>> Nice pano.
> > >>>>> You are saying that it chokes on 10000px wide (10000 by ?).
> > >>>>> What error message do you get?
>
> > >>>>> Harry
>
> > >>>> Hoi Harry.
> > >>>> Thanks, i've tried to make a night-version of the panorama i've
> > >>>> shot
> > >>>> some weeks ago.
> > >>>> I've failed to thorougly investivate it, but the panorama fails to
> > >>>> stitch for sizes 10000x4122 and 12000x4946 px. It actually fails
> > >>>> with
> > >>>> an enblend warning:
> > >>>> "enblend: warning: failed to detect any seam
> > >>>> enblend: mask is entirely black, but white image was not
> > >>>> identified as
> > >>>> redundant
> > >>>> gnumake: *** [DSC_2284-DSC2416.png] Error 1"
> > >>>> are the last entries in the log window. The complete log is
> > >>>> attached
> > >>>> to this mail as "log.txt"
>
> > >>>> I'm a bit confused, since the stitch to the smaller size worked
> > >>>> without a hitch...
> > >>>> Have a nice start into the week.
> > >>>> Habi
> > >>>> ---
>
> > ------------------------------------------------------------------------- Hide quoted text -
>
> - Show quoted text -
--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by David Haberthür-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


On 07.06.2009, at 18:45, Harry van der Wolf wrote:



2009/6/5 David Haberthür <david.haberthuer@...>



i could help with providing a test-case, the panorama i shot last
saturday evening [1] contains +100 images and +7000 control points
generated with pan-o-matic. i'm still struggling with stitching it
with full resolution, somehow i chokes at the fusing-step when trying
to stitch it in sizes bigger than 10000px wide, now i've stitched it
in "only" 2694 x 635 px (os x, with harrys newest svn-builld).

Hi Habi,

Nice pano.
You are saying that it chokes on 10000px wide (10000 by ?).
What error message do you get?

Harry 

Dear all.
I'm happy to say that  with hugin 0.8.0-RC5 I no longer have the problem with this panorama it stitched fine (with a size of 17806x4346, albeit it took approximately 5 hours to render :)
Thanks for all the effort of all involved people!
Habi



--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by Guido Kohlmeyer :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Dear David,

regarding your comment "albeit it took approximately 5 hours to render", I
expect you can speed up the calculation with more RAM. After upgrade my
machine from 512MB to 2GB RAM the process was very quick compared to the
less RAM configuration, especially enblend benefits from lot of free
memory.
My panos are commonly 14000x7000px built from about 32 pictures in
eqirectangular projection. The enblend step needs about 1.5 to 1.7GB RAM
to run quickly, otherwise enblend goes to disk with slows down the
process.

Guido

>
> On 07.06.2009, at 18:45, Harry van der Wolf wrote:
>
>>
>>
>> 2009/6/5 David Haberthür <david.haberthuer@...>
>>
>>
>>
>> i could help with providing a test-case, the panorama i shot last
>> saturday evening [1] contains +100 images and +7000 control points
>> generated with pan-o-matic. i'm still struggling with stitching it
>> with full resolution, somehow i chokes at the fusing-step when trying
>> to stitch it in sizes bigger than 10000px wide, now i've stitched it
>> in "only" 2694 x 635 px (os x, with harrys newest svn-builld).
>>
>> Hi Habi,
>>
>> Nice pano.
>> You are saying that it chokes on 10000px wide (10000 by ?).
>> What error message do you get?
>>
>> Harry
>
> Dear all.
> I'm happy to say that  with hugin 0.8.0-RC5 I no longer have the
> problem with this panorama it stitched fine (with a size of
> 17806x4346, albeit it took approximately 5 hours to render :)
> Thanks for all the effort of all involved people!
> Habi
>
>
>
> >
>



--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by David Haberthür-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message


Dear Guido

> regarding your comment "albeit it took approximately 5 hours to  
> render", I
> expect you can speed up the calculation with more RAM. After upgrade  
> my
> machine from 512MB to 2GB RAM the process was very quick compared to  
> the
> less RAM configuration, especially enblend benefits from lot of free
> memory.
> My panos are commonly 14000x7000px built from about 32 pictures in
> eqirectangular projection. The enblend step needs about 1.5 to 1.7GB  
> RAM
> to run quickly, otherwise enblend goes to disk with slows down the
> process.

My MacBook Pro has 2GB of RAM, and i could only upgrade it to 3GB if  
i'd swap one 1GB for a 2GB module, something which will come after the  
transplantation of a bigger HD :)
As others said before, I'm happy that it runs, I don't really care if  
I let it render overnight, it will be finished in the morning, if it  
takes half an hour or if it takes 5 hours...
Cheers
Habi


--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---


Re: OpenGL slow because of reloading

by Harry van der Wolf-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi Habi,

The most prominent change is that the OSX RC5 bundle is 32/64bit. You run it on a macbook pro and I suppose with Leopard. It means that it will run in 64bit mode and use a 64bit address space. I think the enblend problems are related to the earlier 32bit versions. The 64bit enblend can allocate far more memory than the 32bit.
It should(!) function correctly on 32bit, but malloc on OSX is not very good and leaves many chunks of memory behind. The 64bit version can allocate much more memory. I assume it is therefore "more forgiving" as it has more memory to use as garbage bin before choking itself in it's own garbage.
It means that the Hugin builds in future should be preferably 32/64bit for those who can run in 64bit.

Who will build these bundles?

Hoi,
Harry


2009/7/13 David Haberthür <david.haberthuer@...>

Dear Guido

> regarding your comment "albeit it took approximately 5 hours to
> render", I
> expect you can speed up the calculation with more RAM. After upgrade
> my
> machine from 512MB to 2GB RAM the process was very quick compared to
> the
> less RAM configuration, especially enblend benefits from lot of free
> memory.
> My panos are commonly 14000x7000px built from about 32 pictures in
> eqirectangular projection. The enblend step needs about 1.5 to 1.7GB
> RAM
> to run quickly, otherwise enblend goes to disk with slows down the
> process.

My MacBook Pro has 2GB of RAM, and i could only upgrade it to 3GB if
i'd swap one 1GB for a 2GB module, something which will come after the
transplantation of a bigger HD :)
As others said before, I'm happy that it runs, I don't really care if
I let it render overnight, it will be finished in the morning, if it
takes half an hour or if it takes 5 hours...
Cheers
Habi





--~--~---------~--~----~------------~-------~--~----~
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@...
To unsubscribe from this group, send email to hugin-ptx-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---

< Prev | 1 - 2 - 3 | Next >