[hugin-ptx] [BUG] Segfault with unset

[Manuel Presnitz]

Hi,

sorry for not reporting the bug via Launchpad, but after several attempts to 
create an Ubuntu One
account I gave up.

However, I get a seg fault when starting hugin on two different machines.


Details
---

hugin version 2021.0.0-4
Arch Linux; up-to-date as of today, July 18th
custom kernel 5.18.3


Steps to reproduce
--

To reproduce the crash it is sufficient on my machines to unset the env 
variable XDG_DATA_HOME, so:

$ unset XDG_DATA_HOME
$ hugin

(...)
(hugin:3437): Gtk-CRITICAL **: 21:30:24.701: gtk_widget_set_size_request: 
assertion 'height >= -1' failed
/usr/share/hugin/data/plugins/top_five.py
   CAT:Control Points
   NAM:keep 5 CPs per image pair
   fails @api-max
/usr/share/hugin/data/plugins/woa.py
   CAT:Control Points
   NAM:Warped Overlap Analysis
   fails @api-max
/usr/share/hugin/data/plugins/woa.py
   CAT:Control Points
   NAM:Warped Overlap Analysis
   fails @api-max
zsh: IOT instruction (core dumped)  hugin


Investigation
-

Using gdb I got this backtrace:

Thread 1 "hugin" received signal SIGSEGV, Segmentation fault.
0x7531f9b4 in hugin_utils::GetUserAppDataDir[abi:cxx11]() () at 
/usr/users/presnitz/hugin/src/hugin-2021.0.0/src/hugin_base/hugin_utils/utils.cpp:475
475 if (strlen(xdgDataDir) == 0)
(gdb) bt
#0  0x7531f9b4 in hugin_utils::GetUserAppDataDir[abi:cxx11]() ()
at 
/usr/users/presnitz/hugin/src/hugin-2021.0.0/src/hugin_base/hugin_utils/utils.cpp:475
#1  0x556d0fb6 in MainFrame::MainFrame(wxWindow*, HuginBase::Panorama&) 
(this=0x55f15dc0, parent=0x0, pano=...)
at 
/usr/users/presnitz/hugin/src/hugin-2021.0.0/src/hugin1/hugin/MainFrame.cpp:475
#2  0x556bb901 in huginApp::OnInit() (this=0x55b4a590)
at 
/usr/users/presnitz/hugin/src/hugin-2021.0.0/src/hugin1/hugin/huginApp.cpp:372
#3  0x556bfc15 in wxAppConsoleBase::CallOnInit() (this=0x55b4a590) 
at /usr/include/wx-3.2/wx/app.h:93
#4  0x7670efe2 in wxEntry(int&, wchar_t**) () at 
/usr/lib/libwx_baseu-3.2.so.0
#5  0x556ba87d in main(int, char**) (argc=1, argv=0x7fffd318)
at 
/usr/users/presnitz/hugin/src/hugin-2021.0.0/src/hugin1/hugin/huginApp.cpp:152


This gave me the hint that the seg fault is connected with XDG_DATA_HOME. And 
yes, after defining
XDG_DATA_HOME (empty string or some sensible value) hugin starts as expected :)

So, a workaround for my setup is:

$ export XDG_DATA_HOME=""
$ hugin


Additional Information
--

For the sake of completeness I attach hugin's error-report xml file and list my 
version numbers of
the packages, Arch says that hugin directly depends on:

xwidgets-gtk3 3.2.0-3
boost-libs 1.79.0-1
libtiff 4.4.0-1
libpano13 2.9.21-1
libjpeg-turbo 2.1.3-2
libpng 1.6.37-3
openexr 3.1.5-1
vigra 1.11.1.r67+g093d57d1-3
exiv2 0.27.5-3
glew 2.2.0-3
sqlite 3.39.1-1
lcms2 2.13.1-1
lapack 3.10.1-1
fftw 3.3.10-3
glu 9.0.2-3
libxi 1.8-1
libxmu 1.1.3-3
python 3.10.5-1
lensfun-git 0.3.3.815-1
enblend-enfuse 4.2.r1524+h4c30a326b3f4-2



Best regards,
Manuel.

-- 
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/202207182139460682.0015867F%40gateway.core.mpy.ch.


  
  




  
  











  

Re: [hugin-ptx] bug linefind and edge of image

[Gnome Nomad]

I mentioned it and you addressed the apparent fact that we were getting 
essentially TWO footers on each message ... thanks.


A link to LaunchPad might make bug reporting easier for anyone interested.

On 07/01/2013 11:03 PM, Carl von Einem wrote:

Hi,

I somehow remember that you complained about the length of this mailing
list's footer (being the one who adds a much longer own footer to every
one liner).

The Hugin FAQ mentioned in each message has some hints about bug
reporting, I'll add a direct link to launchpad now for your convenience.

Carl

Gnome Nomad schrieb am 02.07.13 10:47:

On 07/01/2013 07:39 AM, Jim Watters wrote:

linefind will find vertical lines that are the edge of the image. When
the camera has a tilt this is really bad.


Hmmm, I don't think this mailing list is the place to report bugs ...
sorry, don't know where the official bug report site is.


--
David W. Jones
gnomeno...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com
http://www.clanjones.org/david/
http://dancing-treefrog.deviantart.com/
http://www.cafepress.com/otherend/

--
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/51D3D65F.1080602%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [hugin-ptx] bug linefind and edge of image

[Gnome Nomad]

I've also never noticed linefind finding vertical lines at the edge of 
images - if by that you mean it finds the edge of the image as a 
vertical line, even if it's not a vertical line in the image?


You're right, there are many more eyes on the list than Launchpad. But 
putting it on Launchpad more explicitly calls for a developer to look at it.


On 07/02/2013 12:55 AM, Jim Watters wrote:

I can add it to Lanchpad.

The bug happened while working on a project for a client. I don't have
permission to submit the images yet. I was hopping to get conformation
or a workaround. There are many more eyes on this list than Lanchpad.

Jim


Gnome Nomad schrieb am 02.07.13 10:47:

On 07/01/2013 07:39 AM, Jim Watters wrote:

linefind will find vertical lines that are the edge of the image. When
the camera has a tilt this is really bad.


Hmmm, I don't think this mailing list is the place to report bugs ...



--
David W. Jones
gnomeno...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com
http://www.clanjones.org/david/
http://dancing-treefrog.deviantart.com/
http://www.cafepress.com/otherend/

--
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/51D3D5E2.2030603%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [hugin-ptx] bug linefind and edge of image

[Jim Watters]

I can add it to Lanchpad.

The bug happened while working on a project for a client. I don't have 
permission to submit the images yet. I was hopping to get conformation or a 
workaround. There are many more eyes on this list than Lanchpad.


Jim


Gnome Nomad schrieb am 02.07.13 10:47:

On 07/01/2013 07:39 AM, Jim Watters wrote:

linefind will find vertical lines that are the edge of the image. When
the camera has a tilt this is really bad.


Hmmm, I don't think this mailing list is the place to report bugs ...





--
Jim Watters
http://photocreations.ca

--
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/51D2B1A7.6000906%40photocreations.ca.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [hugin-ptx] bug linefind and edge of image

[Carl von Einem]

Hi,

I somehow remember that you complained about the length of this mailing 
list's footer (being the one who adds a much longer own footer to every 
one liner).


The Hugin FAQ mentioned in each message has some hints about bug 
reporting, I'll add a direct link to launchpad now for your convenience.


Carl

Gnome Nomad schrieb am 02.07.13 10:47:

On 07/01/2013 07:39 AM, Jim Watters wrote:

linefind will find vertical lines that are the edge of the image. When
the camera has a tilt this is really bad.


