[hugin-ptx] hugin 2010.4 coredump on FreeBSD
The newest port of hugin for FreeBSD, http://www.freebsd.org/cgi/cvsweb.cgi/ports/graphics/hugin/ core dumps on FreeBSD 8-stable i386 32-bit. Earlier versions worked great. This is the first version ported that uses wxgtk2-2.8, and the port maintainer, Vasil Dimov reports that it runs fine on FreeBSD amd64. It shows the splash here, but that's all: % hugin IRQ's not enabled, falling back to busy waits: 2 0 IRQ's not enabled, falling back to busy waits: 2 0 Segmentation fault (core dumped) % (gdb) bt #0 0x in ?? () #1 0x081cccf3 in TextureManager::DisableTexture (this=0x38bfe5e0, maskOnly=false) at /usr/ports/graphics/hugin/work/hugin-2010.4.0/src/hugin1/hugin/TextureManager.cpp:179 #2 0x081704eb in GLRenderer::Redraw (this=0x38bfe610) at /usr/ports/graphics/hugin/work/hugin-2010.4.0/src/hugin1/hugin/GLRenderer.cpp:112 #3 0x0816f0de in GLViewer::Redraw (this=0x37cc4e00) at /usr/ports/graphics/hugin/work/hugin-2010.4.0/src/hugin1/hugin/GLViewer.cpp:233 #4 0x08170097 in GLViewer::RedrawE (this=0x37cc4e00, e=@0xbfbfc4b8) at /usr/ports/graphics/hugin/work/hugin-2010.4.0/src/hugin1/hugin/GLViewer.cpp:188 #5 0x34ed9167 in wxAppConsole::HandleEvent () from /usr/local/lib/libwx_baseu-2.8.so.0 #6 0x34f78f1a in wxEvtHandler::ProcessEventIfMatches () from /usr/local/lib/libwx_baseu-2.8.so.0 #7 0x34f79066 in wxEventHashTable::HandleEvent () from /usr/local/lib/libwx_baseu-2.8.so.0 #8 0x34f791b8 in wxEvtHandler::ProcessEvent () from /usr/local/lib/libwx_baseu-2.8.so.0 #9 0x3553df39 in wxGLContext::wxGLContext () from /usr/local/lib/libwx_gtk2u_gl-2.8.so.0 #10 0x373ad443 in g_cclosure_marshal_VOID__VOID () from /usr/local/lib/libgobject-2.0.so.0 #11 0x3739eb7e in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0 #12 0x373b5578 in g_signal_handlers_block_matched () from /usr/local/lib/libgobject-2.0.so.0 #13 0x373b75db in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 #14 0x373b791a in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 #15 0x36f4ec85 in gtk_widget_map () from /usr/local/lib/libgtk-x11-2.0.so.0 #16 0x36d75f1d in gtk_button_box_set_child_size () from /usr/local/lib/libgtk-x11-2.0.so.0 #17 0x36e8e013 in gtk_scrolled_window_get_type () from /usr/local/lib/libgtk-x11-2.0.so.0 #18 0x36daa785 in gtk_container_forall () from /usr/local/lib/libgtk-x11-2.0.so.0 #19 0x36dad18e in gtk_container_child_type () from /usr/local/lib/libgtk-x11-2.0.so.0 #20 0x373ad443 in g_cclosure_marshal_VOID__VOID () from /usr/local/lib/libgobject-2.0.so.0 #21 0x3739d501 in g_ptr_array_get_type () from /usr/local/lib/libgobject-2.0.so.0 #22 0x3739ec5f in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0 #23 0x373b51fa in g_signal_handlers_block_matched () from /usr/local/lib/libgobject-2.0.so.0 #24 0x373b75db in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 #25 0x373b791a in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 #26 0x36f4ec85 in gtk_widget_map () from /usr/local/lib/libgtk-x11-2.0.so.0 #27 0x3511bfec in gtk_pizza_new () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0 #28 0x373ad443 in g_cclosure_marshal_VOID__VOID () from /usr/local/lib/libgobject-2.0.so.0 #29 0x3739d501 in g_ptr_array_get_type () from /usr/local/lib/libgobject-2.0.so.0 #30 0x3739ec5f in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0 #31 0x373b51fa in g_signal_handlers_block_matched () from /usr/local/lib/libgobject-2.0.so.0 #32 0x373b75db in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 #33 0x373b791a in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 #34 0x36f4ec85 in gtk_widget_map () from /usr/local/lib/libgtk-x11-2.0.so.0 #35 0x3511bfec in gtk_pizza_new () from /usr/local/lib/libwx_gtk2u_core-2.8.so.0 #36 0x373ad443 in g_cclosure_marshal_VOID__VOID () from /usr/local/lib/libgobject-2.0.so.0 #37 0x3739d501 in g_ptr_array_get_type () from /usr/local/lib/libgobject-2.0.so.0 #38 0x3739ec5f in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0 #39 0x373b51fa in g_signal_handlers_block_matched () from /usr/local/lib/libgobject-2.0.so.0 #40 0x373b75db in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 #41 0x373b791a in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 #42 0x36f4ec85 in gtk_widget_map () from /usr/local/lib/libgtk-x11-2.0.so.0 #43 0x36f600d9 in gtk_window_new () from /usr/local/lib/libgtk-x11-2.0.so.0 #44 0x373ad443 in g_cclosure_marshal_VOID__VOID () from /usr/local/lib/libgobject-2.0.so.0 #45 0x3739d501 in g_ptr_array_get_type () from /usr/local/lib/libgobject-2.0.so.0 #46 0x3739eb7e in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0 #47 0x373b51fa in g_signal_handlers_block_matched () from /usr/local/lib/libgobject-2.0.so.0 #48 0x373b75db in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 #49 0x373b791a in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 #50 0x36f4ec85 in gtk_widget_map () from /usr/local/lib
[hugin-ptx] Re: More image tabs in fast preview window
I am glad this is a common issue and it looks like there are lots of ideas. I like the proposed dynamic area that automatically shows all selected photos, but it should be an option, not a replacement for the context of seeing where in the sequence images lie. Allowing the user to adjust the height of the tab section and thus control how many lines are displayed would solve the how many to show dilemma. While on this topic, a more direct way to find a specific image would be useful. Many CAD systems let users right click through a stacked layer of parts to select hidden objects. A similar right click option to cycle thru stacked photos, identify the number of a selected photo, and perhaps most importantly, allow editing of some sort would be great. Being able to directly remove a selected image from the project via the preview pane once selected, either thru the tab at top or a new right click option is a good first start to weed out bad images. Allowing masks to be drawn in preview will allow much greater continuity and speed for tweeking multi row images. Being able to crop all the moving heads from the upper row of a pano shot in a crowd quickly would be nice. Same goes for moving clouds between rows. There would obviously need to be some method of selecting which image or images to apply masks to. Adding control points would be another obvious feature to add to the preview tool once images can be directly selected. A zoom function would make placement a lot more accurate. The current scroll wheel field of view change(when they are selected) is mostly useless as is is not used often and the manual slider is much more accurate when needed. I'm sure zooming is a heavy set of computations, but resizing the window works like a charm, I don't see why this should be that different. An even more exotic control point feature would be an auto find feature that takes a user selected point on 1 image and searches nearby areas in all stacked photos for similar points. A dynamic threshold that starts lower than normal (after all, these points were probably not found in the origional search) and increases based on the angular distance (not pixel distance) from the chosen point. I have found selecting the exact same point on stacked photos, especially architectural ones with hard lines helps mediocre alignment projects, but gets time consuming when 5 or more images stack. It is these heavily overlapped corners that such a feature helps with most by getting everything to converge on 1 point. Being able to see control points that only tie to a single image could help root out bad images as the current implementation gets overwhelmed in large projects. A feature to sort by worst average control point distance for an entire image would also point out trouble images better than the worst pairs list in the control points tab. Well that got a bit out of hand, I hope I don't kill a good thread. I know feature requests are a dime a dozen, but the new fast preview is so good in my opinion that it deserves a spot in the creation chain, not just to check results. On Jan 13, 8:21 am, kevin wrote: > On Jan 13, 3:36 am, kfj <_...@yahoo.com> wrote: > > > > > > > > > > > I sympathize. In complex multi-sequence situations with large numbers > > of images, trying to identify images by looking at 'which number > > lights up' (or reverse) is a pain, since often the numbers for the > > image one wants to identify are outside the currently displayed range. > > This has often annoyed me. But where does one draw a line? 100 images? > > 200? two rows? three? maybe there's a better way altogether? > > > Kay > > > On 13 Jan., 05:54, Sigma Relief wrote: > > > > Just a minor request for the GUI on the fast preview feature in > > > windows; make the numbered tabs closer together when there are more > > > images. The old version could fit 50+ on a 1600 pixel wide screen > > > while fast preview fits 40 with large spacing between tabs. Reducing > > > spacing would be a good easy start. Wrapping to a 2nd or 3rd line > > > would make identifying images easier as it eliminates having to > > > continually scroll back and forth when using the identify feature. At > > > least in Windows, there is plenty of room for 3 rows of numbers, 1 > > > above the current row and 1 where the horizontal scroll bar is. A > > > small vertical scroll bar could be used for more than 3 rows. > > > > Are there any simple variables a user could tweak to improve this? > > > > I'm not sure if there is an official feature request area so any > > > pointers would be appreciated. > > What about in addition to the row with the scroll bar there's a line > where the numbers change. If there's no mouse on an image the area is > blank, when the mouse moves over images that area is used to show > which image numbers are currently highlighted and they can be colored > just like the scrolled row is. -- You received this message because you are subscribed to t
Re: [hugin-ptx] clustered hugin
On 11/01/11 18:37, michael.grant wrote: I see a few people have posted in the past wanting a clustered version of hugin. I'm wondering if there's been any development work on this. I have some general ideas I'd like to toss out. Could hugin be split up to run part of it's stitching remotely? For example, a stitch server would sit there and accept requests up to the number of CPUs it had available. The front end would feed pieces to as many stitch servers that were available. The server could run on a linux/unix server or as a windows service. Ultimately it would be really cool if people could run some public stitch servers (like grid computing) people could use the spare compute power of idle computers to stitch their images. At my current work a tool is being developed for this kind of distributed computing only it's intended for matlab based computations. Part of the system is also built in C, perhaps it can be adapted to suite hugin? Have a look at http://fieldtrip.fcdonders.nl (look in the FAQ section on peer computing). Cheers Simon -- 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
[hugin-ptx] hugin problems with finding control points with large number of images
I'm using this version of Hugin from sourceforge: HuginSetup_2010.4.0-32bit_Windows.exe I'm having trouble stitching a pano that has about 150 freehand shot images (no tripod). First I tried with the built in cpfind. After 20minutes, I get the following error at the end of the log: --- Write Project output --- Written output to C:\DOCUME~1\Michael\LOCALS~1\Temp\ap_2EE.tmp Detection took 1001.17 seconds. Written output to C:/Documents and Settings/Michael/My Documents/My Pictures/2011_01_09/IMG_5290-IMG_5440.pto "C:/Program Files/Hugin/bin/checkpto" "C:/Documents and Settings/ Michael/My Documents/My Pictures/2011_01_09/IMG_5290-IMG_5440.pto" Found unconnected images Stopping processing. make: *** [all] Error 1 I then tried with autopano-sift-c. After some searching around, I discovered I needed to set this as the arguments: --maxmatches %p %o %s (I'm using the version 2.5.2 of autopano-sift-c from http://lemur.dreamhosters.com/hugin/) I can get it to complete the discovery of the control points but it ends up with 2 sets of images like this: Connected component check... Connected component identification resulted in 2 components: component 1: /IMG_5408.JPG, /IMG_5409.JPG, /IMG_5379.JPG, / IMG_5380.JPG, /IMG_5364.JPG /IMG_5365.JPG, /IMG_5366.JPG, /IMG_5367.JPG, /IMG_5371.JPG, / IMG_5373.JPG /IMG_5374.JPG, /IMG_5372.JPG, /IMG_5290.JPG, /IMG_5291.JPG, / IMG_5292.JPG /IMG_5306.JPG, /IMG_5410.JPG, /IMG_5411.JPG, /IMG_5293.JPG, / IMG_5307.JPG /IMG_5294.JPG, /IMG_5295.JPG, /IMG_5308.JPG, /IMG_5309.JPG, / IMG_5405.JPG /IMG_5406.JPG, /IMG_5310.JPG, /IMG_5296.JPG, /IMG_5297.JPG, / IMG_5311.JPG /IMG_5401.JPG, /IMG_5298.JPG, /IMG_5312.JPG, /IMG_5389.JPG, / IMG_5299.JPG /IMG_5313.JPG, /IMG_5402.JPG, /IMG_5314.JPG, /IMG_5388.JPG, / IMG_5397.JPG /IMG_5399.JPG, /IMG_5400.JPG, /IMG_5300.JPG, /IMG_5301.JPG, / IMG_5315.JPG /IMG_5396.JPG, /IMG_5302.JPG, /IMG_5316.JPG, /IMG_5390.JPG, / IMG_5391.JPG /IMG_5395.JPG, /IMG_5398.JPG, /IMG_5303.JPG, /IMG_5317.JPG, / IMG_5393.JPG /IMG_5318.JPG, /IMG_5394.JPG, /IMG_5304.JPG, /IMG_5319.JPG, / IMG_5392.JPG /IMG_5305.JPG, /IMG_5320.JPG, /IMG_5321.JPG, /IMG_5322.JPG, / IMG_5407.JPG /IMG_5403.JPG, /IMG_5385.JPG, /IMG_5284.JPG, /IMG_5382.JPG, / IMG_5323.JPG /IMG_5324.JPG, /IMG_5325.JPG, /IMG_5347.JPG, /IMG_5326.JPG, / IMG_5327.JPG /IMG_5346.JPG, /IMG_5349.JPG, /IMG_5328.JPG, /IMG_5329.JPG, / IMG_5348.JPG /IMG_5351.JPG, /IMG_5285.JPG, /IMG_5287.JPG, /IMG_5343.JPG, / IMG_5344.JPG /IMG_5330.JPG, /IMG_5352.JPG, /IMG_5289.JPG, /IMG_5331.JPG, / IMG_5342.JPG /IMG_5345.JPG, /IMG_5353.JPG, /IMG_5288.JPG, /IMG_5332.JPG, / IMG_5333.JPG /IMG_5334.JPG, /IMG_5335.JPG, /IMG_5341.JPG, /IMG_5354.JPG, / IMG_5286.JPG /IMG_5336.JPG, /IMG_5340.JPG, /IMG_5355.JPG, /IMG_5358.JPG, / IMG_5337.JPG /IMG_5338.JPG, /IMG_5360.JPG, /IMG_5370.JPG, /IMG_5369.JPG, / IMG_5339.JPG /IMG_5368.JPG, /IMG_5359.JPG, /IMG_5361.JPG, /IMG_5356.JPG, / IMG_5357.JPG /IMG_5350.JPG, /IMG_5378.JPG, /IMG_5362.JPG, /IMG_5363.JPG, / IMG_5375.JPG /IMG_5377.JPG, /IMG_5376.JPG, /IMG_5381.JPG, /IMG_5383.JPG, / IMG_5384.JPG /IMG_5387.JPG, /IMG_5386.JPG, /IMG_5404.JPG component 2: /IMG_5412.JPG, /IMG_5413.JPG, /IMG_5414.JPG, / IMG_5415.JPG, /IMG_5418.JPG /IMG_5419.JPG, /IMG_5420.JPG, /IMG_5421.JPG, /IMG_5429.JPG, / IMG_5432.JPG /IMG_5438.JPG, /IMG_5439.JPG, /IMG_5440.JPG, /IMG_5416.JPG, / IMG_5417.JPG /IMG_5426.JPG, /IMG_5427.JPG, /IMG_5422.JPG, /IMG_5423.JPG, / IMG_5428.JPG /IMG_5424.JPG, /IMG_5431.JPG, /IMG_5430.JPG, /IMG_5433.JPG, / IMG_5425.JPG /IMG_5434.JPG, /IMG_5435.JPG, /IMG_5437.JPG, /IMG_5436.JPG Oddly, if I try with the same set of images in AutoPanoGiga, It manages to connect everything in one huge image, it somehow manages to figure out how it all fits together, although AutoPanoGiga fails during smoothing I think due to lack of memory. Does anyone know which control point detector AutoPanoGiga uses? Is the similar algorithm available in Hugin? I tried several of the other control point detectors, for example "autopano" and I get an error: Finding control points... "C:/Program Files/Hugin/bin/icpfind" -o "C:/Documents and Settings/ Michael/My Documents/My Pictures/2011_01_09/IMG_5290-IMG_5440.pto" "C:/ Documents and Settings/Michael/My Documents/My Pictures/2011_01_09/ IMG_5290-IMG_5440.pto" autopano-sift, Automatic panorama generation program Loading keyfiles 019EB47C Failed to load keypoints from *44 make: *** [all] Error 1 Pan-o-matic doesn't seem to handle the %s properly and doesn't seem capable of handling >127 images. What else can I try to stitch this monster? Michael -- 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, v
[hugin-ptx] Re: make: *** [info] Error 258
Hi it works also for me now! It was (also) the WinAVR in my case! Thank you all for your help Olaf On 12 Jan., 02:12, Sigma Relief wrote: > Ganesh nailed it, my copy of winavr in the root directory contained > the offending files. A simple rename of the folder is a good > workaround. > > On Jan 10, 8:19 pm, Ganesh wrote: > > > Sorry if this is a repeat. > > > But I had the same problem, and fixed it. > > > I realized the Cygwin tools in my system path is messing up Hugin > > (that is where it was finding sh.exe and trying to run the Windows > > Batch command echo through it and failing). I fixed the error by > > renaming my Cygwin folder temporarily. -- 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
[hugin-ptx] Re: what should be in the scripting interface? please have your say!
On 12 Jan., 20:08, Pablo d'Angelo wrote: > Btw. is your code available in some repo? Maybe a new hugin_scripting > branch would be a good idea. Have a look at http://groups.google.com/group/hugin-ptx/browse_thread/thread/ab1f0df18aaa247d# I put the stuff online today. Kay -- 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
[hugin-ptx] Hugin Scripting Interface alpha available
Hi all! I've made a source and a binary version of my hugin scripting interface, 'hsi', available for download. To find out what it does and which version is for you, please have a look at the README: http://bazaar.launchpad.net/%7Ekfj/%2Bjunk/script/annotate/head%3A/main/README.hsi The code is here: http://bazaar.launchpad.net/%7Ekfj/%2Bjunk/script/annotate/head%3A/main/hsi.source.tgz http://bazaar.launchpad.net/%7Ekfj/%2Bjunk/script/annotate/head%3A/main/hsi.binary.tgz Echoes welcome. Kay -- 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
[hugin-ptx] Re: More image tabs in fast preview window
On Jan 13, 3:36 am, kfj <_...@yahoo.com> wrote: > I sympathize. In complex multi-sequence situations with large numbers > of images, trying to identify images by looking at 'which number > lights up' (or reverse) is a pain, since often the numbers for the > image one wants to identify are outside the currently displayed range. > This has often annoyed me. But where does one draw a line? 100 images? > 200? two rows? three? maybe there's a better way altogether? > > Kay > > On 13 Jan., 05:54, Sigma Relief wrote: > > > Just a minor request for the GUI on the fast preview feature in > > windows; make the numbered tabs closer together when there are more > > images. The old version could fit 50+ on a 1600 pixel wide screen > > while fast preview fits 40 with large spacing between tabs. Reducing > > spacing would be a good easy start. Wrapping to a 2nd or 3rd line > > would make identifying images easier as it eliminates having to > > continually scroll back and forth when using the identify feature. At > > least in Windows, there is plenty of room for 3 rows of numbers, 1 > > above the current row and 1 where the horizontal scroll bar is. A > > small vertical scroll bar could be used for more than 3 rows. > > > Are there any simple variables a user could tweak to improve this? > > > I'm not sure if there is an official feature request area so any > > pointers would be appreciated. What about in addition to the row with the scroll bar there's a line where the numbers change. If there's no mouse on an image the area is blank, when the mouse moves over images that area is used to show which image numbers are currently highlighted and they can be colored just like the scrolled row is. -- 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
Re: [hugin-ptx] Re: More image tabs in fast preview window
Kay what about one row but autoscrolling to desired number. On Thu, Jan 13, 2011 at 1:36 PM, kfj <_...@yahoo.com> wrote: > I sympathize. In complex multi-sequence situations with large numbers > of images, trying to identify images by looking at 'which number > lights up' (or reverse) is a pain, since often the numbers for the > image one wants to identify are outside the currently displayed range. > This has often annoyed me. But where does one draw a line? 100 images? > 200? two rows? three? maybe there's a better way altogether? > > Kay > > On 13 Jan., 05:54, Sigma Relief wrote: > > Just a minor request for the GUI on the fast preview feature in > > windows; make the numbered tabs closer together when there are more > > images. The old version could fit 50+ on a 1600 pixel wide screen > > while fast preview fits 40 with large spacing between tabs. Reducing > > spacing would be a good easy start. Wrapping to a 2nd or 3rd line > > would make identifying images easier as it eliminates having to > > continually scroll back and forth when using the identify feature. At > > least in Windows, there is plenty of room for 3 rows of numbers, 1 > > above the current row and 1 where the horizontal scroll bar is. A > > small vertical scroll bar could be used for more than 3 rows. > > > > Are there any simple variables a user could tweak to improve this? > > > > I'm not sure if there is an official feature request area so any > > pointers would be appreciated. > > -- > 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 > -- *Emaad* www.flickr.com/emaad -- 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
[hugin-ptx] Re: More image tabs in fast preview window
I sympathize. In complex multi-sequence situations with large numbers of images, trying to identify images by looking at 'which number lights up' (or reverse) is a pain, since often the numbers for the image one wants to identify are outside the currently displayed range. This has often annoyed me. But where does one draw a line? 100 images? 200? two rows? three? maybe there's a better way altogether? Kay On 13 Jan., 05:54, Sigma Relief wrote: > Just a minor request for the GUI on the fast preview feature in > windows; make the numbered tabs closer together when there are more > images. The old version could fit 50+ on a 1600 pixel wide screen > while fast preview fits 40 with large spacing between tabs. Reducing > spacing would be a good easy start. Wrapping to a 2nd or 3rd line > would make identifying images easier as it eliminates having to > continually scroll back and forth when using the identify feature. At > least in Windows, there is plenty of room for 3 rows of numbers, 1 > above the current row and 1 where the horizontal scroll bar is. A > small vertical scroll bar could be used for more than 3 rows. > > Are there any simple variables a user could tweak to improve this? > > I'm not sure if there is an official feature request area so any > pointers would be appreciated. -- 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
