Kornel Benko | 28 May 15:55 2015
Picon

Nona GPU not working anymore


Ubuntu 14.04, 64 bit, default branch.
Graphic card: NVIDIA, Geforce GTX 750, OpenGL/ES-Version 4.5.0 NVIDIA 346.47

The last versions of nona seem to be not working anymore.
There is no crash and no error message. Nona simply hangs.

Using without '-g' parameter works.
I suspect the
	changeset:   6978:0beb67edf587
	parent:      6976:e4c461b28afc
	user:        tmodes
	date:        Wed May 27 17:48:45 2015 +0200
	files:       CMakeLists.txt CMakeModules/win_bundle.cmake README src/hugin1/hugin/CMakeLists.txt
src/hugin1/hugin/GLRenderer.cpp 	src/hugin_base/CMakeLists.txt
src/hugin_base/hugin_utils/utils.cpp src/hugin_base/vigra_ext/ImageTransformsGPU.cpp	src/tools/CMakeLists.txt
	description:
	Use own code for initialization of GLContext (Windows and Linux)

	This should prevent a popup window, as opened by freeglut.
	This removes the dependencies on glut/freeglut.
	On MacOS there is still glut/freeglut used.

It was not nice with the popup window, but at least it worked.

	Kornel

--

-- 
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
--- 
(Continue reading)

paul womack | 28 May 14:57 2015
Picon

Feature request/Bug fix

When working on a stubborn optimising problem, it is helpful
to work "stepwise".

To faciliate this, Hugin's optimiser tab had an option:
"Only use control points between image selected in preview window".

This works well; however, assuming that an optimisation
gives a good average and standard deviation, but has a high max,
it is "obvious" that some duff control points exist.

Now, the easiest way to get rid of these is the
"Control Points" dialog (F3), which can list control points
in distance order, making deletion quick and easy.

But this shows ALL the control points.  In a partially
completed optimisation, the un-optimised images
(UN-selected in the preview) will have very large errors,
and this make removing the large(st) errors
for the selected images very difficult.

Proposal/Solution:

F3 should only show CPs for "image selected in preview window",
possibly also under the control of the option in the Optimise tab.

  BugBear

--

-- 
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
--- 
(Continue reading)

paul womack | 28 May 12:37 2015
Picon

mosaic, confusion and ignorance - some experiments

I thought I'd step back from my large map project,
and grope my way towards an understanding
of the underlying model and capabilities of
mosaic mode, on the simplest possible example.

I suspect all I've done is better define my ignorance.

In the hope that I may help others, and
that other can help me I present my experiment.

I took two shots of a pretty nigh 2D target;
it's a financial advert (yawn) printed on stiff paper,
and delivered to me unfolded.
The shots were deliberately taken at very different angles,
to see wether this could be resolved.

I carefully (and manually) set a large number
of well distributed control points between the 2 images.

I then attempted to see if one image
could be arbitrarily fitted to another "base" image
using the flexibility of mosaic mode.

So I left image 0 fixed (all parameters zero except roll
of 90 to put the image right way up and keep me sane).
I optimised (in various sequences) YPR,XYX.

All gave me dreadful CP errors (avg 19, max 74).
(attached as base.pto)

(Continue reading)

Mike Mackinven | 28 May 00:56 2015
Picon

wxWidgets Debug Alert popup in Hugin, how can I sort this out?

Here's the screenshot that plagues me every time I want to use Hugin. 

How can I fix this?



--
A list of frequently asked questions is available at: http://wiki.panotools.org/Hugin_FAQ
---
You received this message because you are subscribed to the Google Groups "hugin and other free panoramic software" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hugin-ptx+unsubscribe <at> googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/dcb48b40-38a3-4a12-a297-78560e4a296a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

One photo taken without tripod

Hi all,

I am working on a 360 degree panorama. All but the last photo are taken using a panorama head on a tripod. The
largest control point distances all involve this last photo.

How do I tell Hugin to optimise TrX/TrY/TrZ only for this specific photo? Currently I use Hugin 2014.

Thanks in advance!

--

-- 
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+unsubscribe <at> googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/1432766131.97419.YahooMailBasic%40web171306.mail.ir2.yahoo.com.
For more options, visit https://groups.google.com/d/optout.

Bob Mahar | 26 May 23:11 2015
Picon

Alignment and exposure stacks, feeling like a noob

Hi,

