Hi Yuv, On 1 July 2011 23:14, Yuval Levy <[email protected]> wrote: > On June 30, 2011 11:34:33 AM Lukáš Jirkovský wrote: >> I made few mock-ups (sorry for the watermark): > > Looks promising! > > I would make the image browser flexible. The strip in the window is one > incarnation. Add a lighttable kind of image browser would help too, with the > images grouped in logical folders: projects by date/time, with stacks as > subfolders. And with quick access to (batch) processing functionality.
I'm not sure what you mean by a light table. I know there is light table option in digikam (great feature, BTW) and the film strip widget in my mockups was made with something like that in mind. Grouping can be done by enclosing images from the same stack/whatever in some kind of box, perhaps with a possibility of collapse the entire group into one element. > I am missing two buttons on the images_multiple and images_CP_advanced > mockups: forward and backward. I agree. Apart from using keyboard shortcuts there should be forward/backward button. The question is: "where to place them?" Digikam have these buttons in the film strip. They are shown next to the thumbnails of active images. I don't like it, because the position of buttons change while switching between images. I can think of two places. A first is next to the other tools, such as the mask and crop tool, because there is a lot of free space here. The second one is to place these buttons somewhere in the film strip, but at a fixed position (so they aren't a moving target like in digikam). But the forward and backward buttons brings in another question. How they should behave when stacks are used? Assume you have two stacks made of three images. You have selected the second image in both stacks. Should the forward button move to the next pair of stacks or should it switch to the third image in the current stacks? I think there should actually be two pairs of buttons. One pair of buttons would switch to a next/previous image in the current stacks, the one would switch to a next pair of stacks. > And I would make context-dependent functions (as Thomas started to implement) > accessible via a menu, so that they do not take up screen space. I agree. > It would be neat if the fast preview was the hub and those mockup screens > would open up from hot spots / context menu there and in the image browser. > > The context-menu on the image would bring up a choice of > - images_advanced > - maskingtext-menu on the link I thought it will completely replace the images tab. But yeah, it would be good to have some browser which would show all images at once, without any unnecessary widgets. However I'd prefer if these mockups would open using (double?) click on an image rather than use context menu for this. > While on links between images it would bring up images_multiple or > images_CP_advanced. Yep, I wouldn't want lose the this connection between CP tab and fast preview. It's too useful to be removed. > One key (spacebar?) in the fast preview would toggle visibility of the > hotspots/links between images. > > The linear workflow is dead. While it is still conceptually valid at an > abstract level, it is too far removed from the reality. > > For simple projects I only use the CP tab to add vertical CPs; then the > optimizer to straighten the panorama; then the fast preview and the stitcher > tab to frame the pano. > > For complex projects it is a non-linear forth and back between the different > tabs, in most cases starting from an automatically generated project. > > Only if the assistant fails the project completely I start from scratch, and > only then does the tab order make more or less sense. > > There are a few things still missing in the fast preview, first and foremost: > - zooming in and out > - rendering of HDR (to make the old preview redundant) > > But IMHO it is ready to take over as main app display soon. > > Then we need one screen to summarize/hide the process > (assistant/optimizer/exposure/stitcher) - maybe inside ptbatcher? > > yuv > Anyway, I think we should keep it slow. Evolution, not revolution. If something similar to the mockups would be implemented, I'd start by implementing images tab functionality into such screen first. Then, after it has been tested, the functionality of other tabs might be added one by one while removing these tabs. -- 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
