Gerry Patterson wrote: >> Rename the Enblend tab in the Preferences dialog to "Stitching". Add a >> section called "Nona" (similar to the existing Enblend and Enfuse sections) >> and here add entries for defaults to use in projects (interpolator, cropped >> tiff output...). Here a checkbox could be added to enable GPU support by >> default. This would be then saved in the global preferences (registry on >> windows, ini files elsewhere) >> >> Then, on the stitcher tab, add a GPU checkbox in the nona optoins dialog. >> This would allow the user to disable it if required for that particular >> project. When the project is saved, this state would be stored in .pto >> file. >> >> Does this make sense? >> >> - Gerry >> >> > Hi All, > > I have attached a screen shot of what I was talking about in the previous > e-mail. Does this seem appropriate?
yes. this is very much along the lines of what I was thinking. however my thinking is still incomplete and instead of continuing to fiddle with the code I stopped and took a broader look. I see two ways to approach the problem: 1. forward-thinking: start with a GUI mockup and dig into the code to implement the functionalities until it trickles down to the actual project execution. your mockup is the start. this is what I did until I came across an inconsistency that should not be: the -g option is passed to the Makefile generated when saving the project, but not to the Makefile generated when hitting "stitch now". 2. backward-thinking: start with the end, i.e. with the project execution, and work upstream to the user defined parameters in the GUI. I was actually able to *partially* pass the -g parameters to a Makefile: The saved .pto.mk file was correct, so CLI stitching would work, and probably also PTbatcher (I admit have not used/studied that part of Hugin). But when I hit the "stitch now" button, the temporary Makefile created differs from the saved one and it does not work. Then I thought backward, digging into the code to the points where the Makefiles are executed and where they are generated. To my shock, it is different. And I think I found at least one significant issue: Hugin relies on wxWidgets to get/set preferences. This dependency handicaps CLI tools which simply do not read these preferences and "forget" about settings such as the tmp location or celeste's treshhold. Not understandable/acceptable for the user who expects his preferences to be honored. wxWidgets has the advantage of abstracting the details of different operating systems in dealing with the preferences: they are stored in ~/.hugin on Linux (and OSX) systems; and in the registry on Windows. Fully transparent to Hugin. Very convenient, but with limitations: unless we find a way to parse and implement these preferences in the CLI tools, the current way of setting, reading and storing preferences is unacceptable. It is a major design bug that hitting "stitch now" or "save" in the Hugin GUI on the same system and with the same project yields two different Makefiles. We need a consistent way to set/store/get preferences that is independent of wxWidgets and that can be used by *all* tools - whether GUI or CLI. generating and reading .pto and .pto.mk files should always yield the same results. I see two solutions to the problem. The comprehensive solution would be a new (as in: consider if there are solutions already used by other Open Source projects before writing from scratch) library to deal with the setting/storing/reading preferences that can be linked from both the GUI and the CLI tools; or a workaround parser that parses the existing preferences settings wherever they are (~/.hugin file or hugin registry key) to make them available to the CLI tools. I personally tend more toward the "new" solution. A good one would also free us of the Windows registry and save the preferences in a .ini file, and maybe even move to an XML file format (for both preferences and project files) making it easier to maintain and expand. In the meantime trying to pass arguments as the -g will necessarily be a dirty job. 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 -~----------~----~----~----~------~----~------~--~---