Hmmm, I don't think this mailing list is the place to report bugs ...
sorry, don't know where the official bug report site is.



--
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/51D2977C.6030605%40einem.net.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [hugin-ptx] bug linefind and edge of image

[Lukas Jirkovsky]

On 2 July 2013 10:47, Gnome Nomad  wrote:
> On 07/01/2013 07:39 AM, Jim Watters wrote:
>>
>> linefind will find vertical lines that are the edge of the image. When
>> the camera has a tilt this is really bad.
>
>
> Hmmm, I don't think this mailing list is the place to report bugs ... sorry,
> don't know where the official bug report site is.

It's on Launchpad: https://launchpad.net/hugin

-- 
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/CAFa9FQvp6CwC%2BFNutBrxAWXK677s21z6SMi_Z7zLhDm8FsV69A%40mail.gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [hugin-ptx] bug linefind and edge of image

[Gnome Nomad]

On 07/01/2013 07:39 AM, Jim Watters wrote:

linefind will find vertical lines that are the edge of the image. When
the camera has a tilt this is really bad.


Hmmm, I don't think this mailing list is the place to report bugs ... 
sorry, don't know where the official bug report site is.


--
David W. Jones
gnomeno...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com
http://www.clanjones.org/david/
http://dancing-treefrog.deviantart.com/
http://www.cafepress.com/otherend/

--
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/51D293B5.4060503%40gmail.com.
For more options, visit https://groups.google.com/groups/opt_out.

[hugin-ptx] bug cpclean and line control points

[Jim Watters]

cpclean will not remove bad line control points.
and if -s is used to not optimize, then no control points are removed.
In the case of this project the 7 worst control points are line control points.
Adding -n 1 to remove more control points still did not remove any when the -s 
is used.




cpclean "$panoDir.pto" -w -s -o "$panoDir.2.pto"

Skipping optimisation, current image positions will be used.

Removed 0 control points in step 2

Written output to panorama.2.pto

=

cpclean "$panoDir.pto" -w -o "$panoDir.3.pto"
Optimizing Variables
Strategy 1
...
Removed 7 control points in step 2

==

cpclean "$panoDir.pto" -w -n 1 -o "$panoDir.4.pto"
Optimizing Variables
Strategy 1
...
Removed 48 control points in step 2

==

cpclean "$panoDir.pto" -w -s -n 1 -o "$panoDir.5.pto"

Skipping optimisation, current image positions will be used.

Removed 0 control points in step 2

--
Jim Watters
http://photocreations.ca

--
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/51D1BF04.6020303%40photocreations.ca.
For more options, visit https://groups.google.com/groups/opt_out.

[hugin-ptx] bug linefind and edge of image

[Jim Watters]

linefind will find vertical lines that are the edge of the image. When the 
camera has a tilt this is really bad.


--
Jim Watters
http://photocreations.ca

--
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/51D1BEC8.2060607%40photocreations.ca.
For more options, visit https://groups.google.com/groups/opt_out.

[hugin-ptx] bug pto_var unlink link

[Jim Watters]

pto_var version 2013.0.0.70b10450ff94 built by Matthew Petroff, tested on 
Windows.

The pto_var with unlink changes all images not just the one being unlinked.

pto_var --unlink v5,v4 project.pto, only the v of images 5 and 4 should be 
unlinked but all are.
pto_var --unlink a1,b1,c1 project.pto, only the a, b, c of image 1 should be 
unlinked but a, b, and c of all images are unlinked.


All images of the project are unlinked.
This could be the default behavior if no image is given.
pto_var --unlink v project.pto

Also --link varlist does not provide a method to set how the variable is linked. 
Always links to image 0.

pto_var --link a1,b1,c1
This make more sense
pto_var --link a2=1,b2=1,c2=1 project.pto


--link would not be necessary if this was possible.
pto_var --set a2==1,b2==1,c2==1 project.pto

Unlink is still useful because it offers a easy method to assign the linked 
value.

I did not try all variables.

-- Jim Watters
http://photocreations.ca

--
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/51BFD08F.1040709%40photocreations.ca.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [hugin-ptx] [bug#678842] Stitcher canvas size, proportional change not bidirectional

[Bruno Postle]

Yes it is necessary to be able to change vertical field of view
independently of horizontal field of view - this is the only way to change
the panorama aspect ratio. If there is a bug it is that both sliders should
be completely independent.

-- 
Bruno
On 31 Mar 2011 07:50, "Neeraj Gupta"  wrote:

-- 
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] [bug#678842] Stitcher canvas size, proportional change not bidirectional

[Neeraj Gupta]

Hi,
I was looking at this[https://bugs.launchpad.net/hugin/+bug/678842 ]
particular bug description :

*Changing the horizontal canvas size in the Stitcher results in a
corresponding proportional vertical canvas size just as would be expected.
The same is not true when changing the vertical canvas size. A vertical
canvas size change does not change the horizontal canvas size and in fact
appears to function as a crop.*

I have two questions:-
1. Is it really a bug? (read details below).
2. If yes, then please give suggestions how I should rectify it.

Initially after looking at Panopanel.cpp[1] file especially function at
Canvas Width and Height events(Line 73,74) and then looked for their
respective functions i.e. WidthChange[2] and HeightChange[3], I thought
there is just a typo in line 686(inside Height()) as it seemed that the
author missed to include m_KeepViewOnResize as its present in WidthChange
funtion), but build gave invalid parameter error for HeightChange funtion.

So, I looked for their declaration and there I saw that the original author
has coded it that way( I am assuming that he meant to do it in this way only
as it does seems to be *just missed it* case.).
Please see the definitions of HuginBase::PanoramaOptions::setWidth[4] and
SetHeight[5].

If it needs to be modified, then please suggest me what formula's and
condition should I use to modify the horizontal canvas size as I don't have
much knowledge of this

Regards

Neeraj

[1] 
http://hugin.sourceforge.net/docs/html/PanoPanel_8cpp-source.htmlPanoPanel.cpp
[2] 
http://hugin.sourceforge.net/docs/html/PanoPanel_8cpp-source.html#l00662Func-WidthChange
[3] 
http://hugin.sourceforge.net/docs/html/PanoPanel_8cpp-source.html#l00679Func-
HeightChange
[4]
http://hugin.sourceforge.net/docs/html/PanoramaOptions_8cpp-source.html#l00253SetWidth
[5]
http://hugin.sourceforge.net/docs/html/PanoramaOptions_8cpp-source.html#l00293SetHeight

-- 
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] Bug

[Bart van Andel]

Probably related: out of curiosity I've played around a bit with a test 
makefile to try different special characters in target names. I've added the 
resulting test.mk as an attachment to bug "Stitching fails with '&' 
character in path" [0].

[0] https://bugs.launchpad.net/hugin/+bug/679353

--
Bart

-- 
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] Bug

[Bruno Postle]

On Wed 16-Mar-2011 at 15:19 -0700, ChrisM wrote:
Not sure if this is known about, but if the file name includes an 
ampersand (&) character the preview loads but the stitch phase 
crashes.  Easily solved by changing to a plus (+) but had me 
wondering why it wouldn't work for a while!


Confirmed, this is bug with output filenames (input files and 
foldernames are fine): https://bugs.launchpad.net/hugin/+bug/737224


--
Bruno

--
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] Bug

[Carl von Einem]

Hi.

ChrisM schrieb am 16.03.11 23:19:

Not sure if this is known about, but if the file name includes an
ampersand (&) character the preview loads but the stitch phase
crashes.  Easily solved by changing to a plus (+) but had me wondering
why it wouldn't work for a while!


The Hugin FAQ 
 has 
something about it. Interesting to see that the plus sign worked for you 
but I think it's still a good recommendation to only use 'standard' 
characters in file and folder names, see 
.