I've been using Hugin for years now.   Perhaps I got amnesia along the way and forgot some critical checkbox I automatically would set.   But recently I've been having some issues with exposure bracketed stacks when making stereographic panoramas.   The fused image will have ghosts where it seems as if the stack members are not alaigned properly and cause ghosting / multiple exposure like effects in the stitched image.

I use a tripod and a wired remote release to take a 5 or 7 exposure bracket for each of the shots.   The images for a given stack do not appear to be misaligned as shot, To cover the world with the 14mm lens, perhaps 25-30 bracketed shots.   I plop them into Hugin.  Set the stack size as appropriate.  Use the cpfind ( rows + stacks ).   Then after verifying everything is connected,  do an alignment for Position to rough it in.  Assuming there is nothing too ridiculous in the control point table distances, go for the Position + Barrel.   Normally I get a very nice result, with limited need to futz or post process.  

However in some recent projects, I see ghosting on the fused output, as if the individual stack members are misaligned.slightly.

Since I'm using a tripod, and fixed aperture and focus, the stack images should already be registered properly, so I should be able to ignore the alignment of individual stack members, and rely on the +/-0 EV images for alignment.   I never noticed this ghosting / multiple images issues in prior projects.   And it does not appear in the ordinary non-fused project - so seems to be an artifact of the multiple exposure layers differing in alaignment and then after being fused you have the ghosting.

So, this is a very log winded way of asking: is there a way to force Hugin to use only control points for one of the exposure bracket members, then apply the distortions and masks necessary to all of the stack members?   Is this a behavior that might have changed in recent history?   I assume this is a very commonly desired behavior, so I must be missing something really obvious in my workflow.

Any suggestions are appreciated.

-- Bob

--
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+unsubscribe <at> googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/19312844-a06b-4a66-b1f8-311acf04c735%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
paul womack | 26 May 13:48 2015
Picon

control point editing/review - feature request

When reviewing (and deleting) auto generated control points, I would
very much like to be able to set the "view" to 200%
and NOT to have the little contrast-enhanced accuracy-aid
appear. The enhanced window obscures the context
of the control point, which is crucial during this process.

So the feature I want is the ability to turn OFF
the enhancement.

  BugBear

--

-- 
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+unsubscribe <at> googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/55645DA6.2090202%40papermule.co.uk.
For more options, visit https://groups.google.com/d/optout.

paul womack | 26 May 13:36 2015
Picon

Mosiac model - convergence, accuracy?

The convergence behaviour of the mosaic model is really quite poor.

I have recently completed shooting a very careful trial, using
a cantilevered tripod (Benbo) over a map on my dining table.
(I shot at less than maximum resolution, at 3 Mp to cut down
the data size)

All the shots (30 in all) are accurately focused and sharp.

I found that for this large image set, it is neccessary
to perform step-wise addition and optimisation
of the images (initially just X and Y).

Simple hoping that the optimiser will just "sort it all out"
doesn't work, at least with the kind of control point
set found by automation. it works OK with "nigh-perfect"
control point sets (I just found ;-)

In practise I found that
as I proceeded, I needed to hand edit a "fairly good"
position of X and Y to get the optimisation to converge at all.

This is doable (since my images form a simple matrix)
but more work than I'd like.

(I also regret that the ctrl-T short cut for "optimise"
is not available on the preview window)

My more significant concern is that my "final" optimisation,
has a disappointingly large error, and (indeed)
shows stitching glitches on final output.

Since my map is nigh 2 dimensional, and I went to considerable
pains to shoot a narrow FOV from a good distance above the
map, I believe that the mosaic model should be able to get
VERY close to perfect on this image set, and yet it doesn't.

I am aware that I may be one of the more extreme users
of the mosaic model; is it believed to be bug free?

I would be able to test this by synthesizing scaled and YPR skewed
sub-images from a high res original (e.g. a giga-pan) and then attempting
to stitch them using mosaic mode.

I would rather not go to this effort unless forced.

I have uploaded the images and project file at

https://www.hightail.com/download/bXBhZEV5VnNreEJEZU1UQw

They will be there for a week. Note that I believe the
map test subject to be in copyright.

  BugBear

--

-- 
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+unsubscribe <at> googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/55645AA0.4050902%40papermule.co.uk.
For more options, visit https://groups.google.com/d/optout.

paul womack | 21 May 10:08 2015
Picon

