Hi all, I finally got around to read all the interesting opinions expressed in the previous thread [0]. Those who know me well know how hard it was to let the discussion go without answering :-) but it was well worth it. I wanted to hear *your* opinions.
My understanding is that V+W seems to be broadly acceptable to most; and that the main point of contention is single output / limited set of projections vs. multiple outputs / broad set of projections. Let's first look at what most of us agree on; and then continue on the main point of contention. V is OpenGL. It's blazing fast. It is responsive right away (with place holders while a background task loads the images and creates the textures). Could it be a game engine (as precognized by Bart)? How difficult would it be to make the current fast preview a spherical viewer (while retaining all the functionality)? could be one of the preview modes. W needs more specification. Thank you Bruno for the overview of the current tabbed interface. Knowing where we come from is important when discussing where to go next. To me personally, the major limitation of the current tabbed interface is the rigidity of the single workflow, represented by the individual tabs. It's broken. In term of workflow I see it split in two: input and output, with the input converging to a single image and the output diverging again into different view / projections / formats. The main point of contention is the point where input ends and output starts, with some proponents of a single output / limited set of projections; while others prefer a broad set of projections. I tend to side with Seb, Lukas, James on this one. There is enough of a use case to leave the output of the stitcher as-is, even if the choice may look daunting complex to a newbie. I rather reduce the complexity through interface work than through limiting the choices to equirect, cube, and maybe cylinder. Where is mosaic in all of this? I do understand the point raised by Bruno, Tom, Nicolas. There is a point of inflection in the workflow, where input ends and output begins. Input converges toward the "single output" equirect proposed by Tom (although in the meantime, thanks to the discussion, we know that equirect is not enough for all use cases). It's about generating control points, pruning them, aligning the images. Output diverges again. Starting from the "single input", it creates different views from the same "equirect". Tom has analyzed this very thoroughly. His Panini tool is an actual implementation of something very similar. Like Tom I also would like to see a workflow / graphic representation of this. I'm still not sure about it's positioning, though. I think it does not deserve to be at the top of the hierarchy as it is now (the tabs represent a workflow). I'd rather have it as a tab, with blocks that can be added/removed/connected. In my present draft idea, those blocks could be input or output blocks, to represent the input and output workflow. Output is relatively easy: projection, view(hfov/vfov/yaw/pitch/roll), canvas(width/height/crop); and we can line up as many of them as we want. Input is slightly more complex, as it needs to keep status of whether images have been added / moved since the last optimization, etc. Although it looks very much like all of today's tabs with the exception of the stitcher tab (that is, after all, Output). Using "make" as the underlying "keeper of status" makes sense to me; and I agree with Bruno's view that it would be very nice if the batch processor could piggy-back on "make" rather than going through the whole project from scratch every time. Ideally, as I work through the GUI, individual steps are added / updated to the makefile and the batch stitcher runs in the background, using make to determine if something has changed and triggering the necessary implementation actions. Sometimes very far down the line it would be nice to have feedback about make's completition status, e.g. by a changing color in the blocks on the workflow representation (e.g.: gray = waiting in the pipeline; green = done; the volume being progressively filled from gray to green to signal the degree of completition of the block; and red = error/problem). More thinking to do. More opinions welcome. Last but not least, a word about wxPython. Binding C++ with Python is doable [1]. Many projects, including commercial ones (Google) do that often. Python for rapid development and UI work; C/C++ for the bottlenecks. wxPython is equally supported as wxWidgets and can do the same. Adding Python bindings to the functionality inside Hugin would make it accessible to a wxPython GUI; and everything we can do in wxWidgets/C++ we can do in wxPython. I think it is worth thinking about using Python for the UI. Yuv [0] http://groups.google.com/group/hugin-ptx/browse_thread/thread/43d15deec2251b87 [1] http://www.swig.org/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