Awesome program though, I can't seem to go anywhere now without taking
at least one "panoramic" set of images!


That's a good (and pretty 'normal') sign but not yet covered in the FAQ ;-)

Carl

--
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] Bug

[ChrisM]

Not sure if this is known about, but if the file name includes an
ampersand (&) character the preview loads but the stitch phase
crashes.  Easily solved by changing to a plus (+) but had me wondering
why it wouldn't work for a while!

Awesome program though, I can't seem to go anywhere now without taking
at least one "panoramic" set of images!

-- 
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] BUG [679337] Feedback welcome

[Gerry Patterson]

Hello,

Bellow is a comment I made regarding this bug which is sent out the
hugin-bug-hunters team.  I am posting it here as well as other might have
more insight.


The bug is:Camera response not assigned to the correct
image?

= report:==

Hugin apparently gives the wrong camera response to images, depending on the
first image in the panorama.

Steps to reproduce:
1. Open Hugin
2. Add any two images
3. Assign a different camera to the second image
4. Change the camera response in the first image (for example, enter 5 in
the bottommost box)
5. Look at the two images in the normal preview
5. Save pto file and generate with nona the two "remapped" files

Expected result: the preview of the first image and its remapped image has a
strange color

Outcome: in the normal slow preview the first image is unchanged and the
second one has a very strange color. The same is true for the remapped
images. The GL preview (with Photometrics applied) shows the correct colors
for the second image.

Fix: move up the second image (in the Images tab). Both bugs (in the output
and in the preview) are fixed.

= my comment:==

I have looked into the code on this. I am not familiar with what is supposed
happen but I have a guess:

When one takes a panorama with a single camera with a single response curve,
the output image will use this response curve as well.

When one takes a panorama with multiple cameras, each with their own
response curve, one of the response curves is chosen to be the one which all
others are referenced to. These are the "output" EMoR parameters, as they
are described in the code. Right now, these are hard coded to be whatever
set of parameters are used for the first image. Both nona and the slow
preview enforce this. This is why, when you change the EMoR parameters for
the first image (or any image who's EMoR parameters are linked to the first
image) all other images change since they are either using these new EMoR
parameters (same lens) or their response curve is referenced to the first
image.

However, in the case of the fast preview, while it generates the LUT for the
output response curve, it is always for a output EMoR parameter set of
0,0,0,0,0. I think this is a bug and I have a patch which makes it behave
the same as the rest of the system.

However, I am thinking it would make sense to expose the choice of which
response curve to use as the output one instead of always picking the one
associated with the first image in the list. Similar to how anchor for
exposure and anchor for position are used in the images tab.

Feedback is welcome here

- Gerry

-- 
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] Bug Tracker: proposal for migration

[Yuval Levy]

On October 31, 2010 01:37:25 pm David Haberthür wrote:
> For me personally, the move of the translation infrastructure to Launchpad
> would make me help translate with the languages I speak.

quite a different subject,  but worth researching.  We'd have to figure out how 
to map LP's translate functionality onto Hugin's po files and how to integrate 
the whole thing with the repository.

not the highest priority for me, but if it is a superior translation method 
that will help translators, why not implement it at some point in the future?

Yuv


signature.asc
Description: This is a digitally signed message part.

Re: [hugin-ptx] Bug Tracker: proposal for migration

[David Haberthür]

Dear all.

On 26.10.2010, at 20:31, Yuval Levy wrote:

> Hi all
> 
> [snip]
> 
> So I looked for alternatives, and my recommendation is:  let's move on to 
> *Launchpad*.  It enables users to not only contribute bugs, but also to work 
> on their triaging and getting more involved.

I can't really comment on the bugtracker, since I've got no good grasp of it. 
One thing that I'd welcome though in the process of migration to Launchpad is 
the added benefit of the translation possibilities.

I've suggested this quite some time ago [1]. Let me clarify my idea, also in 
the context of Brunos (then) reply. I've never helped with the translation of 
hugin (as far as I remember), but have helped a bit with both Miro [2] and Make 
Internet TV [3], even though I don't use them in German. Why? Because it's very 
easy for me to also just translate one string while waiting for some other task 
to finish (for example at work). I don't have to download a .po file [3], 
translate it in POEdit, save it and attach it to the tracker or email it to 
Bruno and Pabo. I just go to the web-interface and translate one string, press 
save and am done.

For me personally, the move of the translation infrastructure to Launchpad 
would make me help translate with the languages I speak.

Again, as on March 13, 2009, just my 2 Cents.
Have a nice sunday evening (at least here in Europe :)
Habi


[1]: 
http://groups.google.com/group/hugin-ptx/browse_thread/thread/5c0d5d145f7518a7/dda47867443a2502?lnk=gst&q=launchpad+translation#dda47867443a2502
[2]: https://launchpad.net/democracy
[3]: https://launchpad.net/pcf-mitv
[4]: but can, if I want.

-- 
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] Bug Tracker: proposal for migration

[Yuval Levy]

Hoi Harry,


finally some real business.

On October 27, 2010 10:32:22 am Harry van der Wolf wrote:
> As far as I understand one of the main reasons you want to move to another
> bugtracker is to involve more users to the bugtracking process.

it would be a benefit but from my perspective it is not one of the main reason.

The main reasons are, in order of importance:
1. sort
2. search
3. clutter
4. convoluted user interface
5. latency

Which all boils down to *the* reason:  work through the bug reports faster and 
more efficiently.

A side effect of improving them is that the interaction can actually be more 
fun and maybe attract more users to the bug tracking process, but I'd be happy 
if the process is improved for the current bug tracker users.

We currently have an imbalance, with more users feeding bugs than users 
processing and fixing them.  Improving the infrastructure will hopefully linder 
the imbalance.


1. SORT

per default, SF display bugs of *any* status.  This means that you first have 
to waste the time of an http request (see 4) only to exclude the 800+ closed 
bugs that you don't want to see 99% of times you access the bug tracker.

SF offers a single priority and a single category.  So if you and I have 
different priority for a bug, we have a problem.  It's a way to say: sorry, 
this field is being set by the developer, you, user, have nothing to do with 
it.  The solution is: *tags*.  Not available in the SF bug tracker.


2. SEARCH

A respectful user will first search if a bug is already reported, and confirm 
that report.  On SF, all of this is manual, the infrastructure does not 
support it.  On LP, search is everywhere.  Users are made aware of existing 
bugs that may be related to what they enter based on what they entered.  The 
tool does the job for you.


3. CLUTTER

Two type of bug reports are particularly cluttering the SF bug tracker:  FAQs 
and duplicates (and duplicates of FAQs).

It can happen that a user forgot the FAQ, or that he is reporting a new FAQ.  
On SF, you need to answer manually, close the bug, and it stays there and 
clutter your initial view forever.

On LP, the report can be moved to an Answer, and becomes a FAQ automatically, 
no need to log into the wiki afterward to update the FAQ manually. 

Duplicates stays in SF's initial view, even after they have been identified as 
such.  In LP they disappear, becoming a link/footnote in the main bug report.


4. CONVOLUTED USER INTERFACE

The initial view of the SF tracker is useless.  It lists all bugs ever 
entered, no matter what status they have.  LP has thought well to optimize the 
initial view with what is relevant to you.

When looking at  a bug report on LP, the sequence of comment is simply 
scrollable, in sequence.  In SF's tracker comments are hidden under some of 
the most useless JavaScript I have ever seen.


5.  LATENCY

It's important that a web app is fast and responsive.  AFAIK SF is on the West 
Coast.  I am closer to their server than to LP's (AFAIK in the UK) and yet I 
consistently experience slow HTTP requests to SF, not to LP.  Even when I am 
motivated to work through the UI mess, it is slow, painful and unproductive.  
SF resources are  overused/undersized.  Sometimes it gets better sometimes it 
gets worse.