sources, transcriptions, spelling mistakes, deductions

There seems to a underlying, unspoken theme in the recent discussions
on variant/nested data.

Many of the examples raised mention that multiple sources
might well spell a name differently, or that a place might
be known by multiple names.

Further, place of birth might well be stated to different
degrees of precision on multiple sources
(I've had a case where the "true" location was probably
a village called "Greater Blah", there also being a Lesser Blah", but one
census simply listed "Blah", and yet another listed the nearby
larger town).

And yet the person was (obviously...) only born in one place.
The difficulty here (I believe) is that there is no clean
distinction between a "raw" transcription, (probably textual)
a semantic transcription (e.g. where the *name* of a place
is interpreteted to a place *object*), an aggregate
interpretation (e.g. where multiple sources are conglomerated
into a consensus place object), and deductions (where the process
of reaching a conclusion involves logic and interpretation
as well as "averaging").

I think some of the recent suggestions as to features
are all tiptoeing around the edges of this very fundemental
concept - that the process of genealogy involves
a progression from "raw sources" to a "concluded tree".

Of course, at the moment, most of us are using
gramps to hold BOTH, (along with the intermediate stages
of the process), and yet there is nothing explicit
in the gramps model (or any other software I'm aware of)
to codify or mark these stages.

I feel that feature development in terms of data representation
should have this distinction (raw->conclusion) in mind as a key guiding design concept.

  BugBear

--

-- 
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+unsubscribe <at> googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/555D9266.1040705%40papermule.co.uk.
For more options, visit https://groups.google.com/d/optout.

T. Modes | 19 May 21:11 2015
Picon
Picon

Re: Hugin 2015.0 beta - not coloring image numbers at the preview



Am Dienstag, 19. Mai 2015 16:04:37 UTC+2 schrieb Cartola:
Hi, I am running Hugin 2015.1.0.41e868c40876 on a Linux Mint box. Have just updated the package that showed the version 2015.1.0+hg6958+dfsg-0ubuntu1~trusty while installing.

I have noticed that one function I use is not working as before. At the fast preview window I use to identify images with the mouse cursor + pressed control. When the ctrl is pressed the mouse cursor makes the images colored and you can identify their numbers by the same colors on the number list that stays above the preview. The images at the preview are getting colored ok, but the numbers don't, so it is getting difficult to identify what are the image indexes I want. I use it to make masks and additional control points for example.


The code for this was not touched. So I assume this is an issue with the window manager and/or wxWidgets. Can somebody else confirm the issue and report which versions?

Thomas

--
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+unsubscribe <at> googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/9afb66e5-aa6b-414d-a836-d03f87b05e15%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Picon

Hugin 2015.0 beta - not coloring image numbers at the preview

Hi, I am running Hugin 2015.1.0.41e868c40876 on a Linux Mint box. Have just updated the package that showed the version 2015.1.0+hg6958+dfsg-0ubuntu1~trusty while installing.

I have noticed that one function I use is not working as before. At the fast preview window I use to identify images with the mouse cursor + pressed control. When the ctrl is pressed the mouse cursor makes the images colored and you can identify their numbers by the same colors on the number list that stays above the preview. The images at the preview are getting colored ok, but the numbers don't, so it is getting difficult to identify what are the image indexes I want. I use it to make masks and additional control points for example.

Thanks,


2015-04-28 9:03 GMT-03:00 Stefan Peter <s_peter <at> swissonline.ch>:
Hi All

Please find packages for Ubuntu 14.04 (Trusty), 14.10 (Utopic) and 15.04
(Vivid) in the Hugin PPA Packagers *next Hugin Build" ppa at
https://launchpad.net/~hugin/+archive/ubuntu/next/+packages

The binaries have two additional patches from the 2015 branch of the
hugin hg repository applied (hg6903_Fixes_a_further_assert_message and
hg6904_Fixes_crash_in_cp_editor. Additionally, the python scripts have
been modified in order to be accepted again by 2015.0.

Please send bug reports to this list.


Cheers

Stefan Peter

--
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+unsubscribe <at> googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/553F7701.1080502%40swissonline.ch.
For more options, visit https://groups.google.com/d/optout.

--
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+unsubscribe <at> googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hugin-ptx/CALW1f7jjpG%3D%3DOrX8%3DnJqPA452xz5__Uh-zcVO-2VRS1KjYhAiQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Gmane