hugin-0.8.0_rc1 released
Bruno Postle
Hash: SHA1
A hugin-0.8.0_rc1 (release candidate 1) tarball is available here:
https://sourceforge.net/project/showfiles.php?group_id=77506&package_id=311429
This is a release candidate, i.e. The final release may be
identical.
Changes since 0.8.0 beta4:
* Updated German and Simplified Chinese translations.
* Fix for photometric optimisation crash bug #2629418.
* Batch Processor now uses a socket for communication on Unix
systems.
* 'Save project and send to batch' now launches the Batch Processor
if it isn't already running.
* Batch Processor uses the Hugin language preference setting.
* Various other Batch Processor bugfixes.
* OS X minor XCode updates.
See README, ChangeLog and INSTALL_cmake for more information.
SHA1SUM: df0e871363c5e732e9d917ba096dca1400aa0f64 hugin-0.8.0_rc1.tar.gz
This release is equivalent to svn 3827, recent hugin binary
installers for testing can be found here:
http://panospace.wordpress.com/downloads/
- --
Bruno
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFKAKhzFqOhwCjyCLoRAmItAKCYCDKxD6bym3JsxjqBYRlYLgHBigCfTotZ
jJj+AcN6lcvsVSO3jzlTuic=
=5n5h
-----END PGP SIGNATURE-----
Bruno Postle
>
>Changes since 0.8.0 beta4:
>
>* Updated German and Simplified Chinese translations.
Most translations are now in a good state, except: Ukrainian,
Catalan and Brazilian Portuguese are very out-of-date. Bulgarian,
korean, Polish and Italian haven't been updated since 0.7.0.
The English release-notes are here, they probably won't change much
should anyone want to translate them:
http://hugin.sourceforge.net/releases/0.8.0/en.shtml
--
Bruno
Guido Kohlmeyer
There is still a bug in the OpenGL-Preview, in particular on detecting
OpenGL capabilities to do the difference view. On my OpenGL 1.3 system
(win32) it results in a crash of hugin if I move my mouse pointer over an
image part. I have a fix already on disk but not commited so far, see
below.
Furthermore the identify feature in OpenGL preview won't work properly on
Windows. The images are surrounded with a colored line but the buttons to
enable the images are not colored accordingly. So far as I know this is a
limitation of wxWidgets on Windows platform. After fixing the OpenGL
detection bug (see above) I tried to find a way to overcome this
limitation, cause it's in the same sources. Unfortunately there is no
simple solution available. I have some ideas to implement a button array
that is capable to show colored buttons, but this will take some
development time ... Damn I need some more free time.
To cut a long story short I guess the bug fix for OpenGL detection is
mandatory for the release. I will commit it probably on weekend. The
problem on identify tool is not a show stopper, although it is a little
drawback.
Guido
Lajos Höss
I currently testing the Hugin SVN3830 and libpano13 SVN 966 on UHU-Linux 2.1. Very good news,
now ptbachergui working (i will test more). I currently working on *.desktop file translate to hungarian.
I have some questions. This lines from hugin_stitch_project.desktop comment is correct in original english? :
---------------------
GenericName=Panorama batch stitcher
---------------------
I not know, this a batch processor? I only selectable one file, and stitch it correctly.
"Batch Processor uses the Hugin language preference setting", no, in Hugin ok, but ptbachergui use the system default language (hungarian).
Another questions, i not understand correctly, the original hu.po file fully updated to latest source? I find this script extract-messages.sh, run it, and i see new 3 fuzzy and 1 untranslated? This is a good method, or i forgot it?
Lajos
Frédéric COIFFIER
Starting program: /usr/bin/hugin
[Thread debugging using libthread_db enabled]
[New Thread 0xb61f8710 (LWP 26628)]
MainFrame::RestoreLayoutOnNextResize()
[Switching to Thread 0xb61f8710 (LWP 26628)]
wxWindow::DoSetSize (this=0x8b67e08, x=10, y=79, width=0, height=0, sizeFlags=<value optimized out>)
at /var/tmp/portage/x11-libs/wxGTK-2.8.9.2-r1/work/wxPython-src-2.8.9.2/src/gtk/window.cpp:2763
2763 /var/tmp/portage/x11-libs/wxGTK-2.8.9.2-r1/work/wxPython-src-2.8.9.2/src/gtk/window.cpp: No such file or directory.
in /var/tmp/portage/x11-libs/wxGTK-2.8.9.2-r1/work/wxPython-src-2.8.9.2/src/gtk/window.cpp
(gdb) bt
#0 wxWindow::DoSetSize (this=0x8b67e08, x=10, y=79, width=0, height=0, sizeFlags=<value optimized out>)
at /var/tmp/portage/x11-libs/wxGTK-2.8.9.2-r1/work/wxPython-src-2.8.9.2/src/gtk/window.cpp:2763
#1 0xb7380eee in wxSizerItem::SetDimension (this=0x8b6bf90, pos_=@0xbfe4a174, size_=@0xbfe4a16c)
at /var/tmp/portage/x11-libs/wxGTK-2.8.9.2-r1/work/wxPython-src-2.8.9.2/include/wx/window.h:225
#2 0xb7381779 in wxGridSizer::SetItemBounds (this=0x8b67cc0, item=0x8b6bf90, x=5, y=74, w=0, h=0)
at /var/tmp/portage/x11-libs/wxGTK-2.8.9.2-r1/work/wxPython-src-2.8.9.2/src/common/sizer.cpp:1385
#3 0xb7383162 in wxFlexGridSizer::RecalcSizes (this=0x8b67cc0) at /var/tmp/portage/x11-libs/wxGTK-2.8.9.2-r1/work/wxPython-src-2.8.9.2/src/common/sizer.cpp:1439
#4 0xb7380d13 in wxSizer::Layout (this=0x8b67cc0) at /var/tmp/portage/x11-libs/wxGTK-2.8.9.2-r1/work/wxPython-src-2.8.9.2/src/common/sizer.cpp:880
#5 0xb7380d7b in wxSizer::SetDimension (this=0x8b67cc0, x=5, y=74, width=0, height=0)
at /var/tmp/portage/x11-libs/wxGTK-2.8.9.2-r1/work/wxPython-src-2.8.9.2/src/common/sizer.cpp:976
#6 0xb7380f23 in wxSizerItem::SetDimension (this=0x8b6de70, pos_=@0xbfe4a298, size_=@0xbfe4a2a0)
at /var/tmp/portage/x11-libs/wxGTK-2.8.9.2-r1/work/wxPython-src-2.8.9.2/src/common/sizer.cpp:388
#7 0xb7381dc8 in wxBoxSizer::RecalcSizes (this=0x8b62150) at /var/tmp/portage/x11-libs/wxGTK-2.8.9.2-r1/work/wxPython-src-2.8.9.2/src/common/sizer.cpp:1751
#8 0xb7380d13 in wxSizer::Layout (this=0x8b62150) at /var/tmp/portage/x11-libs/wxGTK-2.8.9.2-r1/work/wxPython-src-2.8.9.2/src/common/sizer.cpp:880
#9 0x08154954 in GLPreviewFrame::panoramaChanged (this=0x8b58ef0, pano=@0x84ecb04)
at /var/tmp/portage/media-gfx/hugin-0.8.0_rc1/work/hugin-0.8.0/src/hugin1/hugin/GLPreviewFrame.cpp:517
#10 0x080b10b5 in PT::PanoramaObserver::panoramaChanged (this=0x8b590b4, pano=@0xffffffff)
at /var/tmp/portage/media-gfx/hugin-0.8.0_rc1/work/hugin-0.8.0/src/hugin1/PT/Panorama.h:178
#11 0xb7f0d0fe in HuginBase::Panorama::changeFinished (this=0x84ecb04, keepDirty=false)
at /var/tmp/portage/media-gfx/hugin-0.8.0_rc1/work/hugin-0.8.0/src/hugin_base/panodata/Panorama.cpp:1034
#12 0x080a7868 in huginApp::OnInit (this=0x84eca80) at /var/tmp/portage/media-gfx/hugin-0.8.0_rc1/work/hugin-0.8.0/src/hugin_base/panodata/Panorama.h:533
#13 0xb751c663 in wxEntry (argc=@0xb75e98cc, argv=0x84dbc88) at /var/tmp/portage/x11-libs/wxGTK-2.8.9.2-r1/work/wxPython-src-2.8.9.2/src/common/init.cpp:444
#14 0xb751c887 in wxEntry (argc=@0xbfe4a970, argv=0xbfe4a9f4) at /var/tmp/portage/x11-libs/wxGTK-2.8.9.2-r1/work/wxPython-src-2.8.9.2/src/common/init.cpp:472
---Type <return> to continue, or q <return> to quit---
#15 0x080a49fd in main (argc=0, argv=0x0) at /var/tmp/portage/media-gfx/hugin-0.8.0_rc1/work/hugin-0.8.0/src/hugin1/hugin/huginApp.cpp:87
Frédéric
Bruno Postle
>
>To cut a long story short I guess the bug fix for OpenGL detection is
>mandatory for the release. I will commit it probably on weekend. The
>problem on identify tool is not a show stopper, although it is a little
>drawback.
Ok, 'release candidate' just means that I'm not aware of any
'blocking' bugs (0.7.0 had six release candidates over six weeks
before we got something workable).
--
Bruno
Bruno Postle
>With this version, I get a crash when I start hugin (on Gentoo Linux) :
>/var/tmp/portage/x11-libs/wxGTK-2.8.9.2-r1/work/wxPython-
>src-2.8.9.2/src/common/init.cpp:472
>I have removed the old ~/.hugin file but it doesn't solve the problem.
I don't know what this, but is it intended that hugin is using
wxPython instead of wxWidgets?
--
Bruno
Bruno Postle
>
>I have some questions. This lines from hugin_stitch_project.desktop comment
>is correct in original english? :
>I not know, this a batch processor? I only selectable one file, and stitch
>it correctly.
hugin_stitch_project was labelled as 'batch processor' in this old
.desktop file because you could right-click on multiple .pto
projects and stitch them all in one go in separate instances of
hugin_stitch_project.
I'm going to delete this old .desktop file as the new
PTBatcherGUI.desktop does the same thing (but better since the jobs
are queued).
>Another questions, i not understand correctly, the original hu.po file fully
>updated to latest source? I find this script extract-messages.sh, run it,
>and i see new 3 fuzzy and 1 untranslated? This is a good method, or i forgot
>it?
This script is to be run when new strings are added to the code. It
hasn't been run since Feb 17, but no interesting strings have
changed since then so it isn't needed at the moment.
--
Bruno
James Legg
> Furthermore the identify feature in OpenGL preview won't work properly on
> Windows. The images are surrounded with a colored line but the buttons to
> enable the images are not colored accordingly. So far as I know this is a
> limitation of wxWidgets on Windows platform. After fixing the OpenGL
> detection bug (see above) I tried to find a way to overcome this
> limitation, cause it's in the same sources. Unfortunately there is no
> simple solution available. I have some ideas to implement a button array
> that is capable to show colored buttons, but this will take some
> development time ... Damn I need some more free time.
I've made a patch (attached) that should make the Identify tool more
useful on windows, and possibly satisfy feature request 2781075
(http://sourceforge.net/tracker/?func=detail&atid=550444&aid=2781075&group_id=77506 Identifying images in large pano doesn't work).
With this patch, when using the identify tool to find the image numbers,
the buttons for the images not under the mouse are hidden.
This means windows users can tell which images are under the mouse, but
cannot see which highlighted image belongs to which image number as the
buttons still look the same.
Also with large projects, it is very unlikely that you can't see all the
identified images' buttons highlighted. Before they would be mostly
hidden, as the buttons had a scrollable box where only a few were
visible.
If I get confirmation that this is acceptable on Windows (and doesn't
break anything on OS X?) I'll commit it to the trunk.
James
James Legg
> Also with large projects, it is very unlikely that you can't see all the
> identified images' buttons highlighted. Before they would be mostly
> hidden, as the buttons had a scrollable box where only a few were
> visible.
Hmmm... I've just found out the scrollable region here doesn't get
smaller. You can scroll the buttons to the right and the highlighted
buttons all shift off the screen to the left, so you are left with no
buttons visible at all.
It doesn't shrink when you start a new project and add a single image
either, even though the image button now fits on the screen without a
scrollbar.
This updated patch will scroll to the start of the buttons when needed
for the identify tool.
We should really set both previews' m_ButtonPanel correctly when images
are removed instead.
James
T. Modes
>
> I've made a patch (attached) that should make the Identify tool more
> useful on windows, and possibly satisfy feature request 2781075
>
> If I get confirmation that this is acceptable on Windows (and doesn't
> break anything on OS X?) I'll commit it to the trunk.
>
when moving the mouse.
What's about adding a wxPanel (for each button), putting the
wxToggleButton inside that wxPanel and change the backgroundcolor of
wxPanel? So you get a colored border around the button. This would
also allow to distinguish the different images under the mouse
pointer.
Thomas
Guido Kohlmeyer
> I find it a little bit nervous with the hiding and showing the buttons
> when moving the mouse.
> What's about adding a wxPanel (for each button), putting the
> wxToggleButton inside that wxPanel and change the backgroundcolor of
> wxPanel? So you get a colored border around the button. This would
> also allow to distinguish the different images under the mouse
> pointer.
>
I didn't tested the patch so far. My idea was to use a bitmap on the
buttons which content depends on the on/off state, mouse over and the
identify state. Following this approach it is possible to use some kind of
icons instead of simply description on the button. Quite similar to a film
strip.
Guido
T. Modes
> To cut a long story short I guess the bug fix for OpenGL detection is
> mandatory for the release. I will commit it probably on weekend. The
> problem on identify tool is not a show stopper, although it is a little
> drawback.
>
your patch doesn't work right.
* You check after glewInit():
if (GLEW_OK != err)
So your test will only run when glewInit failed. I think it should
be
if (GLEW_OK==err)
* In constructor GLPreviewFrame glewInit() fails on my machine (return
code is 1), but the call to glewInit() in GLViewer::GLViewer returns
Ok.
* The check if GL_ARB_imaging is available fails on my system, but the
difference tool works without problems (on my machine the subset
GL_EXT_blend_subtract is available which implements the necessary
difference function on OpenGL). So a check for GL_ARB_imageing or
GL_EXT_blend_substract should be done.
Thomas
Guido Kohlmeyer
> your patch doesn't work right.
meanwhile I see ...
>
> * You check after glewInit():
> if (GLEW_OK != err)
> So your test will only run when glewInit failed. I think it should
> be
> if (GLEW_OK==err)
Right
> * In constructor GLPreviewFrame glewInit() fails on my machine (return
> code is 1), but the call to glewInit() in GLViewer::GLViewer returns
> Ok.
Right, I guess the missing OpenGL context is a problem. The GLViewer
seems to have a context and glewInit() will work properly. I have to
analyse it ...
> * The check if GL_ARB_imaging is available fails on my system, but the
> difference tool works without problems (on my machine the subset
> GL_EXT_blend_subtract is available which implements the necessary
> difference function on OpenGL). So a check for GL_ARB_imageing or
> GL_EXT_blend_substract should be done.
I thought a simple check of the extension which covers the method is
sufficient, but after some investigations this is not the case.
OK, I have to go back to start and find a new solution. I will revert to
the old revision as recently as I have no other ideas.
Guido
Lukáš Jirkovský
thread) because I've quite busy times (AAAH exams are so close). So
I'm sorry that I'm replying soo late about one of the first topics in
this thread.
OK, back to the topic. I think better than hiding button for
non-present images is to have buttons in several rows if it's
necessary (and If there are really lots of them (so they would be
lets' say in 10 rows which would look terribly) possibly use the
hiding or scrollbars). IMHO it would satisfy the feature request
#2781075 on all platforms.
I've nothing to say about the identifying buttons on the windows,
because I don't not much about the problems.
Lukáš
Simon Oosthoek
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> A hugin-0.8.0_rc1 (release candidate 1) tarball is available here:
>
> https://sourceforge.net/project/showfiles.php?group_id=77506&package_id=311429
>
> This is a release candidate, i.e. The final release may be
> identical.
Hi Bruno & all
I've not had much time to keep up with the developments, but I
consistently get a segmentation fault when I try to load images into the
assistent panel. I'm running 64bit kubuntu intrepid 8.10.
Since a RC is out, I realise there's a good chance I've done something
wrong along the way, but I'm not sure what (made clean from svn sources)
Cheers
Simon
Bruno Postle
>
>I've not had much time to keep up with the developments, but I
>consistently get a segmentation fault when I try to load images into the
>assistent panel. I'm running 64bit kubuntu intrepid 8.10.
This is quite possible as there has been a lot of bugfixing lately.
Can you identify which stage of the process is failing? i.e. Load
Images or Align. If it is when opening files then we need to have
one of these photos to try and reproduce the problem.
If it is Align then all sorts of things happen: it runs one of the
external control-point finders, then Celeste, optimisation,
straightening, guessing output format, photometric optimisation,
finally (now) opening the Fast preview.
--
Bruno
Heikki Lehvaslaiho
One of the two computers, both running vanilla ubuntu 9.04, gives
some extra printout before seq fault:
> hugin
get fences failed: -1
param: 6, val: 0
Segmentation fault
Hope this helps finding the fault.
-Heikki
2009/5/11 Bruno Postle <br...@postle.net>:
-Heikki
Heikki Lehvaslaiho - skype:heikki_lehvaslaiho
cell: +27 (0)714328090
Sent from Cape Town, Western Cape, South Africa
Simon Oosthoek
> On Mon 11-May-2009 at 20:37 +0200, Simon Oosthoek wrote:
>> I've not had much time to keep up with the developments, but I
>> consistently get a segmentation fault when I try to load images into the
>> assistent panel. I'm running 64bit kubuntu intrepid 8.10.
>
> This is quite possible as there has been a lot of bugfixing lately.
>
> Can you identify which stage of the process is failing? i.e. Load
> Images or Align. If it is when opening files then we need to have
> one of these photos to try and reproduce the problem.
After I select a range of images in the file dialogue, hugin crashes
upun loading the first image. (See strace -f output below)
BTW, I installed hugin svn from the ubuntu instructions of the wiki on a
quite unspoiled ubuntu 8.04 LTS virtual machine (32bit) and there I
didn't have this problem at all.
If necessary I'll provide the images, but I don't think they're special,
as I've used them before in hugin (they're from 2004 I think, so they've
been through several versions of hugin ;-)
anyway, strace output....
[pid 24423] select(6, [5], [5], NULL, NULL) = 1 (out [5])
[pid 24423] writev(5,
[{"<\2\2\0\227\5\200\3\235\4\5\0\230\5\200\3\226\5\200\3v"..., 92},
{"H\2\6\4\232\5\200\3\233\5\200\3 \0 \0\0\0\0\0\0 \200\3"..., 4120}], 2)
= 4212
[pid 24423] select(6, [5], [5], NULL, NULL) = 1 (out [5])
[pid 24423] writev(5,
[{"<\2\2\0\233\5\200\3\235\4\5\0\234\5\200\3\232\5\200\3v"..., 1004}],
1) = 1004
[pid 24423] select(6, [5], [], NULL, NULL) = 1 (in [5])
[pid 24423] read(5,
"\1\1\205O\0\0\0\0\343\2\200\3\0\0\0\0P\350\266\5\0\0\0"..., 4096) = 32
[pid 24423] read(5, 0x1cdeaf4, 4096) = -1 EAGAIN (Resource
temporarily unavailable)
[pid 24423]
open("/terasaur/blackyroot/local/Photos/panorama/3/STA_2114.JPG",
O_RDONLY) = 14
[pid 24423] read(14,
"\377\330\377\341\31\376Exif\0\0II*\0\10\0\0\0\t\0\17\1"..., 8191) = 8191
[pid 24423] close(14) = 0
[pid 24423]
open("/terasaur/blackyroot/local/Photos/panorama/3/STA_2114.JPG",
O_RDONLY) = 14
[pid 24423] fstat(14, {st_mode=S_IFREG|0644, st_size=1236638, ...}) = 0
[pid 24423] mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fabb758a000
[pid 24423] read(14,
"\377\330\377\341\31\376Exif\0\0II*\0\10\0\0\0\t\0\17\1"..., 4096) = 4096
[pid 24423] read(14,
"\271m\3624\364-&\363RiZ\325\300\332\244H\245\302\3\317"..., 4096) = 4096
[pid 24423] close(14) = 0
[pid 24423] munmap(0x7fabb758a000, 4096) = 0
[pid 24423]
open("/terasaur/blackyroot/local/Photos/panorama/3/STA_2114.JPG",
O_RDONLY) = 14
[pid 24423] fstat(14, {st_mode=S_IFREG|0644, st_size=1236638, ...}) = 0
[pid 24423] mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fabb758a000
[pid 24423] read(14,
"\377\330\377\341\31\376Exif\0\0II*\0\10\0\0\0\t\0\17\1"..., 4096) = 4096
[pid 24423] lseek(14, -4094, SEEK_CUR) = 2
[pid 24423] lseek(14, 0, SEEK_SET) = 0
[pid 24423] close(14) = 0
[pid 24423] munmap(0x7fabb758a000, 4096) = 0
[pid 24423]
open("/terasaur/blackyroot/local/Photos/panorama/3/STA_2114.JPG",
O_RDONLY) = 14
[pid 24423] fstat(14, {st_mode=S_IFREG|0644, st_size=1236638, ...}) = 0
[pid 24423] mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fabb758a000
[pid 24423] read(14,
"\377\330\377\341\31\376Exif\0\0II*\0\10\0\0\0\t\0\17\1"..., 4096) = 4096
[pid 24423] lseek(14, -4094, SEEK_CUR) = 2
[pid 24423] lseek(14, 0, SEEK_SET) = 0
[pid 24423] close(14) = 0
[pid 24423] munmap(0x7fabb758a000, 4096) = 0
[pid 24423]
open("/terasaur/blackyroot/local/Photos/panorama/3/STA_2114.JPG",
O_RDONLY) = 14
[pid 24423] fstat(14, {st_mode=S_IFREG|0644, st_size=1236638, ...}) = 0
[pid 24423] mmap(NULL, 4096, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fabb758a000
[pid 24423] read(14,
"\377\330\377\341\31\376Exif\0\0II*\0\10\0\0\0\t\0\17\1"..., 4096) = 4096
[pid 24423] lseek(14, -4056, SEEK_CUR) = 40
[pid 24423] lseek(14, 0, SEEK_SET) = 0
[pid 24423] read(14, "\377\330\377\341\31\376Exif\0\0", 12) = 12
[pid 24423] read(14,
"II*\0\10\0\0\0\t\0\17\1\2\0\6\0\0\0z\0\0\0\20\1\2\0\24"..., 4096) = 4096
[pid 24423] read(14,
"\300\332\244H\245\302\3\317\334\367\317\245t\376\r\267"..., 4096) = 4096
[pid 24423] lseek(14, 8204, SEEK_SET) = 8204
[pid 24423] lseek(14, 8204, SEEK_SET) = 8204
[pid 24423] close(14) = 0
[pid 24423] munmap(0x7fabb758a000, 4096) = 0
[pid 24423] --- SIGSEGV (Segmentation fault) @ 0 (0) ---
[pid 24435] +++ killed by SIGSEGV +++
Process 24435 detached
Process 24423 detached
---------------------------------------------------------------
Cheers
Simon
Bruno Postle
>
>After I select a range of images in the file dialogue, hugin crashes
>upun loading the first image. (See strace -f output below)
It works ok here (linux i386) so I can't help. Hopefully somebody
else has an idea.
>BTW, I installed hugin svn from the ubuntu instructions of the wiki on a
>quite unspoiled ubuntu 8.04 LTS virtual machine (32bit) and there I
>didn't have this problem at all.
It sounds like an underlying library problem, maybe exiv2.
--
Bruno
Bruno Postle
>
>> * In constructor GLPreviewFrame glewInit() fails on my machine (return
>> code is 1), but the call to glewInit() in GLViewer::GLViewer returns
>> Ok.
>
>Right, I guess the missing OpenGL context is a problem. The GLViewer
>seems to have a context and glewInit() will work properly. I have to
>analyse it ...
I had a second machine where hugin segfaulted at startup as reported
by others. It seems that glewInit() can only be called once
depending on how glew is built:
http://glew.sourceforge.net/advanced.html
So I removed the call to glewInit() in GLPreviewFrame.cpp and it
seems to work ok.
I've committed this, though probably there is a better solution.
In particular I still don't have 'difference mode' available in the
fast preview, even though this did work about a month ago. Both
machines have no hardware acceleration, so the difference mode
worked fine with Mesa software rendering, but now it is disabled.
--
Bruno
Guido Kohlmeyer
> I had a second machine where hugin segfaulted at startup as reported
> by others. It seems that glewInit() can only be called once
> depending on how glew is built:
>
> http://glew.sourceforge.net/advanced.html
>
> So I removed the call to glewInit() in GLPreviewFrame.cpp and it
> seems to work ok.
>
> I've committed this, though probably there is a better solution.
>
> In particular I still don't have 'difference mode' available in the
> fast preview, even though this did work about a month ago. Both
> machines have no hardware acceleration, so the difference mode
> worked fine with Mesa software rendering, but now it is disabled.
>
I applied the approach to check whether the difference feature is
available in OpenGL implementation on the current machine. If so, I add
the difference feature to the drop-down list of the Preview window. Due to
the fact the detection didn't work as expected I can turn clock back and
create the drop-down list as before and leave only a check during runtime
of difference tool. Then hugin won't crash but the difference tool has no
function. Maybe better than a crash ...
Guido
Bruno Postle
>
>I applied the approach to check whether the difference feature is
>available in OpenGL implementation on the current machine. If so, I add
>the difference feature to the drop-down list of the Preview window. Due to
>the fact the detection didn't work as expected I can turn clock back and
>create the drop-down list as before and leave only a check during runtime
>of difference tool.
Ok, does this need more work? as I'd quite like to push out another
release candidate.
--
Bruno
Serge Droz
I did give the RC1 a try on the weekend under
Fedora 10, 64bit.
No Problems encounterted with either assembling stitiching Batch etc.
This obviously implies that it compiled fine.
Thanks for the effort
Serge
Alexandre Prokoudine
fails to work on files that are inside directories with cyrillic
names.
It says:
C:\Program\ Files\Hugin\bin\nona -z PACKBITS -r ldr -m TIFF_m -o 1111 -
i 0 C:\DOCUME~1\126C~1\LOCALS~1\Temp\hug16.tmp
ContractViolation:
Precondition violation!
Unable to open file 'C:\Documents and Settings\
Alexandre
Bruno Postle
>
>On a different note, I have a message from a Russian user that hugin
>fails to work on files that are inside directories with cyrillic
>names.
I'm sure this is the same bug there has been for a long time with
Windows and Russian/Czech codepages. Other languages are fine as
are OS X and Linux:
https://sourceforge.net/tracker/?func=detail&aid=1908349&group_id=77506&atid=550441
>ContractViolation:
>Precondition violation!
>Unable to open file 'C:\Documents and Settings\
--
Bruno
Harry van der Wolf
Could it be used to solve this bug?
Harry
Harry van der Wolf
Forgot to copy the link in: <http://trac.wxwidgets.org/ticket/5858>
Harry
Lukáš Jirkovský
in all newer wxWidgets. Anyway if I get right it's only fixing the
problem with showing the text in opened window.
Alexandre Prokoudine
> 2009/6/1 Harry van der Wolf <hvdw...@gmail.com>:
> I can see that it has been applied to the trunk, so it's most likely
> in all newer wxWidgets. Anyway if I get right it's only fixing the
> problem with showing the text in opened window.
Alexandre
Harry van der Wolf
2009/6/1 Harry van der Wolf <hvd...@gmail.com>:
> Sorry,
>
> Forgot to copy the link in: <http://trac.wxwidgets.org/ticket/5858>
>
> Harry
>
> 2009/6/1 Harry van der Wolf <hvd...@gmail.com>
>>
>> I suppose it has to do with the fact that linuxes and OSX use UTF-8 or
>> UTF-16 instead of these "old fashioned" codepages. There is a 6 year old
>> wxwindows "patch" that deals with that same 1251 codepage.
>> Could it be used to solve this bug?
>>
I can see that it has been applied to the trunk, so it's most likely
in all newer wxWidgets. Anyway if I get right it's only fixing the
problem with showing the text in opened window.
Sorry that I didn't make myself clear enough. I know it has been applied years ago to the public wxwindows releases and I know it has been done for a very specific purpose, and that purpose is not the same as the issue we are encountering now.
What I meant is: Can this "kind of patch" be used also for the issue we have right now?
Not being a programmer and certainly not into wxwindows, I can't judge it.
Harry
T. Modes
> enable the images are not colored accordingly. So far as I know this is a
> limitation of wxWidgets on Windows platform. After fixing the OpenGL
> detection bug (see above) I tried to find a way to overcome this
> limitation, cause it's in the same sources. Unfortunately there is no
> simple solution available. I have some ideas to implement a button array
> that is capable to show colored buttons, but this will take some
> development time ... Damn I need some more free time.
>
buttons into a panel. This allows to color the panel to get a coloured
border around the button when working with the identify tool. I
activated this colouring only on windows. On linux the whole button is
coloured as it was.
Maybe this new function could also help under Mac: In
GLPreviewFrame::SetImageButtonColour there is a comment that
background color isn't working for toggle button. The same is true for
windows. So somebody on mac could give it a try (you have to modify
the conditional compiler switches in
GLPreviewFrame::SetImageButtonColour and
GLPreviewFrame::CleanButtonColours).
Thomas