> I'm affraid users won't be more involved.

Maybe, but that's not what I am aiming for at first.  I want to see the 
existing pile of bugs worked down to a manageable size,  Already having it 
displayed by default in a usable format would be an improvement.

All things being equal, LP is more enticing to users.  Any user can tag any 
bug, without having to fight with other users about category or priority.  
Users receive Karma points for interacting with LP.  The email messages from 
LP are more relevant, inviting a click through to continue the thread.

That said, I agree that if the goal is to attract users to the bug tracker, 
there are better means to reach it.

At the moment I am actually fearful of attracting more users to the 
*reporting* end of the bug tracker because there are few people processing the 
bugs on the other end.  Reports just pile up and make the work of those 
triaging the bugs and those hunting and fixing them more cumbersome.

I wish we can go the same curve as Inkscape, and in the space of a couple of 
months reduce the amount of open bug reports by at least 75%.


> I think
> it's more important to inform and "educate"  the users, than to switch to
> another bugtracker to solve that.

Those are two different things.  And it is easier to "educate" the users with a 
better performing bug tracker, like it is easier to attract developer with a 
state of the art SCM.


> However, the
> new, shiny polish might wear off and then we are at the same position where
> we are with the current bug tracker: not enough user involvement  (and I'm
> one of those users who is only involved from time to time).

Nope.  We're with a better bug tracker that enables the 

Re: [hugin-ptx] Bug Tracker: proposal for migration

[Harry van der Wolf]

Hi,

I have no objections against launchpad, for what I know of it. I don't know
Mantis or other bug trackers.

As far as I understand one of the main reasons you want to move to another
bugtracker is to involve more users to the bugtracking process.  This would
be a good thing. However, I'm affraid users won't be more involved. I think
it's more important to inform and "educate"  the users, than to switch to
another bugtracker to solve that. The only thing that might help is that
it's new. People are always and easily attracted to new, shiny, improved
gadgets so that might be true for a new bugtracker as well. However, the
new, shiny polish might wear off and then we are at the same position where
we are with the current bug tracker: not enough user involvement  (and I'm
one of those users who is only involved from time to time).

If the SF bugtracker is exported from SF into Launchpad we will still have
all our bugs and feature requests. From a principal point of view I would
say that we should clean up first (and yes I know: this "we" is exactly what
didn't work in the past). I will do my best for the OSX relevant tickets.
On the other hand: If users are attracted to the new bug tracker, this
intitial boast might result in geting rid of the too many tickets as well.

I really appreciate your efforts to keep the community moving forward and as
such I think this is another good step forward, but please give us a little
more time than 2-3 weeks. (I assume you also spend a little more time on
it.)
Currently I have holidays but I'm at the same time limited in my computer
time. So this week I certainly won't have time to investigate bugs/features
and/or bug trackers.

Hoi,
Harry

-- 
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] Bug Tracker: proposal for migration

[Yuval Levy]

Hi Carl,

On October 26, 2010 07:39:56 pm Carl von Einem wrote:
> you are not really suggesting an alternative here but stating that you
> would move if others don't follow your personal timetable - is this
> really Open Source (thinking | behaviour)?

You may want to re-read my proposal and reword your false statement. 

1.  Yes, I am suggesting an alternative:  the status quo.

2. I never stated that "I would move if others *don't* follow my personal 
timetable".

I repeat my statement:  I will move the bug tracker *if* *there* *are* *no* 
*objections*.

If there are objections the project will stay with the status quo until these 
objections are discussed and solved.  Exactly like I did with the repository 
move from Subversion to Mercurial earlier this year.

Yes, it is Open Source (thinking | behavior).  Open Source is a meritocracy, 
not a democracy.  As such not all statements, objections, people are equal.

You will forgive me for seeing no merit whatsoever in Dale's comments, given 
his track record as "contributor".

Serious objections will be considered for their merits.  Some will be 
summarily dismissed, others will be discussed.  Some will lead to changes, 
others will be ignored.  In the end there will be some sort of consensus, one 
way or another.

For now the plan is:
- test the Launchpad bugtracker (when it will be ready)
- decide if adopt it or keep the status quo

As usual in Open Source, the plan is subject to change.  There may be a show 
stopper.  There may be better alternatives/proposals.  For now, the two above 
are the only viable alternatives.

Everybody is welcome to make a valid and complete alternative proposal, and if 
valid arguments are presented, the plan will change.

To be viable and worth considering, an alternative proposal must include, 
amongst others:
- considerations of the impact on the project's resources
- migration of the actual bug tracker data into the new tool
- migration from the new tool (data export), just in case Hugin outgrows it
- a live test, possibly with real data from Hugin's bug tracker to enable 
contributors to get a feel for how life with the new tool might be

This list is not comprehensive and it is the responsibility of whoever 
proposes the alternative to do the actual work or find somebody willing to do 
it.


> What's making your proposal so urgent? It looks to me as if you found a
> solution for your personal problem but it seems you don't care to
> discuss other thoughts about the matter.

Nothing urgent, really.  Like with most things in Open Source, there are more 
things to do than resources to do them, and when one thing is mature, it gets 
done so we can move on to the next thing.

Yes, I am scratching my own itches, if you want to call an itch a problem.  
Been doing that for the past four years and it worked quite well.  To me an 
itch is a feeling of being alive, a challenge, not a problem.  That's Open 
Source.

I had stated my goals for the Hugin project long time ago: to increase the 
pace of development, the capacity of the project to absorb change and move 
forward, setting free the talented developers that gravitate to the project to 
scratch their own itches and build into Hugin the best code they can, setting 
Hugin free and making it viable to evolve indefinitely and develop its full 
potential.  There is still so much to develop.

It is in that optic that I

* successfully established Hugin as a Google Summer of Code mentoring 
organization in 2007, leading to the recruiting of more than a dozen talented 
contributors and the implementation of their ideas into valuable 
functionalities

* re-engineered project communication to increase the exchanges on this 
mailing list

* initiated and contributed to the build documentation that enabled countless 
users to start from scratch and roll their own build - one of the main ways to 
recruit significant contributors (and there is still work to do in this area, 
as Kay correctly pointed out) since 2008.

* restructured the subversion repository, separating development from release 
management setting the development free to move forward faster in 2009.

* redesigned the release process in 2009 after it had become a bottleneck for 
all the goodies produced by all the talented contributors to become actual 
functionality on the user's desktop, leading to a series of successful, 
predictable, stable, exciting releases that have lifted Hugin to a level of 
popularity it had never seen before.  And there is more to come, hopefully 
with no end in sight.

* introduced and later formalized a community charter, liberally granting 
repository write access to dozens of contributors, empowering them to do more.

* Moved the code base from Subversion to Mercurial, giving it an additional 
degree of freedom, redundancy, resilience, flexibility to absorb even more 
development in 2010 after distributed SCM reached a sufficient maturity level. 

I've been biting at the bug tracker and its

Re: [hugin-ptx] Bug Tracker: proposal for migration

[Carl von Einem]

Hi Yuv,

you are not really suggesting an alternative here but stating that you 
would move if others don't follow your personal timetable - is this 
really Open Source (thinking | behaviour)?


What's making your proposal so urgent? It looks to me as if you found a 
solution for your personal problem but it seems you don't care to 
discuss other thoughts about the matter.


I worked with Mantis in the late 90ies and "just" from a user's POV I 
liked it a lot. That was an installation on an internal system but it 
should also work on hosted space.


And I'm not sure that software bugs get irrelevant just because they 
don't find someone who hunts them in a certain time. They don't die, 
they are still in the code.


