Re: [hugin-ptx] Getting Hugin interface to display decimal angular values ( not truncated) in assembly tab
On 11/07/2017 06:41 PM, Sean Greenslade wrote: On Tue, Nov 07, 2017 at 12:58:57AM -0800, FabKzo wrote: Hi all, Could it be possible to perform this type of modification in the interface ? In fact I need complete angular datas with decimal values to work on panoramas I produce; while all decimal values are considerated to calculate panoramas pixel width and height with no problem ( I can apply a roll modification of 0.01° , or make a panorama of 32,1 ° vertical angle ), I find those values to be rounded too quickly in the interface. How can I modify this behavior? Can you be a more specific about what you're trying to accomplish? Manually editing image positions / angles is a somewhat unusual way of using Hugin. Is the optimizer not producing good results for you? I don't know of any "assembly" tab in Hugin, and the only tab that contains angle data for the individual images is the optimizer tab. Maybe he means Expert Interface > Photos tab > Display 'Positions'? Shows Yaw, Pitch, Roll, X/Y/Z translation, Plane yaw, Plan pitch, Camera translation. The few times I've looked at it when working on a pano, the columns by default are too narrow to display the full number of digits, so they display a rounded version. When I widen the column enough, all the digits show up. Perhaps Hugin could remember column widths when someone sets them? The version I have installed here now (2017.0.0.eac5e8cc546e from Debian Testing repository) doesn't. -- David W. Jones gnomeno...@gmail.com wandering the landscape of god http://dancingtreefrog.com -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/b6634faf-1c3b-08e5-94a2-8f3324bd6436%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [hugin-ptx] Getting Hugin interface to display decimal angular values ( not truncated) in assembly tab
On Tue, Nov 07, 2017 at 12:58:57AM -0800, FabKzo wrote: > Hi all, > > Could it be possible to perform this type of modification in the interface ? > > In fact I need complete angular datas with decimal values to work on > panoramas I produce; while all decimal values are considerated to > calculate panoramas pixel width and height with no problem ( I can apply a > roll modification of 0.01° , or make a panorama of 32,1 ° vertical angle ), > I find those values to be rounded too quickly in the interface. > > How can I modify this behavior? Can you be a more specific about what you're trying to accomplish? Manually editing image positions / angles is a somewhat unusual way of using Hugin. Is the optimizer not producing good results for you? I don't know of any "assembly" tab in Hugin, and the only tab that contains angle data for the individual images is the optimizer tab. If you right click on an image in the optimizer tab list, you can click "edit image variables" and view / set the decimal values to their full precision. --Sean -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/20171108044121.GA19594%40coach. For more options, visit https://groups.google.com/d/optout.
[hugin-ptx] Re: Multiblend on a Mac
I did make the changes as suggested, and had to provide --bgr to make it work. So it seems that in my case I should not have touched the default. I was working with 8bit tiffs. On Tuesday, November 7, 2017 at 10:15:51 AM UTC+2, Kurt Hillig wrote: > > The code changes I posted basically reverse the meaning of the --bgr > option on Apple systems - the first change makes g_bgr true by default > for Macs (and also makes g_wideblend true by default for all systems), > while the second change allows the --bgr and --wideblend command line > options invert the value of the corresponding variables (T to F or F to T) > rather than explicitly making them true. > > So if you make these changes but still specify "--bgr" on the command > line, then you will see the behavior that you got. > > OTOH I only tested with 16-bit TIFF files, not 8-bit - so it may be that > these don't order the color data the same way. > I guess I'll have to run some more tests... > > > On Monday, November 6, 2017 at 2:32:37 PM UTC-5, Mikko Kuutti wrote: >> >> Fixed it myself: seems the changes to --bgr shouldn't be done. Or at >> least I could counteract this problem by passing --bgr to multiblend. >> >> >> On Monday, November 6, 2017 at 9:27:55 PM UTC+2, Mikko Kuutti wrote: >>> >>> I tried this. The compilation was uneventful with only two warnings. The >>> newly compiled multiblend also seems quite fast >>> – only problem is the resulting file has quite weird colours: reds turns >>> purple and yellows turn blue. >>> >>> I'm working with 8-bit tiffs. >>> >>> Any idea how to fix this? >>> >>> Mikko >>> >>> >>> On Saturday, November 4, 2017 at 6:03:42 AM UTC+2, Dr. Kurt wrote: Maybe all of the Mac users of Hugin have already figured out how to get multiblend (http://horman.net/multiblend/) to work - if you haven't you should really try it, it's *much* faster than enblend, at least for the kind of panoramas I create. But it's not optimized for OSX, and the build instructions for Linux need some tweaking before they will work. So if you're a Mac user like me and want to get it running, here are a few notes on what I did: I've made a few minor tweaks to the code to make it a bit easier to use: 1) In globals.cpp replace: bool g_wideblend=false; bool g_bgr=false; with: bool g_wideblend=true; #ifdef __APPLE__ bool g_bgr=true; #else bool g_bgr=false; #endif I admit I'm not sure whether changing the default for g_wideblend makes any significant difference, but it seems to work well for me. The #ifdef eliminages the need to specify "--bgr" as a command line option on Mac systems. 2) In multiblend.cpp replace: else if (!strcmp(argv[i],"--bgr")) g_bgr=true; else if (!strcmp(argv[i],"--wideblend")) g_wideblend=true; with: else if (!strcmp(argv[i],"--bgr")) g_bgr=!g_bgr; else if (!strcmp(argv[i],"--wideblend")) g_wideblend=!g_wideblend; The help text for the --wideblend option should also be updated to reflect the change. Note that the changes in these two files are independent; if you don't change globals.cpp then multiblend will retain its current behavior for these two options. To compile multiblend, you must have libtiff, libjpeg and libpng installed (typically in /opt/local/lib - there are several ways to get these if you don't already have them). You can then build multiblend with this command: g++ -L/opt/local/lib -I/opt/local/include -msse2 -O2 multiblend.cpp -ltiff -ljpeg -lpng -o multiblend if you've installed libjpeg-turbo then change the "-ljpeg" to " -lturbojpeg" - you might need to add another -L option depending on where it resides . If you've got the various libs and header files in /usr/local or other places rather than (or as well as) /opt/local then you should add the appropriate "-L" and "-I" options to the command line. There will be two "comparison of unsigned expression >= 0 is always true" warnings generated, but these can be ignored. Once multiblend is built and tested (try the command "./multiblend --help"), you can go into Hugin's preferences and add it as an alternative to enblend. I haven't yet figured out how to propagate the ICC profile info from the input files to the output file; enblend does this quite nicely, but I'm not sufficiently fluent in C++ (I'm an old FORTRAN guy from way back...) to know just what should be cut-n-pasted to add this to multiblend. If anyone else would like to give it a shot, I'd love to see this! -- A list of frequently asked questions is available at:
[hugin-ptx] Getting Hugin interface to display decimal angular values ( not truncated) in assembly tab
Hi all, Could it be possible to perform this type of modification in the interface ? In fact I need complete angular datas with decimal values to work on panoramas I produce; while all decimal values are considerated to calculate panoramas pixel width and height with no problem ( I can apply a roll modification of 0.01° , or make a panorama of 32,1 ° vertical angle ), I find those values to be rounded too quickly in the interface. How can I modify this behavior? Best regards, -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/10a737a5-d197-404a-93bc-7d422232553c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[hugin-ptx] Re: Multiblend on a Mac
The code changes I posted basically reverse the meaning of the --bgr option on Apple systems - the first change makes g_bgr true by default for Macs (and also makes g_wideblend true by default for all systems), while the second change allows the --bgr and --wideblend command line options invert the value of the corresponding variables (T to F or F to T) rather than explicitly making them true. So if you make these changes but still specify "--bgr" on the command line, then you will see the behavior that you got. OTOH I only tested with 16-bit TIFF files, not 8-bit - so it may be that these don't order the color data the same way. I guess I'll have to run some more tests... On Monday, November 6, 2017 at 2:32:37 PM UTC-5, Mikko Kuutti wrote: > > Fixed it myself: seems the changes to --bgr shouldn't be done. Or at least > I could counteract this problem by passing --bgr to multiblend. > > > On Monday, November 6, 2017 at 9:27:55 PM UTC+2, Mikko Kuutti wrote: >> >> I tried this. The compilation was uneventful with only two warnings. The >> newly compiled multiblend also seems quite fast >> – only problem is the resulting file has quite weird colours: reds turns >> purple and yellows turn blue. >> >> I'm working with 8-bit tiffs. >> >> Any idea how to fix this? >> >> Mikko >> >> >> On Saturday, November 4, 2017 at 6:03:42 AM UTC+2, Dr. Kurt wrote: >>> >>> Maybe all of the Mac users of Hugin have already figured out how to get >>> multiblend (http://horman.net/multiblend/) to work - if you haven't you >>> should really try it, it's *much* faster than enblend, at least for the >>> kind of panoramas I create. But it's not optimized for OSX, and the build >>> instructions for Linux need some tweaking before they will work. So if >>> you're a Mac user like me and want to get it running, here are a few notes >>> on what I did: >>> >>> I've made a few minor tweaks to the code to make it a bit easier to use: >>> >>> 1) In globals.cpp replace: >>> bool g_wideblend=false; >>> bool g_bgr=false; >>> with: >>> bool g_wideblend=true; >>> >>> #ifdef __APPLE__ >>> >>> bool g_bgr=true; >>> >>> #else >>> >>> bool g_bgr=false; >>> >>> #endif >>> >>> I admit I'm not sure whether changing the default for g_wideblend makes >>> any significant difference, but it seems to work well for me. The >>> #ifdef eliminages the need to specify "--bgr" as a command line option >>> on Mac systems. >>> >>> >>> 2) In multiblend.cpp replace: >>> >>> else if (!strcmp(argv[i],"--bgr")) g_bgr=true; >>> >>> else if (!strcmp(argv[i],"--wideblend")) g_wideblend=true; >>> with: >>> else if (!strcmp(argv[i],"--bgr")) g_bgr=!g_bgr; >>> else if (!strcmp(argv[i],"--wideblend")) g_wideblend=!g_wideblend; >>> >>> The help text for the --wideblend option should also be updated to >>> reflect the change. Note that the changes in these two files are >>> independent; if you don't change globals.cpp then multiblend will >>> retain its current behavior for these two options. >>> >>> >>> To compile multiblend, you must have libtiff, libjpeg and libpng installed >>> (typically in /opt/local/lib - there are several ways to get these if you >>> don't already have them). You can then build multiblend with this command: >>> >>> g++ -L/opt/local/lib -I/opt/local/include -msse2 -O2 multiblend.cpp >>> -ltiff -ljpeg -lpng -o multiblend >>> >>> >>> if you've installed libjpeg-turbo then change the "-ljpeg" to " >>> -lturbojpeg" - you might need to add another -L option depending on >>> where it resides . >>> If you've got the various libs and header files in /usr/local or other >>> places rather than (or as well as) /opt/local then you should add the >>> appropriate "-L" and "-I" options to the command line. >>> There will be two "comparison of unsigned expression >= 0 is always true" >>> warnings generated, but these can be ignored. >>> >>> Once multiblend is built and tested (try the command "./multiblend >>> --help"), you can go into Hugin's preferences and add it as an alternative >>> to enblend. >>> >>> >>> I haven't yet figured out how to propagate the ICC profile info from the >>> input files to the output file; enblend does this quite nicely, but I'm not >>> sufficiently fluent in C++ (I'm an old FORTRAN guy from way back...) to >>> know just what should be cut-n-pasted to add this to multiblend. If anyone >>> else would like to give it a shot, I'd love to see this! >>> >>> >>> -- A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ --- You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group. To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/c12d0ef6-52af-41df-b8dd-ee967c5b8fc8%40googlegroups.com.
