On Fri, 2009-10-09 at 09:13 +0100, Bruno Postle wrote: > On Fri 09-Oct-2009 at 02:49 -0400, Yuval Levy wrote: > > > >does this mean that it is unlikely that the accuracy of the Fast Preview > >will be improved? > > I think it is very dependent on the graphics hardware.
There are a few constants that alter the quality / speed tradeoff. They can be changed. I wanted to keep the preview fairly responsive on less powerful machines, so the accuracy should be easily improved, at a cost to speed. The constants could be tweaked, set based on hardware specifications, or made a preference. Here's where they are: The number of pixels of image data used is set here: http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/src/hugin1/hugin/TextureManager.cpp?revision=4005&view=markup#l_423 A too high value could cause a sudden performance drop on some hardware, but I think the current value is quite cautious, and inappropriately low when stacked images are used. There are two ways of remapping the images. The transformations are calculated by the CPU, but more accurate remapping requires transfering more data to any dedicated graphics hardware, and then rendering there. The quality level of the TexCoordRemapper, which maps evenly spaced points on the panorama to the input images, is set here: http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/src/hugin1/hugin/TexCoordRemapper.cpp?revision=3479&view=markup#l_27 There are several constants for the VertexCoordRemapper, which remaps points on the input images into the panorama: http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/src/hugin1/hugin/VertexCoordRemapper.cpp?revision=3721&view=markup#60 This remapper is adaptive: it adds detail where it thinks it is necessary. You can increase the maximum detail level or change how it decides when there is already enough. The colour correction is more tricky. Most new graphics hardware is programable, which would allow us to make an hdr mode, improve the difference mode, and make photometric correction work well. However, many existing machines don't support custom shaders, so we are stuck with a fixed-function graphics pipeline. We can get exposure and white balance correction this way, but is a bit of hack. The other colour transforms need the photometrics mode, which does the colour transform like the traditional preview (and changing the parameters causes a potentially very long delay in this mode). > >the only difference visible to me in the *chroma* around the preview is > >that Fast Preview (FP) does not have the Output dropdown in the Preview > >Options, that in the Traditional Preview (TP) is used to set the Output > >to HDR/LDR. > > It doesn't set the output of the project to HDR, it just implements > HDR merging and basic tonemapping in the Preview window itself. > > >how about (STEP 1) merging them visually with one single dropdown, > >Output, having three choices: FAST, LDR, HDR. Also layout mode belongs in this menu, and maybe the control point display mode as well. > >That toolbar is actually the next thorn in my eyes. There are too many > >buttons. We have a report that because of too long translation texts, > >the toolbar is larger than the window and some actions are not available. > > >How about (STEP 2) changing it into a menu? > > Maybe, I would certainly like to free up some of the empty space to > make the preview canvas itself bigger, and a 'full screen (F11)' > mode has long been on the wishlist. Definitely something that needs > mockups. > > There are some buttons that do similar things, and some buttons that > are mutually exclusive, these are an opportunity to merge stuff > together. > > I know we all hate the Office Ribbon, but I quite like the buttons > that are also pull-down menus - I don't know if wxwidgets implements > this. There isn't a menu toolbar item in wxWidgets, but it does allow any control to be added to a toolbar, so a combo box will do. http://docs.wxwidgets.org/stable/wx_wxtoolbar.html#wxtoolbaraddcontrol > This is all becoming imminent, the autocrop feature and the fast > preview will both add buttons to the Fast Preview window. The GTK widget library will (optionally but by default) add a menu containing toolbar items that don't fit on the toolbar on the edge of it. I can't find a similar feature in wxWidgets, and it doesn't just work on wxGTK. :-( A normal menu bar seems appropriate, as we continue to add features to the preview. -James --~--~---------~--~----~------------~-------~--~----~ 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 hugin-ptx@googlegroups.com To unsubscribe from this group, send email to hugin-ptx+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/hugin-ptx -~----------~----~----~----~------~----~------~--~---