I wonder if this now makes me a member of your list of "who moved my 
cheese"-characters (as you wrote in another thread). You don't want more 
governance for yourself, right?


Carl


Yuval Levy schrieb am 27.10.10 00:08:

On October 26, 2010 05:05:38 pm Dale Beams wrote:

Sounds like proprietary software path, where choices are limited by the
cathedral method and not open for voting.


You need  an hearing aid.  This is the sound of Open Source, where choices are
limited by the available resources.  If you are willing to provide an
implemented  migration path from the existing bug tracker to whatever you are
suggesting as alternative, I am willing to add it to the list of available
choices for the project.

Yuv


--
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] Bug Tracker: proposal for migration

[Yuval Levy]

On October 26, 2010 05:05:38 pm Dale Beams wrote:
> Sounds like proprietary software path, where choices are limited by the
> cathedral method and not open for voting.

You need  an hearing aid.  This is the sound of Open Source, where choices are 
limited by the available resources.  If you are willing to provide an 
implemented  migration path from the existing bug tracker to whatever you are 
suggesting as alternative, I am willing to add it to the list of available 
choices for the project.

Yuv


signature.asc
Description: This is a digitally signed message part.

Re: [hugin-ptx] Bug Tracker: proposal for migration

[Dale Beams]

Sounds like proprietary software path, where choices are limited by the
cathedral method and not open for voting.

