I was finally able to compile (statically!) all that is necessary to run enfuse on an embedded ARM box. It's quite slow and a simple gprof shows:
Each sample counts as 0.01 seconds. % cumulative self self total time seconds seconds calls s/call s/call name 23.07 11.91 11.91 __adddf3 15.92 20.13 8.22 __divdf3 11.22 25.92 5.79 __muldf3 4.53 28.26 2.34 __aeabi_fadd 4.20 30.43 2.17 __ieee754_exp 3.25 32.11 1.68 __cmpdf2 and only after this, the first "real" enfuse function starts. It seems the 'emulation' of FPU instructions takes over 60% of processing time. Now: any advice how to reduce the impact of FP? Can't enfuse use 'float' instead of 'double' for example? Or integers :) bye, thank you as On Jan 27, 3:03 am, Alessio Sangalli <mano...@gmail.com> wrote: > Hi, I would like to explore the possibility to run enfuse on anembeddedboard, > with an FPU-less ARM processor. The main issue I see > now is the rather large number of library dependencies. Do you know > what is the bare minimum set of dependencies that, maybe after some > patching, could result in a version of enfuse capable of JPG input and > output? Has anybody attempted something similar? > > bye, thank you > as -- 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
