2009/9/4 Yuval Levy <[email protected]> > > Hoi Harry, > > I have two additional questions / remarks. > > Harry van der Wolf wrote: > > Specific items for OSX: > > - You cannot use GPU on MacOSX yet > > what is blocking this? > > I really don't know. It compiles fine but doesn't run. I already posted twice a log in the nona-gpu thread [1] but I had no response yet. I miss the coding skills to see what is going on and to solve it.
> > > - The images pane now has a setting for the AutoControlPoint creator. Too > > bad they didn't look at the MacOSX solution as they invented the wheel > twice > > (slightly different). But the new method is more flexible than the OSX > way. > > However, the new solution is useless for OSX as OSX still uses the plugin > > structure as before. > > reinventing the wheel is never fun. I think Thomas, who implemented the > new CP detector settings, does not have access to OSX. > > if the new method is more flexible, why is it useless for OSX? any > chance to bring this new solution to OSX and simplify code maintenance > (one solution for all platforms)? > > It is currently useless for OSX as the current implementation does not take into account that "things" work differently on OSX. On OSX a bundle expects everything to be inside the bundle available for the user. Earlier we did this by packaging the CPgenerators inside the bundle. However, to prevent license problems Ippei developed another solution which "connects" the CP plugins to the bundle without having to deliver the CP generator with or inside the bundle. OSX has a "Library/Application Support" directory structure inside the /Users (home) directory. You can couple things like templates, plugins, application scripts and so on, to a bundle without needing to install these on every update of the bundle (Hugin in this case) itself. Ippei's solution (OSX's solution) is very elegant in the way that you simply "install" a plugin. From that moment on the application, Hugin in this case, automatically knows that it can use it. The disadvantage of Ippei's implementation is that you can't change parameters which you can with Thomas solution. (I describe this as an elegant solution. It's an elegant solution to end users as Apple tries to keep it as simple as possible for the users, but for developers it is cumbersome). Off course, I will look into trying to merge Ippei's solution and Thomas' solution, but again: My coding skills in C/C++ are probably insufficient. I have not looked into the code yet, so maybe it's easier than expected (but on the other hand ..). When reading back it seems that I'm blaming the "inventor". This is not what I meant to do as Thomas' work/implementation again expands the possibilities of Hugin for the users bringing it to a higer level. It just would have been more efficient if Thomas had contacted Ippei and/or me as the OSX solution could have been combined with Thomas' solution. W.r.t. my resources: After my "return" on the mac I worked on making the "post 0.8" Hugin compile again on OSX and fix/update the XCode project/bundle. Now I'm planning to spend some time again to both ImageFuser and Avidemux. I also want to add some small changes to KImageFuser and than leave that one on low profile. Hoi, Harry [1]: http://groups.google.com/group/hugin-ptx/browse_thread/thread/d3ee3074a01b7b6 --~--~---------~--~----~------------~-------~--~----~ 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