On Tue, 2010-10-26 at 16:02 -0400, Yuval Levy wrote:
> On October 26, 2010 03:27:39 pm Dale Beams wrote:
> > Hugin !== Ubuntu or Kubuntu
> 
> read the proposal: "for all platforms"
> 
> 
> > Personally I like Mantis, have enjoyed using it, and it's very
> > successful for projects much larger than hugin.
> 
> The only choices open for voting at the moment are:
> (a) stay with SourceForge
> (b) move to Launchpad
> 
> If anybody comes up with an implemented migration path to another tool, and 
> if 
> that tool bears the same cost and effort as Launchpad or SourceForge, it will 
> be added to the above short list for consideration.
> 
> Yuv
> 
> 
> > 
> > Dale
> > 
> > On Tue, 2010-10-26 at 14:31 -0400, Yuval Levy wrote:
> > > Hi all
> > > 
> > > One thing that has been bugging (pun intended) me for a few years now is
> > > the bug tracker.  Hugin has grown and IMHO the SourceForge bug tracker
> > > is now inadequate for Hugin's needs.
> > > 
> > > Our current stats:
> > > - Bugs 1115 total - 218 open
> > > - Feature Requests 240 total - 161 open
> > > - Patches 145 total - 12 open
> > > 
> > > I've tried to make it work a few times, but I never managed to clean it
> > > up completely or sorting out the bugs properly.  There is a lot of old
> > > cruft that never expires.
> > > 
> > > So I looked for alternatives, and my recommendation is:  let's move on to
> > > *Launchpad*.  It enables users to not only contribute bugs, but also to
> > > work on their triaging and getting more involved.
> > > 
> > > The criteria I used to evaluate the different bug trackers were:
> > > - search and scalability
> > > - ease of use
> > > - engaging interaction
> > > - ease of migrating the data in and out (we don't want walled gardens)
> > > 
> > > I've considered other tools as well, but in the end Launchpad is IMHO the
> > > best zero-cost hosted solution available, and unlike with the repository
> > > change earlier this year, definitely one step ahead of the competition. 
> > > It is used, amongst others, by Inkscape [0].  The results they have
> > > achieved are excellent [1].
> > > 
> > > With self-hosting (i.e. funding) I might have considered an alternative
> > > like Roundup [2], used by the Python Foundation.  But (a) we don't have
> > > self hosting and (b) the extra cost and effort does not justify the
> > > extra benefit IMHO.
> > > 
> > > The people at Canonical have been very forthcoming.  I have exported the
> > > SF bug tracker and they will import it to a staging version of Launchpad
> > > where we will get to play with it.  I am waiting for the URL where we
> > > can experiment with the new bug tracker to see if it fits our needs [3].
> > > 
> > > At the same time, I contacted the current owner of the unmaintained
> > > Hugin/Ubuntu page on Launchpad [4].  He has moved on and offered to
> > > transfer ownership.  I hope we can get the bugs to reside there so that
> > > we can consolidate the efforts for official Ubuntu binaries with the
> > > effort for better bug tracking *for all platforms*.  Hugin will have a
> > > second home on Launchpad. Actually a third, if we consider that the
> > > mailing list is on GoogleGroups and the code and website will stay on
> > > SourceForge.
> > > 
> > > A few of the advantages of Launchpad:
> > > * bugs can be tagged, so they can belongs to more than just one category
> > > at the same time, and can be easily searched
> > > * users can mark bugs that affect them, giving a signal to bug fixer
> > > where the most pain is felt
> > > * after a while, bugs expire automatically - let's face it, some issues
> > > just don't attract enough attention and having them clutter the bug
> > > tracker is counter-productive
> > > 
> > > 
> > > NEXT STEPS:
> > > * once we have a staging version of the tracker, I will ask *you* to play
> > > with it.  Judge the responsiveness of the interface, the ease of use. 
> > > Try to file a bug report.  See how it behaves.
> > > * if there is no opposition within the next 2-3 weeks,  I will freeze the
> > > current bug tracker and start the final export/import.  We're likely to
> > > have an interruption of a couple of days between export and import.
> > > * once the new bug tracker is active, users are invited to help triage
> > > the bugs, freeing developers to actually fix those that have been
> > > triaged properly.
> > > 
> > > I hope we can achieve similar results as Inkscape [5].  Hugin has
> > > outgrown the SF bug tracker.  There is plenty of room to grow further on
> > > Launchpad.
> > > 
> > > Yuv
> > > 
> > > [0] 
> > > [1] 
> > > [2] 
> > > [3] 
> > > [4] 
> > > [5] 


-- 
You received t

Re: [hugin-ptx] Bug Tracker: proposal for migration

[Yuval Levy]

On October 26, 2010 03:27:39 pm Dale Beams wrote:
> Hugin !== Ubuntu or Kubuntu

read the proposal: "for all platforms"


> Personally I like Mantis, have enjoyed using it, and it's very
> successful for projects much larger than hugin.

The only choices open for voting at the moment are:
(a) stay with SourceForge
(b) move to Launchpad

If anybody comes up with an implemented migration path to another tool, and if 
that tool bears the same cost and effort as Launchpad or SourceForge, it will 
be added to the above short list for consideration.

Yuv


> 
> Dale
> 
> On Tue, 2010-10-26 at 14:31 -0400, Yuval Levy wrote:
> > Hi all
> > 
> > One thing that has been bugging (pun intended) me for a few years now is
> > the bug tracker.  Hugin has grown and IMHO the SourceForge bug tracker
> > is now inadequate for Hugin's needs.
> > 
> > Our current stats:
> > - Bugs 1115 total - 218 open
> > - Feature Requests 240 total - 161 open
> > - Patches 145 total - 12 open
> > 
> > I've tried to make it work a few times, but I never managed to clean it
> > up completely or sorting out the bugs properly.  There is a lot of old
> > cruft that never expires.
> > 
> > So I looked for alternatives, and my recommendation is:  let's move on to
> > *Launchpad*.  It enables users to not only contribute bugs, but also to
> > work on their triaging and getting more involved.
> > 
> > The criteria I used to evaluate the different bug trackers were:
> > - search and scalability
> > - ease of use
> > - engaging interaction
> > - ease of migrating the data in and out (we don't want walled gardens)
> > 
> > I've considered other tools as well, but in the end Launchpad is IMHO the
> > best zero-cost hosted solution available, and unlike with the repository
> > change earlier this year, definitely one step ahead of the competition. 
> > It is used, amongst others, by Inkscape [0].  The results they have
> > achieved are excellent [1].
> > 
> > With self-hosting (i.e. funding) I might have considered an alternative
> > like Roundup [2], used by the Python Foundation.  But (a) we don't have
> > self hosting and (b) the extra cost and effort does not justify the
> > extra benefit IMHO.
> > 
> > The people at Canonical have been very forthcoming.  I have exported the
> > SF bug tracker and they will import it to a staging version of Launchpad
> > where we will get to play with it.  I am waiting for the URL where we
> > can experiment with the new bug tracker to see if it fits our needs [3].
> > 
> > At the same time, I contacted the current owner of the unmaintained
> > Hugin/Ubuntu page on Launchpad [4].  He has moved on and offered to
> > transfer ownership.  I hope we can get the bugs to reside there so that
> > we can consolidate the efforts for official Ubuntu binaries with the
> > effort for better bug tracking *for all platforms*.  Hugin will have a
> > second home on Launchpad. Actually a third, if we consider that the
> > mailing list is on GoogleGroups and the code and website will stay on
> > SourceForge.
> > 
> > A few of the advantages of Launchpad:
> > * bugs can be tagged, so they can belongs to more than just one category
> > at the same time, and can be easily searched
> > * users can mark bugs that affect them, giving a signal to bug fixer
> > where the most pain is felt
> > * after a while, bugs expire automatically - let's face it, some issues
> > just don't attract enough attention and having them clutter the bug
> > tracker is counter-productive
> > 
> > 
> > NEXT STEPS:
> > * once we have a staging version of the tracker, I will ask *you* to play
> > with it.  Judge the responsiveness of the interface, the ease of use. 
> > Try to file a bug report.  See how it behaves.
> > * if there is no opposition within the next 2-3 weeks,  I will freeze the
> > current bug tracker and start the final export/import.  We're likely to
> > have an interruption of a couple of days between export and import.
> > * once the new bug tracker is active, users are invited to help triage
> > the bugs, freeing developers to actually fix those that have been
> > triaged properly.
> > 
> > I hope we can achieve similar results as Inkscape [5].  Hugin has
> > outgrown the SF bug tracker.  There is plenty of room to grow further on
> > Launchpad.
> > 
> > Yuv
> > 
> > [0] 
> > [1] 
> > [2] 
> > [3] 
> > [4] 
> > [5] 


signature.asc
Description: This is a digitally signed message part.

Re: [hugin-ptx] Bug Tracker: proposal for migration

[Dale Beams]

Hugin !== Ubuntu or Kubuntu

Personally I like Mantis, have enjoyed using it, and it's very
successful for projects much larger than hugin.

Dale

On Tue, 2010-10-26 at 14:31 -0400, Yuval Levy wrote:
> Hi all
> 
> One thing that has been bugging (pun intended) me for a few years now is the 
> bug tracker.  Hugin has grown and IMHO the SourceForge bug tracker is now 
> inadequate for Hugin's needs.
> 
> Our current stats:
> - Bugs 1115 total - 218 open
> - Feature Requests 240 total - 161 open
> - Patches 145 total - 12 open
> 
> I've tried to make it work a few times, but I never managed to clean it up 
> completely or sorting out the bugs properly.  There is a lot of old cruft 
> that 
> never expires.
> 
> So I looked for alternatives, and my recommendation is:  let's move on to 
> *Launchpad*.  It enables users to not only contribute bugs, but also to work 
> on their triaging and getting more involved.
> 
> The criteria I used to evaluate the different bug trackers were:
> - search and scalability
> - ease of use
> - engaging interaction
> - ease of migrating the data in and out (we don't want walled gardens)
> 
> I've considered other tools as well, but in the end Launchpad is IMHO the 
> best 
> zero-cost hosted solution available, and unlike with the repository change 
> earlier this year, definitely one step ahead of the competition.  It is used, 
> amongst others, by Inkscape [0].  The results they have achieved are 
> excellent 
> [1].
> 
> With self-hosting (i.e. funding) I might have considered an alternative like 
> Roundup [2], used by the Python Foundation.  But (a) we don't have self 
> hosting and (b) the extra cost and effort does not justify the extra benefit 
> IMHO.
> 
> The people at Canonical have been very forthcoming.  I have exported the SF 
> bug tracker and they will import it to a staging version of Launchpad where 
> we 
> will get to play with it.  I am waiting for the URL where we can experiment 
> with the new bug tracker to see if it fits our needs [3].
> 
> At the same time, I contacted the current owner of the unmaintained 
> Hugin/Ubuntu page on Launchpad [4].  He has moved on and offered to transfer 
> ownership.  I hope we can get the bugs to reside there so that we can 
> consolidate the efforts for official Ubuntu binaries with the effort for 
> better 
> bug tracking *for all platforms*.  Hugin will have a second home on 
> Launchpad.  
> Actually a third, if we consider that the mailing list is on GoogleGroups and 
> the code and website will stay on SourceForge.
> 
> A few of the advantages of Launchpad:
> * bugs can be tagged, so they can belongs to more than just one category at 
> the same time, and can be easily searched
> * users can mark bugs that affect them, giving a signal to bug fixer where 
> the 
> most pain is felt
> * after a while, bugs expire automatically - let's face it, some issues just 
> don't attract enough attention and having them clutter the bug tracker is 
> counter-productive
> 
> 
> NEXT STEPS:
> * once we have a staging version of the tracker, I will ask *you* to play 
> with 
> it.  Judge the responsiveness of the interface, the ease of use.  Try to file 
> a 
> bug report.  See how it behaves.
> * if there is no opposition within the next 2-3 weeks,  I will freeze the 
> current bug tracker and start the final export/import.  We're likely to have 
> an 
> interruption of a couple of days between export and import.
> * once the new bug tracker is active, users are invited to help triage the 
> bugs, freeing developers to actually fix those that have been triaged 
> properly.
> 
> I hope we can achieve similar results as Inkscape [5].  Hugin has outgrown 
> the 
> SF bug tracker.  There is plenty of room to grow further on Launchpad.
> 
> Yuv
> 
> [0] 
> [1] 
> [2] 
> [3] 
> [4] 
> [5] 


-- 
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] Bug Tracker: proposal for migration

[Yuval Levy]

Hi all

One thing that has been bugging (pun intended) me for a few years now is the 
bug tracker.  Hugin has grown and IMHO the SourceForge bug tracker is now 
inadequate for Hugin's needs.

Our current stats:
- Bugs 1115 total - 218 open
- Feature Requests 240 total - 161 open
- Patches 145 total - 12 open

I've tried to make it work a few times, but I never managed to clean it up 
completely or sorting out the bugs properly.  There is a lot of old cruft that 
never expires.

So I looked for alternatives, and my recommendation is:  let's move on to 
*Launchpad*.  It enables users to not only contribute bugs, but also to work 
on their triaging and getting more involved.

The criteria I used to evaluate the different bug trackers were:
- search and scalability
- ease of use
- engaging interaction
- ease of migrating the data in and out (we don't want walled gardens)

I've considered other tools as well, but in the end Launchpad is IMHO the best 
zero-cost hosted solution available, and unlike with the repository change 
earlier this year, definitely one step ahead of the competition.  It is used, 
amongst others, by Inkscape [0].  The results they have achieved are excellent 
[1].

With self-hosting (i.e. funding) I might have considered an alternative like 
Roundup [2], used by the Python Foundation.  But (a) we don't have self 
hosting and (b) the extra cost and effort does not justify the extra benefit 
IMHO.

The people at Canonical have been very forthcoming.  I have exported the SF 
bug tracker and they will import it to a staging version of Launchpad where we 
will get to play with it.  I am waiting for the URL where we can experiment 
with the new bug tracker to see if it fits our needs [3].

At the same time, I contacted the current owner of the unmaintained 
Hugin/Ubuntu page on Launchpad [4].  He has moved on and offered to transfer 
ownership.  I hope we can get the bugs to reside there so that we can 
consolidate the efforts for official Ubuntu binaries with the effort for better 
bug tracking *for all platforms*.  Hugin will have a second home on Launchpad.  
Actually a third, if we consider that the mailing list is on GoogleGroups and 
the code and website will stay on SourceForge.

A few of the advantages of Launchpad:
* bugs can be tagged, so they can belongs to more than just one category at 
the same time, and can be easily searched
* users can mark bugs that affect them, giving a signal to bug fixer where the 
most pain is felt
* after a while, bugs expire automatically - let's face it, some issues just 
don't attract enough attention and having them clutter the bug tracker is 
counter-productive


NEXT STEPS:
* once we have a staging version of the tracker, I will ask *you* to play with 
it.  Judge the responsiveness of the interface, the ease of use.  Try to file a 
bug report.  See how it behaves.
* if there is no opposition within the next 2-3 weeks,  I will freeze the 
current bug tracker and start the final export/import.  We're likely to have an 
interruption of a couple of days between export and import.
* once the new bug tracker is active, users are invited to help triage the 
bugs, freeing developers to actually fix those that have been triaged properly.

I hope we can achieve similar results as Inkscape [5].  Hugin has outgrown the 
SF bug tracker.  There is plenty of room to grow further on Launchpad.

Yuv

[0] 
[1] 
[2] 
[3] 
[4] 
[5] 


signature.asc
Description: This is a digitally signed message part.

Re: [hugin-ptx] Bug: set crop values for more than one image at once via lens .ini file

[Bruno Postle]

On Sat 20-Feb-2010 at 16:48 +0100, Carl von Einem wrote:


I have a problem with assigning lens data using the "Load lens..."
button in the Camera&Lens tab: it used to set also the crop values for
all other images with the same lens number. Now only the selected image
uses the crop values defined in my lens.ini file. I don't remember when
this behaviour changed but I try to find out later this evening.


It was probably when the layout branch was merged into the trunk 
(23rd December).


The crop settings have never been 'linked' between photos with the 
=0 notation like the other lens parameters.  Though I think applying 
lens settings should work as you expect it to work.



A possible workaround would be to select all images in the Camera&Lens
tab and then load the lens' .ini file. Only the button "Load lens..."
will be greyed if I select more than one image which IMHO doesn't make
sense.


--
Bruno

--
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] Bug: set crop values for more than one image at once via lens .ini file

[Carl von Einem]

Hi,

I have a problem with assigning lens data using the "Load lens..."
button in the Camera&Lens tab: it used to set also the crop values for
all other images with the same lens number. Now only the selected image
uses the crop values defined in my lens.ini file. I don't remember when
this behaviour changed but I try to find out later this evening.

A possible workaround would be to select all images in the Camera&Lens
tab and then load the lens' .ini file. Only the button "Load lens..."
will be greyed if I select more than one image which IMHO doesn't make
sense.

Carl

-- 
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] Bug Squisher

[Carl von Einem]

http://sourceforge.net/tracker/?group_id=77506&atid=550441

You have to be logged in to submit a bug.

Dale Beams schrieb am 12.02.10 23:46:
> What bug tracker does hugin use?
> 
> Dale
> 

-- 
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] Bug Squisher

