Dear Guido and Harry, Guido Kohlmeyer wrote: > Thus Yuv's aproach should be continued.
my approach was to look at those who are more experienced and have more resources than me. Red Hat, Novell, Canonical are all large corporations producing popular Linux distributions. Canonical is based in U.K. and AFAIK has nothing that makes it subject to US jurisdiction. Red Hat is 100% US jurisdiction. Novell is an interesting case because it is a US company that bought Suse, an off-shore subsidiary in Germany. All of them have their own lawyers and it can be safely assumed that they are looking at all legal aspects pertinent to their distribution. Latest since the SCO lawsuits it has become clear how important it is to know where the code comes from and what IP rights are attached to it. In an ideal world, those companies have legal compliance processes in place that examine each piece of code before letting it into the distribution. The processes may not be perfect, but they are better than mine simply because they have the necessary resources. None of them includes SIFT code. > I will take it into account, if I'll generate a new setup. What's the > approch on the other paltforms? Single installs or one package with a > control flow similar to my current windows setup? The current windows setup is more or less the same as my snapshot installer. It was done for educational purposes, i.e. learning to master the control flow. I am not sure what the best architecture would be for a distribution that is not bound to a particular purpose. It could be a monolithic distribution with all the CP generators (and all the blenders) in one single installer. Or it could be a pluggable architecture, with each CP generator having its own installer. The installer is not so much critical as is the choice of tool within the process. Right now, I must go into the preferences to choose which of the many CP generators to use, and to set its parameters. But much of that is project related, and should IMO not be set in the general program preferences, but in the project itself. If the software can identify automatically, by a set of logical rules, which CP generator would work best, then it should be done so (with an option for the user to override it). Specifically, on the Assistant tab I would like to see a box under the 2. Align... button similar to the box that is currently under the 1. Load images... Similar to 1. Load images..., I would like to see the software pre-fill the values with defaults or with the result of some logic; and I would like to have the option, as a user, to override the software. In that box I would like to have: - a dropdown with a list of the available CP detectors. - an input field with their parameters (as they are now in the preferences) - a checkbox to run Celeste on cloudy skies (and later a list of checkbox when Celeste is trained against foliage, water, crowds, etc.) in the current interface, for the advanced user, the choice of CP detector / CP pruning mechanism would IMO belong on the Images tab where the functionality/buttons to "Create control points" and "Remove points" can be expanded to select the tool used for the task. > By the way, is it planned to do maintenance releases, e.g. hugin 0.7.1? > This would be a good point to integrate bugfixes as well as to generate a > new setup. http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/branches/release-0.7.0/ has been branched out, so if you want to integrate bug fixes you can commit them there. And of course to trunk. 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 [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 -~----------~----~----~----~------~----~------~--~---