[Dale Beams]

What bug tracker does hugin use?
Dale




  
_
Your E-mail and More On-the-Go. Get Windows Live Hotmail Free.
http://clk.atdmt.com/GBL/go/201469229/direct/01/

-- 
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] Bug: parameters of the pannini are not exported, and future request

[Bruno Postle]

On Sun 31-Jan-2010 at 16:54 -0800, Daniel M. German wrote:


Also, it would be nice if nona embedded the script in the output file
(the way that PTmender does).


..or at least wrote some EXIF metadata so the output from Hugin can 
be loaded into Hugin with the correct Field of View automatically.


--
Bruno

--
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] Bug: parameters of the pannini are not exported, and future request

[dmg]

I found that the export to PTmender script does not include the
parameters of the projection.

Also, it would be nice if nona embedded the script in the output file
(the way that PTmender does).



-- 
--dmg

---
Daniel M. German
http://turingmachine.org

-- 
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] bug: crop circle not visible on 2009.4 OS X

[Bruno Postle]

On Tue 05-Jan-2010 at 08:42 -0800, Jeffrey Martin wrote:

I cannot see the cropping circle on version 2009.4 on os X. I can see
the rectangle that contains the circle, but not the circle.


Are your input photos set to 'fisheye' or 'circular fisheye'?

--
Bruno
-- 
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] bug: crop circle not visible on 2009.4 OS X

[Jeffrey Martin]

I cannot see the cropping circle on version 2009.4 on os X. I can see
the rectangle that contains the circle, but not the circle.

Jeffrey
-- 
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] bug in libpano/PTmender

[D M German]

FYI,

Adding Tr parameters to the script will restrict the output of the any
remapped image be at most 180 degrees, even if it can spawn longer (such
as most of the cylindrical panoramas).

I am not sure why this happens yet.


--dmg



-- 
--
Daniel M. German  
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

-- 
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] Bug in the camera response model?

[Seb Perez-D]

Hi all

I just got bitten by a strange bug, which I described here:
https://sourceforge.net/tracker/?func=detail&aid=2877384&group_id=77506&atid=550441

Basically, with two lenses and different camera response models, the
output depends on which image is first, which was a surprise to me.

Can anyone reproduce? (the steps to reproduce are in the bug report).

Best,

Seb

--~--~-~--~~~---~--~~
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] Bug Tracker Policy

[Yuval Levy]

Hi all,

unless there are strong objections I intend to change the tracker policy 
to accept only bug reports from identified users.

bug tracker statistics:

* of 858 bug reports file overall, 341 were filed anonymously (40%).

* of 145 open bug reports, 37 were filed by anonymous reporters (32%).

many, too many, anonymous bugs are either incomplete and/or never 
followed up by the anonymous poster. time used to answer those bug 
reports is wasted.

some of those anonymous bug reports are filed by users who are on 
Sourceforge, but forgot to log in.

there is no drawback to being a Sourceforge member - no spam, no cost.

i expect this to improve the quality of the bug reports.

for the patches, we have had a few anonymous contributions, a couple of 
them in the last few days. There is an inherent problem with them. whom 
is Copyright assigned to? even worse: if the anonymous poster has copied 
code from somewhere else without permission, who is liable for the 
potential copyright infringement?

last but not least, take a look at the quality and quantity of enblend 
bug reports to see what the result of this policy is.

with this policy I hope to increase the quality of the report, and 
optimize the work of sorting them out.

Yuv

--~--~-~--~~~---~--~~
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] bug: obscure compile failure if libpano12 is installed

[Reid Priedhorsky]

I had libpano12 installed (Debian Lenny package libpano12-dev). The
build failed with:

/usr/local/src/hugin-0.8.0/src/hugin_base/panodata/
PanoramaOptions.cpp: In member function 'double
HuginBase::PanoramaOptions::getMaxVFOV() const':
/usr/local/src/hugin-0.8.0/src/hugin_base/panodata/PanoramaOptions.cpp:
527: error: expected primary-expression before '}' token
/usr/local/src/hugin-0.8.0/src/hugin_base/panodata/PanoramaOptions.cpp:
527: error: expected `;' before '}' token

Looking in PanoramaOptions.cpp at that line, there is an obvious
syntax error, but it's #ifdef'ed out - if libpano13 is installed.

Removing libpano12-dev and friends and replacing with libpano13-dev
and friends resulted in a successful build and working software.

The docs indicate libpano13 is required, but the cmake step did not
complain that I had the wrong libpano version.

Thanks,

Reid

--~--~-~--~~~---~--~~
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] bug in shear parameter handling: READ IT if you use them!

[D M German]

Hi Everybody,

There was a bug in panotools. It involves the parameters g and t (it has
survived since their conception).

In a nutshell, they have never worked properly. More specifically, its
inverse was wrongly computed when both g and t were different from zero
(I can elaborate on why, if there is interest).

I have a patch now, that I'll commit in the following hours.

This patch might disrupt some people's panoramas iff they use a script
with both g and t <> 0. I think almost nobody does, because the
parameters were useless. I suspect this is the reason they were never
included in the hugin interface (besides the fact that they are of
little practical use).

Dev is finishing the code to add a new feature to the evaluation stack,
called 'tilt'. This will be similar to shear, but will allow an effect
similar to "shear" with independent parameters in each side of the image
(think in terms of holding a photo  and "tilting" it in any angle).

Once his tilt code is finalized, the next step is to add code to the
optimizer, in order for the new parameters of the tilt function to work.

--dmg


-- 
--
Daniel M. German  
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

--~--~-~--~~~---~--~~
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] Bug 2830104: The incredibly growing preview image....

[Gerry Patterson]

Hi All,

One of the more recent commits appears to have given the preview images in
the images tabs, super powers.  When a pano with linked images is dragged
around in the fast preview, the preview images in the tab will grow a little
bit.  Then grow a little bit more on the next drag.  They can get positively
huge after a while.

Filed as a bug. GNU/Linux, (K)ubuntu 9.04, i386. Hugin SVN Rev 4128

https://sourceforge.net/tracker/?func=detail&aid=2830104&group_id=77506&atid=550441

Best Regards,

- Gerry

--~--~-~--~~~---~--~~
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] Bug Triage: priorities?

[Yuval Levy]

hi all,

weather is bad here. son and wife are sleeping. I work on codifying bug 
triaging.

One key issue to collaborative triaging is to identify which tickets are 
new. I would like to suggest doing it via the priority.

New bug reports have default priority 5. In 99% of cases, the reporter 
does not change the priority, which is good so.

We already agreed that priority 9 bugs are "show stopper" in the release 
process. 

Can we agree that priority 5 bugs are "untriaged bugs" and whoever does 
the triage sets the priority to something else?

Yuv


--~--~-~--~~~---~--~~
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] bug

[ivanchti]

hello,

I'm a new user of hugin. my system is a linux ubuntu 8.10.

I had a bug message from my hugin :

nona -z PACKBITS -r ldr -e 11.7228 -m TIFF_m -o
panorama_exposure_layers_ -i 0 /tmp/huginpto_PtblMn
nona -z PACKBITS -r ldr -e 11.7228 -m TIFF_m -o
panorama_exposure_layers_ -i 1 /tmp/huginpto_PtblMn
nona -z PACKBITS -r ldr -e 12.079 -m TIFF_m -o
panorama_exposure_layers_ -i 2 /tmp/huginpto_PtblMn
nona -z PACKBITS -r ldr -e 12.079 -m TIFF_m -o
panorama_exposure_layers_ -i 3 /tmp/huginpto_PtblMn
nona -z PACKBITS -r ldr -e 12.079 -m TIFF_m -o
panorama_exposure_layers_ -i 4 /tmp/huginpto_PtblMn
nona -z PACKBITS -r ldr -e 12.079 -m TIFF_m -o
panorama_exposure_layers_ -i 5 /tmp/huginpto_PtblMn
nona -z PACKBITS -r ldr -e 12.079 -m TIFF_m -o
panorama_exposure_layers_ -i 6 /tmp/huginpto_PtblMn
nona -z PACKBITS -r ldr -e 11.7228 -m TIFF_m -o
panorama_exposure_layers_ -i 7 /tmp/huginpto_PtblMn
nona -z PACKBITS -r ldr -e 11.7228 -m TIFF_m -o
panorama_exposure_layers_ -i 8 /tmp/huginpto_PtblMn
nona -z PACKBITS -r ldr -e 11.7228 -m TIFF_m -o
panorama_exposure_layers_ -i 9 /tmp/huginpto_PtblMn
nona -z PACKBITS -r ldr -e 11.7228 -m TIFF_m -o
panorama_exposure_layers_ -i 10 /tmp/huginpto_PtblMn
nona -z PACKBITS -r ldr -e 11.7228 -m TIFF_m -o
panorama_exposure_layers_ -i 11 /tmp/huginpto_PtblMn
nona -z PACKBITS -r ldr -e 11.7228 -m TIFF_m -o
panorama_exposure_layers_ -i 12 /tmp/huginpto_PtblMn
nona -z PACKBITS -r ldr -e 11.7228 -m TIFF_m -o
panorama_exposure_layers_ -i 13 /tmp/huginpto_PtblMn
nona -z PACKBITS -r ldr -e 12.079 -m TIFF_m -o
panorama_exposure_layers_ -i 14 /tmp/huginpto_PtblMn
nona -z PACKBITS -r ldr -e 11.7228 -m TIFF_m -o
panorama_exposure_layers_ -i 15 /tmp/huginpto_PtblMn
enfuse  -o panorama_stack_ldr_.tif
panorama_exposure_layers_.tif panorama_exposure_layers_0001.tif
panorama_exposure_layers_0002.tif panorama_exposure_layers_0003.tif
panorama_exposure_layers_0004.tif panorama_exposure_layers_0005.tif
panorama_exposure_layers_0006.tif panorama_exposure_layers_0007.tif
panorama_exposure_layers_0008.tif panorama_exposure_layers_0009.tif
panorama_exposure_layers_0010.tif panorama_exposure_layers_0011.tif
panorama_exposure_layers_0012.tif panorama_exposure_layers_0013.tif
panorama_exposure_layers_0014.tif panorama_exposure_layers_0015.tif
make: enfuse : commande introuvable
make: *** [panorama_stack_ldr_.tif] Erreur 127


What is this? What do I have to do?

Thanks a lot

ivanchti
marseille  France

--~--~-~--~~~---~--~~
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 [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

[hugin-ptx] Bug in preview window

[Peter Miller]

Using Hugin 0.7 beta 4 on Ubuntu Hardy.

I noticed a problem last night, while stitching A4 scans of a topo map
together, using the tutorial at
http://hugin.sourceforge.net/tutorials/scans/en.shtml

The optimizer worked perfectly.  In the preview window, however, the
"fit" and "centre" buttons (and also clicking to select center) ignored
the custom optimizer settings, and introduced pitch and yaw.

(These days I always save before the first optimizer run, so I can quit
and start again as a simple way to completely reset; a button would be
more convenient, though.)

eventually I wised up, and stitched after optimizer run without preview.


Could the preview window be made to honour optimizer settings, please?
(in this case: no pitch, no yaw).


Could there be a single "reset everything the optimizer and/or preview
altered utterly and completely" button, please?  Clicking several times
per image, on several tabs, is a royal PITA.  Remembering to save before
optimizing, and then quitting and restarting, is also a PITA.


Regards
Peter Miller <[EMAIL PROTECTED]>
/\/\*http://miller.emu.id.au/pmiller/

PGP public key ID: 1024D/D0EDB64D
fingerprint = AD0A C5DF C426 4F03 5D53  2BDB 18D8 A4E2 D0ED B64D
See http://www.keyserver.net or any PGP keyserver for public key.

"...by an expert. Worse, a committee of experts." -- Final Cut Pro
easter egg


signature.asc
Description: This is a digitally signed message part