Re: [hugin-ptx] [OSX] 20110615 hugin-mac-2011.1-5311_f8270bcc6d99-build2

[Eric O'Brien]

On Jun 16, 2011, at 6:33 AM, Harry van der Wolf wrote:



2011/6/16 phartz...@gmail.com 
On Wed, Jun 15, 2011 at 8:21 AM, Harry van der Wolf  
 wrote:


> A reworked version of the yesterday bundle:
>
> - Changed call to PTBatcherGui from Assistant
> - I removed python again for the time being.

 This latest build does not launch PTBatcherGUI either.  The results
are the same as before.  All works well until the stitch procedure
wherein there is no activity associated with the batcher and it
remains dormant.


It doesn't launch PTBatcherGui at all?
Or it doesn't launch PTBatcherGui in "immediate stitch"  mode?
If the latter, just to be sure: What button do you use in the  
Assistant: The "Send to Assitant queue" from button row 2, or the  
"Create panorama..." from button row 3?




The same for me.  I'm using a PowerMac G4 with a dual processor  
upgrade.  Mac OS X 10.5.8.


The same behavior whether using "Create Panorama..." on the Assistant  
tab or "Stitch" on the Stitcher tab:  a window titled "Specify output  
prefix" is displayed.  Pressing the Save button dismisses that dialog  
but PTBatcherGui does not launch at all.


I think someone else also mentioned:  In the File menu, "Quit Hugin"  
is unavailable (grayed out).  Huh, after forcing a quit, restarting,  
checking the "About" menu and opening my saved project, Quit is now  
available.  Odd.


I also noticed that the version string that displays in the Info  
window (Finder) does not match the version number shown in the About  
dialog.


eo

--
You received this message because you are subscribed to the Google Groups "Hugin and 
other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: A job for Hugin mosaic-mode - hieroglyphs

[Eric O'Brien]

To be fussy, note that this "flattening of perspective" is the result  
of the ratios of the distances between the camera and the near and far  
parts of the image being more similar than otherwise.  This can be  
caused to happen by moving the camera farther away from the subject  
(as Kay says).  Naturally, as you move father from your subject, you  
may find yourself reaching for a longer lens (which has a smaller  
field of view).


Lens length itself does not affect this kind of "perspective."

eo


On May 30, 2011, at 11:18 PM, Emad ud din Btt wrote:

Yes, I am talking about using a telephoto lens and shooting a linear  
panorama from different spots.


I am talking about using telephoto compression to make surfaces  
flat. For example there are objects physically not on one same  
plane. So thats not a flat surface to shoot.  A telephoto lens will  
make this plane flat. But do you have any info about Lens (mm) to  
distance relationship to minimalize parallactic error. I want to  
shoot a long  linear panorama of a historical road from a moving car.



Emaad


On Mon, May 30, 2011 at 9:43 PM, kfj <_...@yahoo.com> wrote:


On 30 Mai, 17:53, Emad ud din Btt  wrote:
> Kay, Can we utilize dof compression as well? Like you are looking  
for flat

> surfaces and dof of a telephoto lens also compresses depth. Objects
> physically apart form each other start looking like on one same  
plan.  So
> what about mosaicing with a telephoto lens. Will it have effect or  
not? What

> do you say? If yes, what would be ideal lens?

I'm not sure if I understand what you mean. If the subject is flat, it
doesn't matter which lens(es) you use. If it's not you're better off
shooting from one spot (panorama-style) and with a long lens from afar
so you have less parallactic errors.

If you taking the images from a spot looks wrong and you want the
'flat' impression (like, with large facades), your best bet is to be
as far away as possible and use a long lens, minimizing parallactic
differences between images. If you can't get far enough away, you'll
have a hard time getting a convincing result without manual
intervantion.

Kay


--
Emaad
www.flickr.com/emaad


--
You received this message because you are subscribed to the Google Groups "Hugin and 
other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Panini-Video

[Eric O'Brien]

Umm..

Cool, I guess.

The format is AVI  !?!?

eo

On Feb 16, 2011, at 9:00 PM, Tom Sharpless wrote:


I don't suppose you've been wondering what I've been up to for the
past 18 months, but...

The first member of the the Panini Version 1 suite -- Panini-Video --
is now pre-beta.  It converts wide angle and fisheye video to Panini
projection, with interactive controls too numerous to mention.  See
the first-ever full HD Panini video clip at http://www.youtube.com/watch?v=qKVZ7pJdCvw 
.


Technically, Panini-Video unites a slightly tweaked FFmpeg (named
PPmpeg) with an all-new Panini engine running in OpenGL shader code
and supported by a Qt GUI and a lens and camera database.   It runs
from the command line exactly like FFmpeg; but if you ask for the
'panini' video filter, the Panini-Video GUI pops up.  Eventually I may
make the GUI come up first and run the PPmpeg part on an internal
command line; but I do like the flexibility of having the full FFmpeg
command interface available.

On my machine, max conversion rates are 5.7 fps at 1920x1280 and 14
fps at 1280x720, with H.264 in and out.  Almost all the time is spent
on decoding the video to RGBA and encoding it again; the 'Panini time'
is negligible by comparison.  Of course you can slow the frame rate
even more, pause, and single-step to make it easier to follow the
video with the perspective controls.   Someday, if it becomes a
commercial tool, it might get proper 'animation-style' facilities to
record and replay control sequences.

In a week or two the beta source will be on SourceForge, project name
paniniperspective.  During the Spring I shall be releasing betas of
two more suite members: Panini-Photo for correcting photos (not only
perspective but tca and vignetting too) at full resolution, and  
Panini-

Pano for extracting high-res views from full panoramas.  And even
Panini-Stitch, for very fast (but not too accurate) stitching of panos
from array cameras like Jan Martin's.

Cheers,  Tom


--
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] Progress window flashes, no stitch

[Eric O'Brien]

On Feb 7, 2011, at 9:27 PM, phartz...@gmail.com wrote:

On Mon, Feb 7, 2011 at 11:53 PM, Eric O'Brien  
 wrote:



The same for me:
echo: write: Bad file descriptor
gnumake: *** [info] Error 1


 Are you also running OSX 10.5 Leopard?


Yes, 10.5.8

eo



 Steve


--
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] Progress window flashes, no stitch

[Eric O'Brien]

On Feb 6, 2011, at 9:51 AM, Harry van der Wolf wrote:

No idea how I got that copy&paste action incorrect. See correct link  
below.





The same for me:

echo: write: Bad file descriptor
gnumake: *** [info] Error 1

At least this time the progress window stayed open and revealed some  
possibly useful information.  When using 2010.5.0.4886:a1cb4a2efa65,  
that window flashes briefly and disappears.



Earlier, I tried using PTBatcherGUI.app and although it is hardly a  
good replacement for Hugin working correctly I *was* happy to see a  
quite verbose log printed to a window.


I wish there were a way for Hugin itself to (optionally) produce such  
a thing.  If Hugin doesn't "leave notes" somewhere about what is  
happening, how will we ever be able to track down some of the more  
obscure misbehaviors?


Thanks,

eo

--
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] Progress window flashes, no stitch

[Eric O'Brien]

Thanks!

So I seem to be experiencing the "Mac OS X 10.5 Mystery," eh?

eo

On Feb 5, 2011, at 5:33 AM, Carl von Einem wrote:


Eric O'Brien schrieb am 05.02.11 04:51:
It seems this has happened for me before, but I don't recall the  
cause

or solution.

I'm using the Mac version 2010.5.0.4886:a1cb4a2efa65.

On the Stitcher tab, I press "Stitch now..." I'm given the  
opportunity

to edit the file name and save location. In that dialog I then press
"Save."

What *would* be the progress window appears for a brief moment, then
disappears. A panorama is not saved on disk. No error messages are
displayed.

What should I try?


I just tested it on 10.5 and the same happens here. Note that 10.4  
and 10.6 aren't affected.
The workaround is to safe the project, load it into ptbatchergui and  
run the project.

Download from
http://sourceforge.net/projects/hugin/files/hugin/hugin-2010.4/
-> ptbatchergui-mac-2010.4.0.dmg

Hope that helps,

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] Progress window flashes, no stitch

[Eric O'Brien]

It seems this has happened for me before, but I don't recall the cause  
or solution.


I'm using the Mac version 2010.5.0.4886:a1cb4a2efa65.

On the Stitcher tab, I press "Stitch now..."  I'm given the  
opportunity to edit the file name and save location.  In that dialog I  
then press "Save."


What *would* be the progress window appears for a brief moment, then  
disappears.  A panorama is not saved on disk.  No error messages are  
displayed.


What should I try?

Thanks,

eo

--
You received this message because you are subscribed to the Google Groups "Hugin and 
other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Error on stitching.

[Eric O'Brien]

On Feb 4, 2011, at 4:29 PM, C wrote:


Check for non standard characters in the folder names in the path down
to where the pictures are you are loading.  I suggest normal letters
and spaces only.  Alternatively copy the pictures to the desktop and
load from there so as to avoid the Hugin program having to look down
through the folders with non standard characters to get to the
photos.


I am familiar with this problem in command line programs and UNIX  
ports.  Looking at the interface in Hugin, I don't see a way to view  
the full path for a image or pto or other file.  Is there a way to do  
this?


If there were, it would be easy to check that to make sure that there  
were no illegal characters anywhere in the path.


eo

--
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] "Rounded" Perspective correction

[Eric O'Brien]

I don't know if this will help, but you might search on

   unwrap cylindrical label image

eo

On Dec 20, 2010, at 12:27 PM, aliquis wrote:


Hello guys,

I am looking for the function in hugin that I would call rounded
perspective correction(I am not sure if this is the right name).
Basicly I would like to get a linear image from a can-like image, for
example like 
http://www.iainclaridge.co.uk/blog/wp-content/uploads/inspiration_can.jpg
. I would like to straighten the "Inspiration" title. Is there such a
functionality in hugin? Do you know any other tools which would be
able to do that?

Thanks very much.

br,

- aliquis


--
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] Magnifier in control point editor panel

[Eric O'Brien]

I agree that more sophisticated behavior would be helpful.  Sometimes,  
the view in the magnifier is so "enhanced" that it no longer looks  
much like the area the cursor is over.  This makes it difficult to  
determine which feature you might *actually* be selecting.


Sometimes, "more contrast" isn't really the best choice.  Often,  
simply "lighter" would do nicely.  And for very light areas "more  
contrast" often results in a hard to read "blown out" look.


eo


On Dec 18, 2010, at 2:29 PM, davidefa wrote:


I have already noticed a 'strange' behaviour of the magnifier in the
control point editor panel ( but never understood it ).
Today I loaded in hugin a few astronomical images ( see thread [1] ),
and while adding a few cp I noticed that when the magnifier was
positioned on the dark background ( no bright stars in the fov of the
magnifier ) it showed a 'bright and dark texture', I couldn't
understand where it came from.
Searching in the code found that before being displayed the magnifier
is 'contrast enhanced' ( the darkest part of the image is converted to
back, the brightest part is converted to 255, max brightness ).
This is to help identifying 'features' in the images.
But when the magnifier is placed on a low contrast part of the image
( a generic image, not the astronomical image I refered above ) this
amplification ( contrast enhancement ) could be very high and this
seems a little bit confusing to me ( I mean the magnifier show a very
high contrast on a part of the image which has very low contrast ).
I think we could/should limit the maximum contrast enhancement.



in file CPImageCtrl.cpp line 601
  // transform to range 0...255
  vigra::transformImage(vigra::srcImageRange(magImg),  
vigra::destImage(magImg),

vigra::linearRangeMapping(
  VT(minmax.min),  
VT(minmax.max),   // src range

  VT(0), VT(255)) // dest range
);




[1] 
http://groups.google.com/group/hugin-ptx/browse_thread/thread/06c616c5f57c6787#
[2] http://www.davidefabbri.net/files/panorama/magnifier.zip



--
You received this message because you are subscribed to the Google Groups "Hugin and 
other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Command line interface for hugin please

[Eric O'Brien]

Didn't I just say something about some documentation being a bit ...  
sparse?


Please, all you programmers out there:

Take an additional hour or so, after you are "done" with the Real  
Work, and expand the "help" and man files.


Then take yet another hour, go back over your code and add some  
comments.  (Well, really, you should be commenting as you go.   
Shouldn't you?)


Coolness isn't cool if nobody but yourself and three buddies can use  
it / make sense of it.


Come on now, everybody reach for the next level TOGETHER.  ;)

Thanks,

eo


On Nov 21, 2010, at 10:18 AM, kfj wrote (in part):

 I looked at likely candidates among the scripts that handle pto  
files, but all I

found was extremely meagre documentation.  It made me really angry.
Like there is 'hugin_stich_project'. It is a command line tool to
stitch a hugin project. It states

Verwendung: hugin_stitch_project [-h] [-o ] [-t ] [-d]
[ ...]
 -h, --helpshow this help message
 -o, --output=output prefix
 -t, --threads=   number of threads
 -d, --delete  delete pto file after stitching

... and that's it. (there is a man page which says the same in  
slightly more words).


. . .

 I lost patience.


with clenched jaw from grinding my teeth

Kay

--


--
You received this message because you are subscribed to the Google Groups "Hugin and 
other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Several questions about hugin sourcecode

[Eric O'Brien]

I am not a programmer.  And I have not looked at this code.

But.

Questions like this (which seem to appear fairly often) greatly  
concern me as a user.


While I am not a programmer, I *am* familiar with certain conventions  
or "best practices."


One of those being something called "COMMENTING YOUR CODE."

I realize this project is an Open Source one, and all that but...

Shouldn't questions like those below be addressed (at least at the  
first level) as comments in the code?


Is it truly the case that when inspecting the code described that  
answers to these questions are mysteries??



eo

On Nov 21, 2010, at 7:24 AM, Cugucas wrote:


Hi，all

I have met some questions while reading the sourcecode of hugin.

1. I noticed that there are two functions named createTransform and
createInvTransform in PanoToolsInterface.cpp. What are they used for?
In "createTransform", there are two lines:
   m_srcTX = destSize.x/2.0;m_srcTY = destSize.y/
2.0;
What do m_srcTX and m_srcTY mean? and why destSize.x and destSize are
divided by 2.0?

2. In SpaceTransform.cpp, a variable named "params.distance" appears
many times. What does it mean?

3. What is the function "AddTransform" in SpaceTransform.cpp used for?

Thanks for your help!


--
You received this message because you are subscribed to the Google Groups "Hugin and 
other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: colors

[Eric O'Brien]

If Hugin is not retaining the profile information, it should be more  
of an irritation rather than a significant problem.  Just do all your  
work as usual while ignoring any "funny" colors.  When you have  
created a final output file, just open it in your favorite image  
editor and assign the it the correct profile.


That is, probably the PIXEL data has not changed, only the notation of  
what profile is being used.


eo

On Nov 9, 2010, at 5:40 PM, sneike wrote:


so, is there a solution to use images with a certain profile, having
as output an image with that same profile?


On Nov 10, 12:26 am, Bruno Postle  wrote:

On Tue 09-Nov-2010 at 11:56 +0100, Carl von Einem wrote:


Eric O'Brien wrote:
I wonder if the inputs have multiple profiles, and hugin is  
arbitrarily

picking ONE for the output.


It certainly does this, or is supposed to. i.e. it treats the input
and output data as unprofiled, then copies any profile from the
first photo to the final output.

It could be modified to convert all photos to a universal
colourspace on reading and to a specified colourspace when writing,
but there has never been any request for this.


I consistently have to reassign the correct profile to the output
file (using Harry's Mac OS X builds). Isn't exiftool supposed to do
this job?


I have never tested it, it could be broken.

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

[Eric O'Brien]

The color profiles in the files are different.

"KJG.jpg" is "Generic RGB Profile" but
"IMG_5673.jpg" is "Adobe RGB (1998)

In Photoshop, if I assign Adobe RGB (1998) to the first file, it then  
looks substantially like the second file.


The question of course is:  why the color profiles are different?  I  
have *thought* that Hugin retains color profiles.


eo


On Nov 8, 2010, at 4:06 PM, sneike wrote:


seems like the colors of my photos change when i import them into
hugin.. also the quality of the photo is involved..
for example, this is the photo i import (http://dl.dropbox.com/u/ 
37538/

compared/IMG_5673.jpg) and this is the exported one just setting some
vertical points (http://dl.dropbox.com/u/37538/compared/KJG.jpg)

just note that i can see the color and quality difference already in
the hugin's tabs..

how can avoid this annoying issue?

thanks
DNL


--
You received this message because you are subscribed to the Google Groups "Hugin and 
other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: View this page "Affine SIFT algorith"

[Eric O'Brien]

Anything that would help to spread control points farther beyond  
clumps in the center of the image for fisheye images... would greatly  
reduce stitching errors, I think.


ei

On Nov 7, 2010, at 2:58 AM, kfj wrote:




On 31 Okt., 03:14, Tom Sharpless  wrote:


It is a fact that SIFT does not find as many matches as we would like
in wide angle and especially fisheye images.  But that problem will
not be solved by better matching of affine transformations, as it is
due to image deformations, characteristic of those lenses, that are
not affine transformations.


I've thought about the matter and come up with this train of thought:
If you look at two corresponding small sections of, e.g., two fisheye
images taken with different orientation, the transformation from one
to the other is not, but resembles an affine transformation. The
smaller the bits you compare, the closer the semblance. So looking at
affine transformations helps, since a particular affine transformation
locally approximates the actual nonaffine transformation.
If the lens geometry is known, though, the choice of which affine
transformation of which subsection of the image to feed into a feature
generating algorithm could be narrowed down to that affine
transformation that best locally approximates the non-affine
transformation, thus gaining some efficiency.
I admit that this is more of a gut feeling than something I could
easily demonstrate mathematically, but maybe someone with a firmer
mathematical background could give a comment?

with regards
Kay


--
You received this message because you are subscribed to the Google Groups "Hugin and 
other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Not a Panorama - just control points for Enfuse - How to?

[Eric O'Brien]

One might consider this, also, an indication that the documentation  
might be expanded or clarified on this point.  ;)


(In case it's not already addressed.)

eo

On Nov 3, 2010, at 8:29 AM, Bruno Postle wrote:


(Apologies my phone won't let me quote properly)

If your bracketed sets are not well aligned there is no need to save  
the intermediate files and blend them manually.


Hugin has two exposure fusion modes: 'fused and blended' fuses  
stacks together first then seam blends the result, this requires the  
stacks to be approximately aligned, i.e. handheld using an SLR  
bracketing mode is fine; the other 'blended and fused' mode is what  
you need if you want to do exposure fusion but don't have  
identifiable stacks.


--
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] Where to place feature requests?

[Eric O'Brien]

On Oct 31, 2010, at 5:02 PM, Bruno Postle wrote:


On Sun 31-Oct-2010 at 14:20 -0700, Eric O'Brien wrote:

Well, this is an interesting point.  I also shoot the horizon row  
first, then the zenith, then the nadirs.  That is, I don't proceed  
top to bottom or bottom to top but shoot the middle row, the top  
"row" and then the bottom "row."
For me, the assumption that "pictures that are next to each other  
in the shooting sequence are also next to each other in the  
panorama." will be incorrect.


The multi-row option is more sophisticated than this, matching  
consecutive images is only the first step in the process.  It is  
able to deal with rows or columns in any order.


Does this require using a pre-aligned panorama (as below), or is it  
expected to succeed with images in the project in any order and all  
beginning placed at 0, 0, 0?




On the other hand, if I (we) are shooting a sequence that is  
standard for us, it seems that using a Template would work.  Apply  
the template would distribute the images in close to the correct  
locations on the sphere.  Then the trick would be to get the  
control point generators to generate points only between adjacent  
images.


Yes you can do this in Hugin currently, use an existing project as a  
template with the File -> Apply Template function, then use a  
'prealigned panorama' control point detector preset.


Out of curiosity, is it the *control point generator* that  
"understands" to create control points only between overlapping  
images, or is that some information that Hugin generates and passes to  
the CP generators?  Or...?




This is definitely the most efficient way to align multiple  
panoramas taken with the same setup.


Sorry, we are really suffering from a lack of documentation  
considering how often we get requests for features that already exist.


Since I believe you work with Linux, you may not be to aware of the  
Macintosh text editor TextMate.  The interface is very simple looking,  
but it packs a *huge* amount of functionality.  "Requests for features  
that already exist" are fairly frequent on the discussion list.  Also,  
requests for help figuring out a complicated way to achieve something  
when the right use of a menu command will do the trick.  ;)




--
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] Where to place feature requests?

[Eric O'Brien]

Hey Yuval...

I appreciate you technical contributions to the project but I've grown  
quite weary of your impatience and short temper with people who, even  
slightly, might disagree with you or perhaps write something that  
turns out not to be completely precise.


You often seem to work hard at MIS-understanding people's intentions  
and quickly take offense at perceived slights.  Why so sensitive?


Maybe some of your time would be better spent studying mediation or  
taking an anger management class.  I mean, you bother to work up some  
outrage about top or bottom posting??  How tiresome.  Go outside for  
some fresh air.  Practice your breathing exercises.


eo

On Oct 31, 2010, at 3:23 PM, Yuval Levy wrote:


On October 31, 2010 06:11:13 pm Eric O'Brien wrote:

I will say that I think a slightly more tolerant original response on
Yuval's part could have avoided an escalation.  :(


here [0] is my original response.  Would you please be so kind and  
point me to

which part of it is not tolerant enough to your taste?

Yuv (being way to tolerant of your bad habit of top posting [1])

[0] http://groups.google.com/group/hugin-ptx/msg/8a23f6f8a238c5e2
[1] from the netiquette http://www.faqs.org/rfcs/rfc1855.html  "If  
you are
sending a reply to a message or a posting be sure you summarize the  
original
at the top of the message, or include just enough text of the  
original to give
a context. This will make sure readers understand when they start to  
read your

response."


--
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] Where to place feature requests?

[Eric O'Brien]

In this case, I'm referring to the existing "Apply Template" feature  
of Hugin.  So the way to "input the sequence" would be to manually  
adjust a project so that the positions of all the images are as you  
desire, and saving that project.


Then probably copy it somewhere else to a new name that makes you  
think of whatever pattern you used for shooting it.  Later, start a  
new project, import your image and Apply Template.  I don't believe  
there is an explicit "Save Template," and that might make the feature  
less obvious to many users.


eo

On Oct 31, 2010, at 3:06 PM, Bernd Hohmann wrote:



On the other hand, if I (we) are shooting a sequence that is standard
for us, it seems that using a Template would work.  Apply the  
template

would distribute the images in close to the correct locations on the
sphere.  Then the trick would be to get the control point generators
to generate points only between adjacent images.


Good suggestion.

I would accept such templates too, but this leads to the question  
"how to input the sequence?" into the template.


--
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] Where to place feature requests?

[Eric O'Brien]

I will say that I think a slightly more tolerant original response on  
Yuval's part could have avoided an escalation.  :(


eo


On Oct 31, 2010, at 2:38 PM, Bernd Hohmann wrote:


On 31.10.2010 22:28, Yuval Levy wrote:


Because your workflow is crackbrained?


Or your brain crackflowd?


Well - your pleading was the lowest of the low I ever had read.

All the best to your liver,

Bernd



--
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] Where to place feature requests?

[Eric O'Brien]

Well, this is an interesting point.  I also shoot the horizon row  
first, then the zenith, then the nadirs.  That is, I don't proceed top  
to bottom or bottom to top but shoot the middle row, the top "row" and  
then the bottom "row."


For me, the assumption that "pictures that are next to each other in  
the shooting sequence are also next to each other in the panorama."  
will be incorrect.


On the other hand, if I (we) are shooting a sequence that is standard  
for us, it seems that using a Template would work.  Apply the template  
would distribute the images in close to the correct locations on the  
sphere.  Then the trick would be to get the control point generators  
to generate points only between adjacent images.


Next, it would be nice to specify a series of optimization runs (that  
preferably could be run automatically).  For example, first a series  
of runs on the horizon row, then a series on the zenith using also the  
horizon row's control points but *not* optimizing the horizon row this  
time.  Then a similar run for the nadir images.  And now that things  
are very close, maybe optimize the whole bunch again.


eo

On Oct 31, 2010, at 1:47 PM, Bernd Hohmann wrote:

Me (and likely most of the others) is shooting 360° around then  
zeniths and nadir.


so the whole patterns boils down to a "snake" from zenith to nadir  
or the
other way around.  Can't know which one is which, so this must be  
manual

input.




--
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] Hugin Mac 2010.2.0 error loading files

[Eric O'Brien]

Not to mention that the *forward* slash is the directory separator  
symbol on Mac and *nix.  The Finder tolerates a forward slash in a  
file or folder name, but I have found it can cause problems in other  
programs.


Personally, I try to never use spaces in folder names either.  This  
make things more difficult to read, but has greatly reduced the  
frequency of various odd errors I used to encounter.  To make things  
more readable, I often resort to camelCase:  "ColumbiaGorgePan" rather  
than "Columbia Gorge Pan" for example.


While the forward slash is a directory separator on Mac and *nix, the  
backslash is the directory separator on Windows!  If you might ever  
need to move files around between platforms, you'll want to avoid both  
in file and folder names.  Also tempting to use are the apostrophe and  
ampersand.  While I wish I could safely use things like "Bill & Mary's  
Photos," I end up naming the thing "BillAndMarysPhotos" or somesuch.


eo

On Oct 27, 2010, at 2:38 PM, Harry van der Wolf wrote:




2010/10/27 Michael Brubaker 
The files which produce the error are in Storeage Drive\Portland/OR  
Coast/Olympic Park 2011\Canon\Pamorama Files\Columbia Gorge Pan  
3\filename.  The filenames are named HDRtist_6021.jpg and so on.  I  
did just manage to load some picture files into Hugin that were not  
in a directory that had the "/" character in the path, and they  
loaded properly.  Could the "/" character int




You mail was suddenly cut off, but yes indeed: This  backslash is  
the case of the error.  A backslash is normally  used to "escape"   
characters that are otherwise leading to errors. Characters like  
question marks, spaces, exclamation marks, etc. Please do not use  
backslashes.
I don't even know if this can be compensated for in the source code  
as that backslash has a "system" purpose on Un*x, linux,  
{free,open,net}bsd including darwin, solaris, aix.  You name it.


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] [OSX] New hugin-mac-2010.3.0-e432bab64741 bundle with new cpfind and makefilelib

[Eric O'Brien]

However, upon downloading and launching, I got this:



Process: Hugin [2163]
Path:/Applications/Hugin-Enfuse-Enblend-ImageFuser/hugin- 
mac-2010.3.0-e432bab64741/Hugin 2010.3.0.app/Contents/MacOS/Hugin

Identifier:  net.sourceforge.hugin.Hugin
Version: ??? (???)
Code Type:   PPC (Native)
Parent Process:  launchd [105]

Interval Since Last Report:  941958 sec
Crashes Since Last Report:   4
Per-App Interval Since Last Report:  0 sec
Per-App Crashes Since Last Report:   1

Date/Time:   2010-10-10 23:20:11.574 -0700
OS Version:  Mac OS X 10.5.8 (9L30)
Report Version:  6
Anonymous UUID:  5C567855-0C3B-4DA6-A529-B40FE23D1BE7

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0001, 0x8fe0105c
Crashed Thread:  0

Dyld Error Message:
  Library not loaded: /Users/Shared/development/hugin_related/ 
ExternalPrograms/3way-repository/lib/libexiv2.6.dylib
  Referenced from: /Applications/Hugin-Enfuse-Enblend-ImageFuser/ 
hugin-mac-2010.3.0-e432bab64741/Hugin 2010.3.0.app/Contents/MacOS/../ 
Frameworks/icpfind.framework/Versions/A/icpfind

  Reason: image not found

--
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] [OSX] New hugin-mac-2010.3.0-e432bab64741 bundle with new cpfind and makefilelib

[Eric O'Brien]

Harry,

Thanks again for continuing to do battle with all the parts and pieces  
of this thing!  :)


eo



On Oct 10, 2010, at 4:52 AM, Harry van der Wolf wrote:


Hi all,

I built another triple architecture i386/x86_64/ppc bundle.
In this bundle the GSOC-2010 makefile project and the GSOC-2010  
patent_free_cpm project are integrated.
It took some time to integrate these two also due to the fact that  
the cpm has already been expanded again with new functionality (and  
due the fact that my XCode project somehow got corrupted).


In this bundle you can use/test:
The new patent-free CPdetector cpfind (as it is called now) which  
supersedes the "patfree-panomatic" (as I called it in earlier  
bundles and referred to in the defaults as "Pablo's patent free  
Panomatic"). This cpfind is from the GSOC-2010 project done by  
Antoine Deleforge. Thomas Modes already added some new combined  
celeste functionality to it which enables you to run celeste during  
the CP detection to improve accuracy. This will slow down the  
process a bit, but it's worth it I think.
The makefilelib functionality done by by Florian Achleitner. This  
functionality should improve and stabilize the entire process  
dealing with project files (very simply stated), also between Hugin  
and PTBatcher(Gui). I did not test the last one yet.


The makefilelib functionality doesn't require any extra configuration.
The "cpfind" functionality has changed compared to it's predecessor  
"patfree-panomatic". This bundle comes predefined with default  
settings for cpfind (indoors/architectural, no clouds) and cpfind 
+celeste (panos with clouds). From the CPDetectors Preferences pane  
just select the "load defaults". Note: If you also made some exotic  
changes to other CP detectors than please take a note of these  
settings prior to loading the defaults (other CPdetectors? who needs  
other CPdetectors?). You don't need to reinstall the other  
CPdetectors, just reconfigure.
If you just want to add cpfind by hand, than take a quick look at  
the new wiki page(2), which will expand soon (by you?). Note that  
you have to add cpfind as executable WITHOUT browsing for it and  
WITHOUT path reference, just as cpfind.



Tiger users should use the Tiger versions of enblend/enfuse as can  
be found in the "enblend-enfuse-4.0"  folder in the dmg.
(Snow)Leopard users can stick to the builtin enblend/enfuse version.  
These builtin (Snow)Leopard versions are 32/64bit openMP builds.
New users or users switching from 2009.2 and below: If you want to  
use autopano-sift-c and/or panomatic you should download and install  
the correct versions (see (1)). The bundle comes pre-configured for  
autopano-sift-c and panomatic but without the actual programs due to  
patent/license restrictions.



As always: Information and binaries via my website
.
(The binaries themselves are served from hugin.panotools.org who  
kindly provide the disk space and bandwidth).


Harry


(1): Check  for further info about autopano-sift-c and panomatic.

(2): 


--
You received this message because you are subscribed to the Google Groups "Hugin and 
other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Linked bracketing

[Eric O'Brien]

Enblend is not for "merging bracketed shots," it is for seamlessly  
combining overlapping images... it is the "stitcher."


Enfuse is for merging multiple exposures.

eo

On Oct 9, 2010, at 3:09 PM, Bernd Hohmann wrote:


On 09.10.2010 23:43, Erik Krause wrote:


Am 09.10.2010 21:18, schrieb Bernd Hohmann:

enblend doesn't calculate the camera response curve correctly for  
me (if

it uses response curves at all).


No, enfuse (!) uses a totally different approach which doesn't need
camera response curves.


This is the problem: when you use enblend to merge bracketed JPG  
shots at first, the resulting image is broken because it isn't a  
real HDR.


You can process those images in Hugin, but the details are gone  
before.


Thats why I wait for better handling of bracketing shots in Hugin.

Bernd

--
Bernd Hohmann DV Sachverständiger & Gutachter
Höhenstrasse 2 * 61130 Nidderau
Telefon: 06187/900495 * Telefax: 06187/900493
Blog: http://blog.harddiskcafe.de



--
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] photo mosaic & panorama with rendered images

[Eric O'Brien]

Now it would be interesting if the generator could *render* to a sphere!

eo

On Sep 28, 2010, at 5:37 PM, Tom Sparks wrote:

I am rendering a group of images like these (http://www.google.com.au/images?hl=en&q=fractal+flame 
)


Is it possible to create a photo mosaic with these imagwa?
then is it possible to create a spherical panorama?

tom_a_sparks
Light travels faster then sound, which is why some people appear  
bright, until you hear them speak




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

[Eric O'Brien]

It wasn't my recommendation, but I would agree.

Why?  Last heard, negative material can capture a wider dynamic  
brightness range from a scene than transparency material.  Plus, the  
developed film has a *lower* dynamic density range than  
transparencies.  That should make it easier to get higher quality scans.


eo


On Sep 23, 2010, at 7:35 PM, Yuval Levy wrote:


On September 23, 2010 06:26:32 am Carl von Einem wrote:

Shoot color negative film and scan the frames with 16 bit.


any reason why you recommend color negative as opposed to slides?


try VueScan (hamrick.com)


highly recommended.  It has given new life to my old Nikon CoolScan  
LS30

(Nikon stopped publishing drivers after Windows 2000).

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] [OSX] bundle for hugin-2010.2.0_rc1 released

[Eric O'Brien]

"Me too."

That is, downloading using Safari 5.0.1 from a PPC machine, I did not  
see the poll either.


eo

On Sep 17, 2010, at 8:16 PM, AKS-Gmail-IMAP wrote:

And BTW, the download poll worked on the Intel (Safari 5.0.2) but as  
usual did not show on the PPC (Safari 5.0.1).




--
You received this message because you are subscribed to the Google Groups "Hugin and 
other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: enfuse 4.0 and multi page TIFFs

[Eric O'Brien]

Hmm.

I'm not buying in on many of your arguments here.

I don't know enough about this particular change in Enfuse.  Was the  
decision to treat all pages of multipage TIFF files equally taken with  
a clear understanding of the repercussions of that choice?


Certainly it is not the case that all pages will always be of equal  
importance to the user.  Like I say, I wasn't "around the table" for  
the discussion.  But I *have* been around other tables, discussing  
other things.  And this decision sure has the flavor of an  
enthusiastic developer implementing what they personally wanted/ 
needed... without (sorry) "thinking about it a bit further."


Programmers, especially programmers of Open Source tools, build things  
that "ordinary people" (that is, non-programmers) will use.  Over the  
years, I have encountered far too many programmers who are very very  
sensitive to having their work criticized.  A reaction of "Go fix it  
yourself!" is disingenuous -- ordinary users are *not* programmers and  
can't fix it themselves.


eo


On Sep 13, 2010, at 6:52 AM, Yuval Levy wrote:


On September 12, 2010 05:01:21 am Erik Krause wrote:

Am 12.09.2010 08:51, schrieb Harry van der Wolf:

You can also use tiffsplit to split your tiffs first.


Hmm, an additional step that wouldn't be necessary if the programmers
would have thought a bit further...


You might be surprised to find out that the "programmers" (I  
actually prefer

the term "contributing users") actually did think further.

No Free software contributor expects a turnkey solution for his  
problems from
another contributor.  But Free software contributors expect to be  
treated with

respect.  The above statement belittles the work of all those who have
contributed to getting enblend-enfuse where it is now.

The current solution, while not claiming to be perfect, enables GIMP  
users of
multi layered documents to access their TIFFs directly - unlike  
Photoshop
users who need to run their PSD through an extra step like your  
script [0].


Users of PSD files would surely deem as incomplete any software that  
ignores
Photoshop layers other than the background layer.  Similarly, users  
of GIMP

deemed enblend-enfuse incomplete and improved it.

Can it be further improved? of course.  Nobody claims perfection.   
Workarounds
and patches are always welcome and *if the existing / suggested ones  
are not

reasonable for you, you are free to contribute alternatives*.



This should have been an option, not the default behavior in order to
keep compatibility and for ease of use. Or at least there should be a
parameter to deliberately choose the page.


Processing PSD layers is the default behavior of most modern  
applications so

why should the default for TIFF layers be different?

Would you suggest that in order to keep backward compatibility and  
*"ease of

use"* any application importing PSD files should default to import the
background layer only?

On the last sentence of the statement I agree: a parameter to  
deliberately
choose the page would be a neat improvement.  Those who need it can  
work on
it.  A good starting point is to expand on the syntax of the command  
line and
of the response file [1].  How would you identify which layers to  
use and
which to ignore?  Next would be implementation, starting around line  
1587 of

[2].  Patches welcome.



In my opinion enfuse 4 got far too complicated for most users. I
recommend using version 3.2 instead and in most cases this solves
problems. Same applies to enblend...


If staying behind works for you, it is a reasonable and legitimate  
alternative
for you.   Good for you.  You can even fix 3.2 issues such as the  
horizontal

lines artifacts which in my experience are gone from 4.x

What has worked well in the past is not necessarily the best  
solution for the
future.  It is a legitimate personal choice to stay behind.  It is  
not a

legitimate choice to force everybody else to stay behind with you.

Version 3.2 still lives in the repo [3].  You have write access to  
the repo.
Nobody prevents you from branching out and improving on 3.2 if you  
think so
negatively of 4.0.  Anybody is free to branch out there (or anywhere  
else) and
continue 3.2 development, fix 3.2 bugs, improve 3.2 any way they see  
fit if
they don't think that 4.x was the right way to go.  So far all  
contributing

users have been adding to 4.x, an act that speaks for itself.

The added complexity of dealing with layers is not an enblend-enfuse  
problem.
It is a garbage-in garbage-out problem that is solved upstream by  
adequately
controlling the output of the upstream software and/or specifying  
the input to

enfuse.

This discussion reminds me of another recent negative complaint/ 
suggestion in
a completely different setting [4].  It is easy for a *consumer* to  
argue
against higher security for a web-based app in the name of *"ease of  
use"*.
Tell that to the admin who has to "easily" sort out all the s

Re: [hugin-ptx] Re: Hugin 2010.3.0 crashes on startup on OS X 10.6.4

[Eric O'Brien]

Just a report about how this command behaved...

The result is:

   Can't open /var/log/Xorg.t.log: No such file or directory.

I don't need this to work, but I just thought I'd mention it.  (I  
happen to be running OS X 10.5.8).


eo

On Sep 10, 2010, at 5:18 AM, Yuval Levy wrote:


On September 10, 2010 07:19:52 am Harry van der Wolf wrote:

Hi Darrel,

This really needs some further investigation. I really can't  
reproduce your
issues, not even with completely removed and clean installed new  
trunk

versions. Did you try that b.t.w.?


one avenue that you might want to explore to explain this is the  
video card
and driver.  Accept my apology if you already did so, I don't read  
every
detail of OSX related posting since I don't have an interest in that  
O/S.


I had a similar situation of crashes on startup on Kubuntu.  The one  
thing
that changed was the video card driver.  Wiping out everything and  
rebuilding
from scratch helped.  The change in video card driver also caused  
other apps

that use OpenGL to crash in a similar way.

What is the output of the following command on your machine:

perl -n0077 -e 'print "Using driver $1 v$3 by $2.\n" while /Module  
(radeon|

fglrx|intel|nvidia|nv|vesa): vendor="([^"]+)"\n.*version = (\S+)/img;'
/var/log/Xorg.${DISPLAY:1:1}.log

?

I don't know if it will work on OSX, on a fairly standard Linux/Unix  
box it

should parse the X log for your main display.

Also: does the Mac in question have more than one display attached?   
more than

one video card?

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] (Almost) stable hugin 2010.2.0 and libpano13-2.9.17_beta2

[Eric O'Brien]

So... do you suppose I should bother to try compiling this thing (on  
the Mac) again, or maybe wait for the Local Expert (that's you, Harry)  
to come up with something?  ;)


(I did actually get the "compile, etc." part to work, but the  
resulting Hugin silently failed to stitch.  I never got as far as  
tracking down what was going on there.)


Thanks,

eo


On Aug 31, 2010, at 9:25 AM, Harry van der Wolf wrote:


Hi,

We are currently working on a stable release of Hugin being  
2010.2.0. It needs to be compiled against a beta version of  
libpano13, being 2.9.17 beta2.
When do we expect 2.9.17 being stable? Can this be done within/ 
before/simultaneously with the release of Hugin 2010.2.0?


I'm not completely comfortable with the fact that we release a  
stable build (hugin) on top of beta libraries (pano 2.9.17).
I'm well aware of the fact that this beta2 can easily become an RC  
version and then a stable release without further modifications.
But I would like to get some feedback here, if possible, on whether  
we can combine this.


(Says he who has never been release manager for both projects).

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] Re: Jilted Ceilings

[Eric O'Brien]

(I don't know how this works, by the way, just pondering.)

Umm...

When you say that EXIF data is "in" the file, precisely what do you  
mean?  Surely it's not part of the image data.  So... what is it?  A  
"header?"


eo

On Aug 27, 2010, at 11:31 PM, Andreas Metzler wrote:


Eric O'Brien  wrote:

Also, isn't EXIF data stored as Extended File Attributes?


No, exif data is included in the image file.


All you  need is for one program or one file transfer process to
fail to manage  that data correctly and the next thing you know,
your images don't  *have* any EXIF data.  :(



If I copy pictures from *my* camera to *my* computer (with "no" steps
in between), then the EXIF data will probably be there.  But if
someone else emails images to to me, or I email them to myself, (via
which client or service?) or someone puts them on a USB stick (FAT
file system... does it matter?) and hands that to me  or shares them
via Dropbox (the current, released, version does not support xattrs),
then... ?

[...]

None of these should lose exif-data. (Editing image files wth
non-exif aware programs can lose it, though.) Even cameras store
the images on FAT-filesystem (all sd-cards except the newest latest
sdxc).

cu andreas


--
You received this message because you are subscribed to the Google Groups "Hugin and 
other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Jilted Ceilings

[Eric O'Brien]

Also, isn't EXIF data stored as Extended File Attributes?  All you  
need is for one program or one file transfer process to fail to manage  
that data correctly and the next thing you know, your images don't  
*have* any EXIF data.  :(


If I copy pictures from *my* camera to *my* computer (with "no" steps  
in between), then the EXIF data will probably be there.  But if  
someone else emails images to to me, or I email them to myself, (via  
which client or service?) or someone puts them on a USB stick (FAT  
file system... does it matter?) and hands that to me  or shares them  
via Dropbox (the current, released, version does not support xattrs),  
then... ?


I'm just agreeing with Yuval here, I guess.  ;)

eo

On Aug 27, 2010, at 6:40 PM, Yuval Levy wrote:


On August 27, 2010 06:04:06 pm Bruno Postle wrote:

There are plenty of places where Hugin can be improved for all
levels of users, but these days the EXIF metadata generated by
consumer devices is reliable enough to let Hugin stitch a panorama.


I still think it is a mistake in terms of usability to assume that  
the EXIF
data is there and is always valid.  IIRC there has been at least one  
case in
which one version of Windows would mess up the EXIF data of Nikon  
cameras.  It
does not take much to design things to be slightly more fault- 
tolerant, and it

has its appeal as the latest Autpoano Pro vs. Hugin screenshot show.

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] Re: Hugin HDR noobie question

[Eric O'Brien]

Now, now... ;)

(cute animation though!)

The key to the question was "this option doesn't seem to exist in the  
latest version."  Perhaps the original poster should have written  
"...seem to exist in MY version."


That is, they probably don't have the development version of Hugin,  
which is why they don't see the option.


eo

On Aug 26, 2010, at 10:15 AM, Andreas Metzler wrote:


inhumangeek  wrote:
I'm trying to merge bracketted shots into an HDR panorama using  
hugin.
I can't seem to see how this works - I've found a tutorial but it  
says

to choose the "align_image_stack" and yet this option doesn't seem
to exist in the latest version.



http://lmgtfy.com/?q=align_image_stack

align_image_stack is a command-line tool available in the development
version of hugin to align overlapping images to facilitate HDR ...



Can anyone help me please?!


Short version:
Load images, generate control points, optimize, stitch Fused and
blended or Blended and fused.

cu andreas


--
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] Jilted Ceilings

[Eric O'Brien]

My guess is that there are control points between images 1 and 5/6 and  
or 2 and 5/6.  The ceiling looks rather symmetrical from the shooting  
viewpoint and "Hugin" or whatever piece of it is responsible for this  
(the control point generator?) made inappropriate matches between  
images that actually have no overlapping areas.


No exactly "WHY" that happens (how it might be avoided  
programmatically) is a different story.  The fact that Autopano Pro  
succeeded begs the question of why Hugin did not.


eo


On Aug 15, 2010, at 8:53 PM, Dale Beams wrote:


Hi.

Way back in the day (0.7.x), one could hand hold a camera, and take a
pano, hugin would stitch it togather, not perfectly, but well enough  
to

get a decent photo to view.  An example of this would be:

http://www.tatteredmoons.org/pano/20080601-7/20071005-bur_oak_trail_rock.jpg

there are others in my stash of course, with much larger FOV.

Recently an acquaintance asked me to look at a set of photos to see if
Hugin could stitch them together.  When I came out with garbage  
using a

clean build on Ubuntu from 20100730 here is the result:

good match == green bar
http://www.tatteredmoons.org/hugin/screenshots/Screenshot-3.png

alignment shows 2.3 good fit
http://www.tatteredmoons.org/hugin/screenshots/Screenshot-4.png

result
http://www.tatteredmoons.org/hugin/screenshots/Screenshot-5.png

optimization error of 5000+
http://www.tatteredmoons.org/hugin/screenshots/Screenshot-6.png

As you can tell, after the optimization, things went haywire.

My next question was, could another program do what Hugin couldn't do?
Below is the result of AutoPano Pro.  Worked out of the box.  I've not
tried any others yet.

http://www.tatteredmoons.org/hugin/screenshots/Screenshot-7.png
http://www.tatteredmoons.org/hugin/test/ceiling.jpg

So, using the same CPD (autopano-sift-c) we assume that it's finding
similar points, and doing a similar job.  What is going wrong at the
alignment/optimizer stage.

My binaries i used for hugin are located here:

http://www.tatteredmoons.org/hugin/deb/ubuntu/10.04/20100730-hugin_deb.html

which I built according to the wiki for Ubuntu builds located here

http://wiki.panotools.org/Hugin_Compiling_Ubuntu

Test images & pto file are located here

http://www.tatteredmoons.org/hugin/test/test.html





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


--
You received this message because you are subscribed to the Google Groups "Hugin and 
other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: hugin-2010.2.0_beta1 released

[Eric O'Brien]

So you have made some changes in one or more of the installer files,  
right?


If I was feeling inspired to try installing again, how should I go  
about it?  That is, "hugin-2010.2.0_beta1.tar.gz" at SourceForge is  
from July 16.


eo

On Jul 30, 2010, at 4:50 AM, Harry van der Wolf wrote:

The cmake build of 2010.2.0 (as well as the trunk) on OSX works as  
it should be, including the "bare bones" applications.


After Eric O'Briens mail and my "OS less" macbookpro actions, I did  
some theoretical analysis of what I thought went wrong. I was  
incorrect on the most important part: the PATH part when loking for  
binaries.
Then I went wrong on the "bundle less" build for Hugin as wxWindows  
does not allow this (QT4 and Gtk2 have no problems with that b.t.w.)
I was right about the "CMAKE_INSTALL_NAME_DIR" parameter and that  
one has been added now to the main CMakeList.txt file.


Conclusion: Hugin 2010.2.0 (and Hugin 2010.3.0 (trunk)) now build  
correctly and work correctly when built via cmake.


(Off topic: I have updated the entire hugin build plus dependencies  
for MacPorts up to 2010.0.0 (was still at 7.0-svn2903). This is now  
in acceptance testing. You can consider this the same as that hugin  
has been added to the Ubuntu or OpenSuse or Fedora repository. I  
will update 2010.0.0 to 2010.2.0 as soon as it is live. I don't know  
when it comes available in "stable" MacPorts).



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] Some delay on OSX: hugin-2010.2.0_beta1 released

[Eric O'Brien]

I don't think he was *logged in* as root,  (correct me if I have it  
wrong, Harry).  I think he had switched his working directory to the  
*file system* root, then executed "sudo rm ..."


It always seems that somewhere in the make/build/install process,  
commands need to be executed with elevated privileges.  For example,  
the default install location is /usr/local/Application/Hugin.app.   
But /usr is owned by root.  So "make install" fails at some point and  
I had to use "sudo make install."


Now, to delete the files created there I'm going to have to "sudo  
rm ..."  Aren't I?  Or am I going about things the wrong way?


I think one could redefine "rm" so that it wouldn't work from the file  
system root, or maybe warn you how many files you were about to  
destroy.  Or something.  Does anyone have "safety precautions" other  
than being very very careful?


eo


On Jul 25, 2010, at 2:30 PM, Kornel Benko wrote:


Am Sonntag 25 Juli 2010 schrieb Harry van der Wolf:
...
I decided that I could get rid of it, so I did,* from root /*, a  
"sudo rm

-rf *"


Every one has to do it once in his live. This is the hard way to  
learn, not to work as root.

I did it. I know others.

...


(At least my backup infrastructure works great :-) )


Lucky you :)


Harry


Kornel
--
Kornel Benko
kornel.be...@berlin.de


--
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] Panini patents?

[Eric O'Brien]

Have you already published the math involved?  If so, then that would  
amount to "prior art" I would think.  I'm not a patent lawyer, but I  
understand that the existence of prior art would prevent anyone else  
from obtaining a patent on it.


On the other hand if you *don't* formally claim ownership, then I  
guess you'd pretty much have no say about how it was used... it  
essentially would become public domain.  Which you might feel OK about  
if the Hugin project used it, but could get to feeling a little grumpy  
if "JVC" or "Adobe" managed to figure a way to *profit* from it!


eo


On Jul 29, 2010, at 12:21 PM, Thomas Sharpless wrote:

You may have heard rumors that I am planning to patent the Panini  
projection.  That is not strictly true, but as I do hope to do  
something like it, I thought I should make my position clear to the  
group.   I sincerely hope this doesn't start one of those long  
fruitless discussions about the morality/legality/feasibility of  
software patents.


I'm well aware that a patent is one of the least effective ways of  
"protecting" software, and that no patent is likely to generate any  
income without a viable product to go with it.  However I would hate  
to see the Panini projection become the "property" of Adobe or some  
other commercial interest, which could happen if they patent an  
application of it before anyone else does.  So earlier this year I  
filed a "preliminary patent application" with the USPTO, describing  
the panini-general algorithm (as published in libpano13) and three  
plausible applications, realized by different combinations of  
hardware and software.  A preliminary application is just a way of  
establishing priority, and cannot result in a patent.  Its main  
purpose is to support later normal patent applications, and it is  
valid for just 1 year.   As far as I know this type of application  
has no standing in the E.U. or Britain.


So the idea is to apply for proper U.S. patents on some specific  
uses of the Panini projection -- at least one of them commercially  
viable -- before next Spring.  That will involve hiring a good  
patent attorney, which can cost a significant amount of money,  and  
possibly other legal costs such as setting up a corporation or  
foundation to manage the patent rights.  So I don't want to do it  
unless and until there is at least a fair prospect of selling  
something.  Those patents would not claim protection for the Panini  
projection as such, which is probably not patentable anyhow, but  
would hopefully make it hard for others to patent or sell similar  
applications of it.  And they might conceivably earn Bruno and me a  
bit of royalty income.


In case any such patents are granted, it is my firm intention to  
issue blanket free licenses covering any and all uses of the  
"protected" technology in open source software that is licensed  
under GPL Version 3 (and any compatible free software licenses).   
That can apparently be made perfectly legal,  even in the greedy  
U.S., as IBM and Red Hat have done with a large pool of software  
patents they own.  Bruno assures me he would not object to having  
his name on a patent licensed that way, and as he really discovered  
the Panini projection I think it should be there.


It is important for this strategy that ownership of the basic  
patents stays in the hands of a reliable organization unlikely to be  
taken over by "patent trolls" (as Ipix and SCO so sadly were).   
Hence the foundation idea.   But any seriously money-making  
application would almost certainly have to be covered by additional  
patents owned outright by a manufacturer (otherwise nobody would  
want to build it).  For example let's say JVC decides to offer an  
ultra-wide angle video camera based on the Panini projection.  They  
would absolutely want Canon et al not to be able to do the same, and  
would no doubt apply for several patents on the technology.  The  
trick for keeping the software free is to have the "Panini  
foundation" be in a position to sell them an exclusive license for  
some key elements of the video processor, that is limited, say, to  
in-camera video processors and would not preclude licensing someone  
else to use the same technology for rendering movies in a post- 
production facility.  Then JVC can patent the hell out of their  
camera without infringing the right of Hugin users to use panini- 
general.


I'm sure the trick is doable, but it clearly needs both good legal  
preparation and good management of the patent rights.  Which in turn  
need to be sustained by some revenue.  So it won't happen unless I  
can actually find some customers who want to build and sell Panini- 
based products.  If I were 20 years younger I'd probably try to  
start a company to make TV and movie rendering software (and  
probably lose my shirt) but as it is, someone else is going to have  
to do that.  If any of you wants to volunteer, or knows how to sell  
n

Re: [hugin-ptx] Re: New hugin-mac-2010.1.0-38ed0587798b 32/64bit bundle

[Eric O'Brien]

I just came across this:

Mac OS X v10.6: About gamma 2.2
<http://support.apple.com/kb/HT3712>  (Last Modified: May 06, 2010)

"To better serve the needs of consumers and digital content producers,  
Mac OS X v10.6 Snow Leopard uses a gamma value of 2.2 by default.   In  
versions of Mac OS X prior to 10.6, the default system gamma value was  
1.8."


I had been under the impression that Apple had changed to gamma of 2.2  
several years ago, but I guess not!


I *think* this change should noticeable only when viewing images that  
do not have a color profile.  You wrote "the
picture goes very flat if I strip an sRGB profile..."  If by that you  
mean that you leave the image without a profile, then, according to  
the kb article


"... images that do not contain color profiles might appear darker in  
Mac OS X v10.6 than they did in earlier versions of Mac OS X.  Adding  
the sRGB IEC61966-2.1 profile or Adobe RGB (1998) profile to these  
images lets them display correctly."


They say "darker," you say "flat."  Hmm.

If your images have color profiles attached, and you use a custom  
profile for your monitor and a custom or manufacturer's profile for  
your printer, then this "change" to gamma 2.2 in OS X 10.6 should not  
matter.


eo


On Jul 14, 2010, at 1:09 AM, Martin Middelhoek wrote:


The SL stands for OS X 10.6 aka Snow Leopard. I make the distinction
with 10.5 aka Leopard, because the color management and printer driver
stuff have been subtly modified in this revision. In 10.5 and with
Aperture2 it was clear what to do independent of the printer. Now in
10.6 and with Aperture3 the final step of the color management has
been delegated to the manufacturers printer driver, which is a world
of pain. Most people with an Epson are still fighting; luckily I have
a Canon but I am still not completely happy with the results on some
non-Canon papers.

Mark Dubovoy is mainly referring to these printing problems in OS X
with the hand-off from the application to the printer driver.

The choice between sRGB and Adobe RGB comes down to the gamut of the
image. If the image has a wide gamut to begin with it is better to go
with Adobe, with rather "flat" images sRGB will utilize the bits
better. I do mainly landscapes and have never been able to see the
difference in a side by side comparison (maybe with a better monitor
or printer...). So I go with sRGB mainly for the better compatibility
between applications and devices. Adobe gets so easily tripped up
somewhere in the workflow. The 16-bit versus 8-bit debate is also
interesting. I never expected to see the difference, but I did, and
always in deep blue skies. There the hue changes very subtly, and you
require all the resolution you can get to prevent banding. The 8-bit
images fall apart too easily when imported back into Aperture and
subjected to final adjustments.

I have started a thread in the Apple forums to find out how OS X
handles (or should handle) images without a color profile. I always
assumed it would default to sRGB, but it appears that it does not: the
picture goes very flat if I strip an sRGB profile, so maybe Adobe is
the default?

As you say, slightly off topic. But this is the Hugin on OS X thread,
so only slightly.

Martin

On Jul 14, 7:14 am, Eric O'Brien  wrote:

First, I guess missed something along the way.  You (Martin) wrote
"...I have not yet discovered how images
without a profile are supposed to be handled in SL."  Uh... what is
"SL?"

Next, I don't know if there's a "default" color space in OS X, but if
you are going as far as using 16 bit deep images it seems counter
productive to use a color profile on the list that has pretty much  
the

smallest gamut.  Of course, *eventually* you would probably want to
reduce the pano to 8 bit sRGB, but while you're working with it it
seems that a wider gamut such as Adobe RGB (1998) or ProPhoto RGB
would be better.  In theory anyway... I don't know if ordinary  
persons
would be able to see any problems if you just kept using sRGB.   
(Adobe

RGB is much larger than sRGB and ProPhoto is much, much larger than
Adobe RGB.)

Slightly off topic now, but it appears that there are circumstances  
on
the Mac where it is *impossible* to have "no" color management.   
See <http://www.luminous-landscape.com/tutorials/solving.shtml

 >

eo

On Jul 13, 2010, at 2:10 AM, Martin Middelhoek wrote:




Hi Harry,



thanks for the prompt response.



I export from Apple Aperture3 to 16-bit TIFF with the color profile
sRGB IEC61966-2.1. It was my believe that sRGB was the default color
space on OSX, so loosing the profile would not lead to disaster.
Obviously I was wrong, but I have not yet discovered how images
without a profile are supposed to be handled in SL. The finished
pano's get imported back into Aperture for final adjustments and are
then expo

Re: [hugin-ptx] Not getting layers, only individual images

[Eric O'Brien]

Replying to your last question here:  For me, yes "/var/folders/Hg/"  
exisits.  It's current size is about 109 MB.  There are *quite* a  
number of folders and files in there.  Most clearly not from Hugin.  I  
asked the question because text in the "Stitching" window seems to  
indicate that temporary files were being created/reference here.   
(Name of the files were very long, perhaps hex, strings.)


eo

On Jul 24, 2010, at 12:59 PM, Bruno Postle wrote:


On Fri 23-Jul-2010 at 20:12 -0700, Eric O'Brien wrote:


The "Stitching" window does not show in the application switcher,  
or in Hugin's "Window" menu (something I found counter-productive,  
FYI).  When things stopped happening, the "Stitching" window was  
lost among many other windows I had opened and I assumed everything  
had successfully completed successfully.   That window apparently  
went away when I quit Hugin.


The window that shows the stitching log is a separate process, you  
can close Hugin and it should stay around until stitching finishes.


But I am puzzled about the temp file locations.  If these *are*  
temp files, why are they appearing here, rather than in the  
"Temporary dir" location I have specified in Hugin prefs?


Intermediate files are currently written to the same folder as the  
output panorama.  The 'remapped images' checkbox just disables  
deleting them at the end of stitching.


Hmm.  Thanks.  I don't believe I actually checked "Remapped images"  
under either "Normal" or "Exposure fusion, but your info would support  
my idea that what I thought were final results actually were  
intermediate images.




The whole Makefile generation system is being refactored as part of  
the Summer of Code, this should make it easier to change stuff like  
this in the future.


Furthermore, why is nona apparently putting *its* temp files in / 
var/folders/Hg/  ?


No idea, does this folder even exist?

--
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] Re: hugin-2010.2.0_beta1 released

[Eric O'Brien]

It says "cmake version 2.8.2"

eo

On Jul 24, 2010, at 5:18 AM, Harry van der Wolf wrote:




2010/7/23 Eric O'Brien 
For what it's worth...

I have very little idea of what I'm doing here, but I managed to  
compile this on my Macintosh.  It may not have been completely  
"successful" however.


The program ended up at /usr/Application/Hugin.app, along with  
separate programs "HuginStitchProject.app" and "PTBatcherGUI.app."


The program will *run* but the stitching window opens, displays  
three lines of text, then vanishes too quickly for me to read what  
those lines were.  Maybe this is just a symptom of what you are  
describing?


In regards to trying to track this sort of thing down, is Hugin and  
friends writing to any log(s)?


eo


Hi Eric,

Your problem is something else. In my case hugin (or one of the  
others) don't even start.
I'm currently on cmake 2.8.1. I have been relatively long on the  
2.6.x series and they worked OK.

What version are you using  (cmake --version)?

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] Not getting layers, only individual images

[Eric O'Brien]

I now *think* I have an idea of what's going on here.

Whatever it is seems to happen only if I have Output: Normal, "Blended  
panorama" checked *at the same time* as any of the first three options  
under Exposure fusion.  *Without* "Blended panorama" checked, I get  
expected results from "Blended and fused panorama" and "Blended  
exposure layers."


I think what I took to be incorrect output files actually were  
intermediate (temp) files created by, perhaps, enblend.


The "Stitching" window does not show in the application switcher, or  
in Hugin's "Window" menu (something I found counter-productive, FYI).   
When things stopped happening, the "Stitching" window was lost among  
many other windows I had opened and I assumed everything had  
successfully completed successfully.   That window apparently went  
away when I quit Hugin.


But I think what happened is that enblend stalled or hung, and I  
previously I didn't notice it.  Today, I noticed that messages had  
stopped appearing in the "Stitching" window and the odd collection of  
files that had been accumulating in my work folder stopped  
accumulating.  (That "work" folder contains the source images and the  
Hugin project file.  It is also where I specified the output files be  
created.)


While I went on some errands, I left everything running.  About 4  
hours later, nothing has changed.  Activity Monitor tells me that  
enblend is taking about 85 to 95 percent of my CPU time, so it's still  
running and I suppose is busy at something.



For this run, I had selected Normal: "Blended panorama and "Exposure  
fusion: Blended and fused panorama."  In my work folder are now a  
number of files:


Just one, named .tif, which looks like it s the blended and  
fused version.  [Note:  of course, "" is just a placeholder  
for the actual name I used.]


Then there are 24 files named .tif through  
0023.tif.


Next, there are 8 files named _exposure_layers_.tif  
through 0021.tif


Finally, a single file named exposure_00.tiff.  That's only  
4KB



The last messages in the "Stitching" window are

enblend: info: loading next image: _exposure_layers_.tif  
1/1
enblend: info: loading next image: _exposure_layers_0003.tif  
1/1
enblend: info: loading next image: _exposure_layers_0006.tif  
1/1



I don't really need an "answer" to any of my experience here, as I  
seem to be getting what I want as long as I do NOT check anything  
under "Normal" on the Stitcher tab.  (Of course, not having such  
mysterious behavior happen would be more pleasing.)


But I am puzzled about the temp file locations.  If these *are* temp  
files, why are they appearing here, rather than in the "Temporary dir"  
location I have specified in Hugin prefs?  Furthermore, why is nona  
apparently putting *its* temp files in /var/folders/Hg/  ?


I'll stop now.  Thanks,

eo


On Jul 21, 2010, at 1:22 PM, Bruno Postle wrote:


On Wed 21-Jul-2010 at 12:12 -0700, Eric O'Brien wrote:


Mind you, the problem isn't (yet) a failure to blend... it is a  
failure to keep images in three "layers" rather than break the  
project up into one "layer" per source image.


Exactly how does Hugin determine which images belong "together?" If  
it is the exposure value, how close to identical do these need to be?


0.5EV, but this only applies when you have chosen 'Blended and fused  
panorama'.  At some point this needs to become configurable, but  
Hugin currently doesn't give any feedback as to where it thinks  
there are stacks and exposure layers.



Finally, can someone point me to documentation on stacks?


There is some here: http://wiki.panotools.org/Hugin_Stitcher_tab#Exposure_fusion

..but there isn't anything yet on 'linked stacks', which is a new  
feature for 2010.2.0.


--
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] Re: hugin-2010.2.0_beta1 released

[Eric O'Brien]

For what it's worth...

I have very little idea of what I'm doing here, but I managed to  
compile this on my Macintosh.  It may not have been completely  
"successful" however.


The program ended up at /usr/Application/Hugin.app, along with  
separate programs "HuginStitchProject.app" and "PTBatcherGUI.app."


The program will *run* but the stitching window opens, displays three  
lines of text, then vanishes too quickly for me to read what those  
lines were.  Maybe this is just a symptom of what you are describing?


In regards to trying to track this sort of thing down, is Hugin and  
friends writing to any log(s)?


eo

On Jul 22, 2010, at 12:43 PM, Harry van der Wolf wrote:




2010/7/22 Lukáš Jirkovský 
On 22 July 2010 18:37, Harry van der Wolf  wrote:
>
>
> I see that I made a typo in cmake -cmake_install_dir="blahblah" ..
> It should be: cmake -cmake_install_name_dir="blahblah" ..
>
> And  that's something completely different than the install prefix.
> Sorry for the confusion.
>
> I'll go looking whether cmake is wrong or hugin.
>
> Harry
>

I think it is cmake -DINSTALL_NAME_DIR="blah" .

Lukas



Oh, #?!$.

I seem to be making typos all the time. Sorry again.


According to the documentation it is:

CMAKE_INSTALL_NAME_DIR: Mac OSX directory name for installed targets.
CMAKE_INSTALL_NAME_DIR is used to initialize the INSTALL_NAME_DIR  
property on all targets. See that target property for more  
information.




Which means that you use it in CMakeList.txt as


IF(APPLE)
  SET_TARGET_PROPERTIES(huginvigraimpex  PROPERTIES INSTALL_NAME_DIR  
"${prefix}/lib")

ENDIF(APPLE)

(and I also tried:

IF(APPLE)
  SET_TARGET_PROPERTIES(huginvigraimpex  PROPERTIES INSTALL_NAME_DIR  
"${CMAKE_INSTALL_PREFIX}/lib")

ENDIF(APPLE)

)

and on the command line as

cmake -dcmake_install_dir="blahblah" ..

Nothing works. (I think) I tried all options and also interchanged  
the install_name_dir and cmake_install_name_dir.


I'll search further but I'll go over to the XCode build now.

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


--
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] Not getting layers, only individual images

[Eric O'Brien]

I'm running Hugin 2010.1.0.38ed0587798b on a Macintosh (Harry's  
build).  The Mac is a G4 running OS X 10.5.8.


On the Stitching tab, I have UNCHECKED both "Use alternative Enblend  
program" and "Use alternative Enfuse program."  My understanding it  
that this will cause Hugin to use the internal versions.


The "stitching" process runs to conclusion without revealing any errors.

Mind you, the problem isn't (yet) a failure to blend... it is a  
failure to keep images in three "layers" rather than break the project  
up into one "layer" per source image.


Exactly how does Hugin determine which images belong "together?" If it  
is the exposure value, how close to identical do these need to be?


Finally, can someone point me to documentation on stacks?

Thanks,

eo


On Jul 21, 2010, at 5:13 AM, Nicolas Pelletier wrote:

When you run the stitching process, do you get any errors in the  
logging window? Or does it finish gracefully but without any blended  
images?


Also, can you confirm enblend is there and working?

Last but not least, what version of hugin exactly on what platform!

Thanks

nick

On Tue, Jul 20, 2010 at 8:03 PM, Eric O'Brien  
 wrote:
I'm trying to stitch a panorama made up of 3 exposure steps of 11  
images (33 images total).


I have changed a number of things, but the output I keep getting is  
remapped *individual* images.


Output is set to "Blended panorama"

Things I have tried:

Add stacks.  That is, put each set of three exposures into it's own  
stack.


Under Exposure fusion set
  Fused and blended panorama
  Blended and fused panorama
  Blended exposure layers

I always get individual images, not exposure layers or any flavor of  
"stitched" panorama.


Any ideas?


eo




--
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] Not getting layers, only individual images

[Eric O'Brien]

I'm trying to stitch a panorama made up of 3 exposure steps of 11  
images (33 images total).


I have changed a number of things, but the output I keep getting is  
remapped *individual* images.


Output is set to "Blended panorama"

Things I have tried:

Add stacks.  That is, put each set of three exposures into it's own  
stack.


Under Exposure fusion set
   Fused and blended panorama
   Blended and fused panorama
   Blended exposure layers

I always get individual images, not exposure layers or any flavor of  
"stitched" panorama.


Any ideas?


eo

--
You received this message because you are subscribed to the Google Groups "Hugin and 
other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: New hugin-mac-2010.1.0-38ed0587798b 32/64bit bundle

[Eric O'Brien]

First, I guess missed something along the way.  You (Martin) wrote  
"...I have not yet discovered how images
without a profile are supposed to be handled in SL."  Uh... what is  
"SL?"


Next, I don't know if there's a "default" color space in OS X, but if  
you are going as far as using 16 bit deep images it seems counter  
productive to use a color profile on the list that has pretty much the  
smallest gamut.  Of course, *eventually* you would probably want to  
reduce the pano to 8 bit sRGB, but while you're working with it it  
seems that a wider gamut such as Adobe RGB (1998) or ProPhoto RGB  
would be better.  In theory anyway... I don't know if ordinary persons  
would be able to see any problems if you just kept using sRGB.  (Adobe  
RGB is much larger than sRGB and ProPhoto is much, much larger than  
Adobe RGB.)


Slightly off topic now, but it appears that there are circumstances on  
the Mac where it is *impossible* to have "no" color management.  See 


eo

On Jul 13, 2010, at 2:10 AM, Martin Middelhoek wrote:


Hi Harry,

thanks for the prompt response.

I export from Apple Aperture3 to 16-bit TIFF with the color profile
sRGB IEC61966-2.1. It was my believe that sRGB was the default color
space on OSX, so loosing the profile would not lead to disaster.
Obviously I was wrong, but I have not yet discovered how images
without a profile are supposed to be handled in SL. The finished
pano's get imported back into Aperture for final adjustments and are
then exported again as 8-bit TIFF and sRGB to Pano2VR. There also
seems to be a color profile issue with that application which I will
try to tackle next (or maybe it is just a scaling thing).

My whole flow is color managed and calibrated using icc-profiles all
the way. As a stopgap I can use Preview to assign the correct profile
and after that the input and output of Hugin are indistinguishable. I
will try to figure out where the profile information is living in the
images. In preview it shows up under General Info as "ColorSync
profile: sRGB IEC61966-2.1" and under More info -> General as "Profile
Name sRGB..". Is there any reason why exiftool -all:all can't find it,
all groups and all writeable tags, right?

Martin

On Jul 13, 9:17 am, Harry van der Wolf  wrote:

2010/7/13 Martin Middelhoek 


Hi Harry,


just found another bug: Hugin is stripping the color profile from  
the

output file; or maybe not copying it.



I tried to use exiftool -all:all to copy it myself, but to no avail.
Where is this going wrong? I seem to remember that this once worked.



This explains some of the weird color casts that I have been seeing.



Martin


Hi Martin,

These are the settings that exiftool should use:
#define HUGIN_EXIFTOOL_COPY_ARGS   "- 
ImageDescription -Make

-Model -Artist -W
hitePoint -Copyright -GPS:all -DateTimeOriginal -CreateDate - 
UserComment

-ColorSpace -OwnerName -SerialNumber"

These parameters are missing the "-icc_profile" and the  "-XMP"   
option tags
from exiftool. I think that's the biggest problem for you as  
colorspace is
not the only parameter that should be used when using images with  
color

profiles.

IMO, Hugin could and should also use: "-IPTC:all -JFIF:all - 
ColorSpace

-icc_profile -XMP"
I will post a separate mail about this asking users if I can add  
these to
the trunk or whether there are some serious arguments why I should  
do that.


What kind of input files do you use and what kind of output files  
(including

bit depths)?
Are you using icc color profiles?*

*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


--
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] Increase Corner Detection Sensitivity

[Eric O'Brien]

A good question.

In my opinion, this situation is one thing that limits the accuracy of  
the Lens Correction Parameters ("a," "b," "c," etc.) obtained from  
automatically created control point pairs.


The the vexing problem is that regions where it is *most* important to  
have good values are exactly the same regions where automatic control  
point generators place NO points.  The problem probably doesn't occur  
with lower distortion lenses, but certainly does with circular or full  
frame fisheyes.


The way that I have always dealt with this is to manually add a few  
control points at the sides, and particularly the corners, of  
overlapping images.  The manually added points plus the automatically  
generated ones can produces very accurate lens parameters -- judged by  
the small error numbers during optimization and the complete absence  
of any visible stitching errors.  But this requires manual  
intervention for every single stitch.


I realize that after you have done this once, with a images from a  
representative panorama, you will then probably then have a very good  
starting point for future stitches.  You can save the "lens" (Camera  
and Lens tab), then load it for future panoramas, or save a successful  
project and use it as a Template for future stitching.


But what I'd really like to see is a control point generator that  
could accurately place points for images from fisheye lenses far away  
from the image center.


eo

On Jul 2, 2010, at 4:39 PM, pfanous wrote:


I'm using align_image_stack. I notice that the effectiveness of the
alignment is related to how well the corner detection / control point
generation process performs. For certain images, the control point
generation is very limited.

I'm wondering if there's away to increase its effectiveness by some
means. For instance, does it use median filtering to help out the
corner detection process? If so, is there some way to increase the
radius / patch size? How can I modify the delta that it uses as a
threshold to determine if an edge is an edge?



--
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] Compiling Hugin on Mac OSX

[Eric O'Brien]

Hello!

I'm attempting to follow the instructions at .


End result:

Apparent "success" with the steps.  Except then

"... you're finished. Look for the new bundle Hugin.app in usr/ 
local/Applications/ or in usr/local/bin/."



eh ...  I have no /usr/local/Applications directory.  There is no  
Hugin.app in usr/local/bin/.


Comment:  How would I know to look in either of those locations?  Why  
am I instructed to look in either of TWO directories?  Surely this is  
specified in some build/make file somewhere.  Right?  And does that  
spec offer the option of "either/or??"


Plus, note that /usr is not a visible directory.  Why would I want  
Hugin installed in an normally invisible directory??


. . .

Instead, I find the newest Hugin.app on my computer is at

   /Applications/hugin_build/src/hugin1/hugin/Hugin.app.


When I run that program I receive the error:

Fatal Error

xrc directory not found, hugin needs to be properly installed
Tried Path: /usr/local/share/hugin/xrc/

OK

No, it is not "OK"

And, hey, could y'all please do whatever necessary to make it possible  
to SELECT the text in such error messages?  Transcribing it from a  
displayed window is tedious and prone to error.


Also, the error message is not what I would call "helpful."  "hugin  
needs to be properly installed" Oh excuse ME!  I am so sorry.  It is  
entirely my fault  :(


Sheesh.  Now, would you please explain PRECISELY what you don't like,  
how it might have come to be, and how I can fix it?  [And by the way,  
should not "hugin" be capitalized as "Hugin"  ?]



"xrc directory not found"  Why not?  Why do you care?  Where were you  
looking?  Why were you looking THERE?  How can I change where you were  
looking?


The only file I have in /usr/local/share is a directory named "man."   
Why is Hugin looking *there* for hugin/xrc/ ??  Again, that must be a  
setting that's defined somewhere, right?  Please let us know where  
that's being specified!  And... any guesses why it is wrong in my case?


I DO see an xrc directory at  /Applications/hugin_build/src/hugin1/ 
hugin/xrc.   Hmm.  Maybe if I somehow can manage to tell Hugin to look  
*there* instead in /usr/local/share/hugin/xrc/ I might get it to work.


Uh... How can I tell Hugin to do that??  *should* I try to do that, or  
is the problem elsewhere?



Hey Readers!

Feel free to choose *any* of my several problems/confusions and offer  
suggestions!



Thanks,

eo

--
You received this message because you are subscribed to the Google Groups "hugin and 
other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Hugin 2010.2.0 release process

[Eric O'Brien]

Gee, with Mercurial, this sort of stuff is supposed to... Just Work!  :)

Umm... did it?

eo

On Jun 28, 2010, at 2:07 PM, Bruno Postle wrote:


On Sat 26-Jun-2010 at 17:15 +0100, Bruno Postle wrote:


So we need to create a Hugin branch, then:

Increment the version numbers in both the 'stable' branch and the  
'trunk'.


Ok, I *think* I've done this, there should now be a 2010.2 branch in  
addition to the default 'tip' which now builds as 2010.3.0.


Though Harry was pushing stuff at the same time, so I hope I haven't  
made too much of a mess.


--
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] Hugin: photo tricking with the mask editor

[Eric O'Brien]

I think you could have at least changed shirts for each shot!  ;)

eo

On Jun 12, 2010, at 4:46 AM, Harry van der Wolf wrote:


Hi,

The idea for this post originates from a discussion on panotoolsng  
(1) in which I also participated. I already did the same thing about  
8 years back with my children in it, using gimp.


This morning I did a real quick one with Hugin's builtin mask editor  
(again: Thanks Thomas for this great feature).


I setup my tripod, used the self-timer and shot 6 images in the back- 
yard. Not really a pano though, but a show case for the mask-editor.


Note: I did not much to improve the image. Next to that there was a  
strong wind which results in blurred leafs and branches. Never the  
less this is about 35-40 minutes from image taking to complete  
picture.


Actions in Hugin:
- load images
- run a cp detector (Pablo's patent-free panomatic-lib in this case)
- simple optimize
- Set projection to rectilinear
- In mask-editor I created the masks (remember to set them to  
"include region")
- On stitcher pane: Uncheck "blended panorama" (as enblend 4.0  
complaints about "excessice overlap")  and check "Fused and blended".


See here: 

In case you always wondered what I look like, this is your  
chance :-)  (and sorry for the white feet).


Harry

Ps: I also showed this image to my wife and sent it to my mother.  
They always complain I'm not often enough in the picture, being the  
photographer. This is often enough I think.



(1): 


--
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] Hugin source code visualization

[Eric O'Brien]

Plus, this should make everyone want to put *everything* under source  
control, just so they can visualize their activity!  :)


eo

On Jun 10, 2010, at 1:18 AM, David Haberthür wrote:


Hey all.
Now that hugin recently switched to Mercurial for Code revision, I  
thought I could try something fun with it:
Recently I stumblede over gource [1] a nice tool for the  
visualization of sourcecode. I've used gource to visualize the  
progress of my PhD-Thesis ([2], which was handed in a week ago btw)  
and thought I'd do this for hugin.
It turned out to be a little bit of a challenge, but let me walk  
through to the end-result:


On OS X it's pretty easy to install all the necessary things to make  
the resulting movie, just make sure you've installed MacPorts [3]  
and issue

 $ sudo port install mercurial ffmpeg gource
in Terminal.app to install the necessary stuff. Then drink a coffee,  
because this takes a long time :)


Using a simple
 $ hg clone http://hugin.hg.sourceforge.net:8000/hgroot/hugin/hugin  
hugin
in a directory of choice downloads hugin's source code. Again, do  
this in the Terminal.app.


"Cd" into hugins directory and enter the following command:
 gource -800x600 --disable-progress --stop-at-end --bloom-multiplier  
1.25 -a 0.05 --output-ppm-stream - | ffmpeg -y -b 3000K -r 60 -f  
image2pipe -vcodec ppm -i - -vcodec libx264 -vpre default hugin.mp4
This command instructs gource to make a 800x600 pixel movie with  
some tweaks, outputs this to a ppm-stream and converts this stream  
with ffmpeg to a resulting movie, hugin.mp4. Go and have another  
coffee, since this can take even longer than the command above...  
After you've marveled at the nearly 3 GB, two-hour (!) long movie  
(or maybe not :) you wonder how to present this movie.


Fiddling around with iMovie [4] in the end you get this: 
http://vimeo.com/12442226

It's beautiful! My way of saying "Thank you" to all the developers  
and coders of hugin. You've done a great job, I love to use hugin.  
Keep it up!


Greetings from Switzerland
Habi


[1]: http://code.google.com/p/gource/
[2]: 
http://habi.gna.ch/2010/05/14/codevisualisierung-mit-gource-so-arbeitete-ich-an-meiner-diss/
[3]: http://www.macports.org/
[4]: http://www.apple.com/ilife/imovie/. The fiddling with iMovie  
involved conversion of the movie to alter its speed, since iMovie  
can only speed up to 2000%, which was not enough to go from +2 hours  
to 4 minutes in one step. Since I've had a nice song as a  
background, I had to to multiple exports and imports to speed the  
movie up to the necessary 4.5 minutes,


--
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] Hugin source code visualization

[Eric O'Brien]

Wow!

That is mesmerizing!  The music certainly helps increase the effect.

eo

On Jun 10, 2010, at 1:18 AM, David Haberthür wrote:


Hey all.
Now that hugin recently switched to Mercurial for Code revision, I  
thought I could try something fun with it:
Recently I stumblede over gource [1] a nice tool for the  
visualization of sourcecode. I've used gource to visualize the  
progress of my PhD-Thesis ([2], which was handed in a week ago btw)  
and thought I'd do this for hugin.
It turned out to be a little bit of a challenge, but let me walk  
through to the end-result:


On OS X it's pretty easy to install all the necessary things to make  
the resulting movie, just make sure you've installed MacPorts [3]  
and issue

 $ sudo port install mercurial ffmpeg gource
in Terminal.app to install the necessary stuff. Then drink a coffee,  
because this takes a long time :)


Using a simple
 $ hg clone http://hugin.hg.sourceforge.net:8000/hgroot/hugin/hugin  
hugin
in a directory of choice downloads hugin's source code. Again, do  
this in the Terminal.app.


"Cd" into hugins directory and enter the following command:
 gource -800x600 --disable-progress --stop-at-end --bloom-multiplier  
1.25 -a 0.05 --output-ppm-stream - | ffmpeg -y -b 3000K -r 60 -f  
image2pipe -vcodec ppm -i - -vcodec libx264 -vpre default hugin.mp4
This command instructs gource to make a 800x600 pixel movie with  
some tweaks, outputs this to a ppm-stream and converts this stream  
with ffmpeg to a resulting movie, hugin.mp4. Go and have another  
coffee, since this can take even longer than the command above...  
After you've marveled at the nearly 3 GB, two-hour (!) long movie  
(or maybe not :) you wonder how to present this movie.


Fiddling around with iMovie [4] in the end you get this: 
http://vimeo.com/12442226

It's beautiful! My way of saying "Thank you" to all the developers  
and coders of hugin. You've done a great job, I love to use hugin.  
Keep it up!


Greetings from Switzerland
Habi


[1]: http://code.google.com/p/gource/
[2]: 
http://habi.gna.ch/2010/05/14/codevisualisierung-mit-gource-so-arbeitete-ich-an-meiner-diss/
[3]: http://www.macports.org/
[4]: http://www.apple.com/ilife/imovie/. The fiddling with iMovie  
involved conversion of the movie to alter its speed, since iMovie  
can only speed up to 2000%, which was not enough to go from +2 hours  
to 4 minutes in one step. Since I've had a nice song as a  
background, I had to to multiple exports and imports to speed the  
movie up to the necessary 4.5 minutes,



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


--
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] Hg Init: a Mercurial tutorial

[Eric O'Brien]

I'm not using Mercurial, but for those that are, or are trying to  
figure things out, perhaps this


Hg Init: a Mercurial tutorial 

by Joel Splosky, might be useful.

The very first section is called "Subversion Re-eduction"  ;)

Want to know something funny?  Almost every Subversion team I’ve  
spoken to has told me some variation on the very same story.  This  
story is so common I should just name it “Subversion Story #1.”  The  
story is this: at some point, they tried to branch their code, usually  
so that the shipping version which they gave their customers can be  
branched off separately from the version that the developers are  
playing with.  And every team has told me that when they tried this,  
it worked fine, until they had to merge, and then it was a nightmare.   
What should have been a five minute process ended up with six  
programmers around a single computer working for two weeks trying to  
manually reapply every single bug fix from the stable build back into  
the development build.


...

When you switch to Mercurial, you may not even realize it, but  
branching becomes possible again, and you don’t have to be afraid.




eo

--
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] Hugin based camera tracker

[Eric O'Brien]

Not free, but not terribly expensive (at USD99.00 or 199.00) is  
"PFhoe" found at .  I have no experience with it.


eo

On May 29, 2010, at 11:29 AM, Mikko Lempola wrote:


Idea: Let's convert Hugin to a match moving camera tracker.



Perhaps Hugin could be as a base to a free camera tracker. What is a
camera tracker you might ask. Well...
http://en.wikipedia.org/wiki/Match_moving

At the moment there is no free alternatives to a commercial products
like Syntheyes and Voocat except Voodoo which is freeware and not
permitted to commercial usage. Check Voodoo here:
http://www.digilab.uni-hannover.de/docs/manual.html

Camera tracking done with Voodoo can then be exported (with Voodoo) to
a file that Blender (free and open source 3d modeling and animation
program) understands. You can get a good picture what this is all
about and test camera tracking by yourself by looking these youtube
videos:
Part one
http://www.youtube.com/watch?v=kPZbtKQ1a4g

Part two
http://www.youtube.com/watch?v=dREGzpAGKyA

(Of course, Blender skills are highly recommended for testing it.)


Surely there are only very few of them who happens to use Hugin, use
Blender, know what is a camera tracker, need it and have required
programming skills (which I don't have) - and motivation to do it.
However, at least one effort has been done althought it is not Hugin
based:
http://wiki.blender.org/index.php/User:Keir/TrackingDiary

Probably it was too large effort for a one person voluntary project.
Therefore I'm here to ask if Hugin developers are willing to create an
open source camera tracker.
(Somebody has to create the spark, some one else must do all the hard
work.)

Any ideas how to continue from this?

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


--
You received this message because you are subscribed to the Google Groups "hugin and 
other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

Re: [hugin-ptx] Re: Error when trying to find CP's with any detector and any version of Hugin

[Eric O'Brien]

I *hope* that is not the cause of the error described!

I understand that this is a volunteer effort.  And I realize that  
programs often throw arcane error codes in ambiguous situations.


But, *please* reassure me that "Error: Could not find 'autopano-sift- 
c.exe' in path..." does not ACTUALLY mean "Arguments supplied,  
, not understood.  Try using "--maxmatches %p %o %s"   !!


eo



On May 6, 2010, at 4:12 PM, Zoran Zorkic wrote:


On May 6, 8:35 pm, Didgeridoohan  wrote:

Today, I accidentally pressed "Load Defaults" in the "Control Point
Detectors" preferences.

First, Hugin was suddenly not able to find autopano-sift-c.exe. It
merely stated that:

"Error: Could not find "autopano-sift-c.exe" in path. Maybe you have
not installed it properly or given the wrong path in the settings."
At the time I was running Zoran's 5118 build for windows, but the  
same

error happens whatever version I try and no matter if I clear all
settings...


Change the arguments for APSC to:  --maxmatches %p %o %s
and you should be fine.


--
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] [OSX] Hugin 2010.1.0 svn5138 32/64-bit bundle

[Eric O'Brien]

Yes, Macintosh G4, OS X 10.5.8 ("Leopard").


I'm not a programmer either.  But I *could* see myself doggedly  
grinding through the build process like you have been doing.  *shudder*


I have also done a lot of software testing.  The final situation you  
describe ("I enabled both fixes and now it magically works") reminds  
me of situations where a work-around for a bug breaks things when the  
bug itself is finally fixed.


Here, each "fix" nominally address the issue, but in current reality  
neither "fix" ALONE is sufficient to address the issue.  Instead,  
*both* "fixes" must be present before the problem will go away.



Even if I *were* a programmer, I would not look forward to trying to  
unravel that.  It sounds real messy.


Any programmers out there care to comment?  ;)

eo

On May 4, 2010, at 12:04 AM, Harry van der Wolf wrote:


Hi,

2010/5/4 Eric O'Brien 
YES!

A window I had never seen before:  "Control Point detector  
results"  :)


Is there any easy way to describe what the problem was with that  
("finding control points" dialog hangs) ?


Thanks!

eo



First a counter question: This is on your G4 with OSX Leopard  
10.5.8? Please confirm or state otherwise.



I can describe it but that doesn't mean I understand it myself. I'm  
not a programmer.
Quite some time ago we had the same problem. The functionality for  
this external command with progress in a window is in  
"MyExternalCmdExecDialog.cpp".


Ippei Ukai created a fix for the problem in coordination with some  
wxmac aka wxwidgets developer, but it unfortunately only partially  
worked. At that time Ippei wnet on with his life and study and a  
little bit later I picked it up and I got in contact with a wxmac  
developer (the same?) responsible for the Mac side. He worked  
through a few scenarios with me. I implemented his fix and everybody  
was happy. I uncommented Ippei's fix, but left it in (fortunately as  
it turns out now).


Now you and some others are complaining ;) since a few weeks, so the  
issue was back and I had no idea why. I first upgraded to wxmac  
2.8.11 from 2.8.10 to see whether it was fixed. It wasn't, but  
another issue was fixed (or so it seems: the "bleeding" through").
Than I started switching between Ippei's fix and the Mac developer  
fix: That didn't work.

Than I enabled both fixes and now it magically works.
(I told you I didn't understand it myself).

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


--
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] [OSX] Hugin 2010.1.0 svn5138 32/64-bit bundle

[Eric O'Brien]

YES!

A window I had never seen before:  "Control Point detector results"  :)

Is there any easy way to describe what the problem was with that  
("finding control points" dialog hangs) ?


Thanks!

eo

On May 3, 2010, at 5:07 AM, Harry van der Wolf wrote:


Hi mac users,

A new 32/64-bit bundle. I might continue building these mixed 4- 
architecture builds. The only point is that they take twice as much  
time to build, both the "external" libraries/binaries as well as the  
bundle it self and that it takes twice as much space.



In this bundle:
* more fixes/enhancements by Thomas Modes and James Legg.

* Pablo's patent free panomatic still as 32bit build as the 64bit  
build segfaults.


* The "Find Control Point" dialog should no longer hang on ppc/ 
(Snow)Leopard. I don't know about Tiger as I can't test that. If it  
still hangs on Tiger I think I know what to do.


* WxMac aka WxWidgets aka WxWindows upgraded from 2.8.10 to 2.8.11.  
Until now we needed to apply a patch as <=2.8.10 "bleeded"  through.  
The CP tab images would show "through" other panes if something got  
changed. This seems to be fixed now. Please test this. It is easy to  
test: Set Hugin to any pane but the ControlPoints pane. Open the CP  
table and delete some CP's. The ControlPoint pane will show up. Now  
change to another pane again and see what happens and repeat the CP  
delete in the CP table.



As always: Information and binaries via my website
.


(The binaries themselves are served from hugin.panotools.org who  
kindly provide the disk space and bandwidth).


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


--
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] [OSX] Hugin 2010.1.0 svn5116 32/64-bit bundle

[Eric O'Brien]

Ah!

Allan and I seem to share a similar opinion/conjecture/analysis of the  
problem.


Pushing the "Cancel" button in the finding control points window  
yields an error because the control point generator has successfully  
completed *and quit*  (That is, there is no longer anything left to  
"Cancel.")


But what I'm calling the "hand off" to Hugin never happens.  For some  
reason, Hugin misses the "I'm done, here are those control points you  
asked for" event.


And bothering to go a step further than I did before, in

/var/folders/Hg/HgTVbhBpG7GpGWUU2vjMhE+++TI/-Tmp-

are files such as ap_resj0h6w4, ap_resovgvgE, ap_resR4vOEu and so  
forth that are indeed control points files.  (Thanks Allan!)  At least  
the ones for Autopano-sift-C and Panomatic.  There are also some files  
with that naming convention that are empty, but I'm guessing those are  
from patfree-panomatic (which this time around was crashing).


So!  This ought to be easy to fix!  :)  ... right?

If the problem only happens on PPC machines, I don't suppose it might  
have something to do with byte order, would it?  (He said naively.)


eo

On Apr 23, 2010, at 8:24 PM, AKS-Gmail-IMAP wrote:


Harry,

On Apr 23, 2010, at 12:24 PM, Harry van der Wolf wrote:



About 15-16 months ago we needed to create a workaround for wxmac  
on Tiger/ppc versus Leopard/ppc as leopard did not behave correctly.
For this exact same error as mentioned above the work-around was  
created (in collaboration with a dev from the wxwindows team). It  
now seems that tiger/ppc misbehaves the same, so I now applied the  
same leopard/ppc workaround also for tiger/ppc.

I have no idea whether it works or not.
For all of you on Tiger on G4/G5, please download  and see whether it works or not.


This problem has become a PPC issue regardless of having Leopard or  
Tiger. I see 2010.0.0 and 2010.1.0-svn5031 as the only versions  
running on a PPC that do not exhibit this failure to know that the  
Auto CP generators have successfully finished.


As you recall, that is basically what happens. The  completed points  
file winds up stranded in a tmp folder and the process that created  
it unloads. I would guess that the Canel button on the "finding  
control points" pane results in the "failed to kill" message because  
it is trying to kill a process that no longer exists. One can watch  
that process come and go on the Activity Monitor. Comparing the  
differences seen on the Activity Monitor between svn5031 and svn5116  
(any version), I see the "Control point detector results" pane  
appear before the generator process disappears from the Activity  
Monitor process list when running the svn5031. When running svn5116  
one sees the generator process finish in the status pane and then  
instantly disappear from the Activity Monitor list as one would  
expect knowing that completed points files are left stranded in tmp.


Allan



--
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] [OSX] Hugin 2010.1.0 svn5116 32/64-bit bundle

[Eric O'Brien]

Thanks Harry!

Although I *do* have Apple's Developer Tools installed, I am perfectly  
OK with having *you* trying to puzzle all this out.  ;)



eo

On Apr 23, 2010, at 2:36 PM, Harry van der Wolf wrote:


Hi Eric,

2010/4/23 Eric O'Brien 
A G4 Mac running Leopard (OS X 10.5.8)

For your test version, patfree panomatic crashes:

EXC_BAD_ACCESS (SIGBUS)
KERN_PROTECTION_FAILURE at 0x0024

but maybe that has to do with the separate problems we're having  
with patfree panomatic (?)  Note that this one did *not* crash using  
your 5116-p2 build.


This is my fault. I have to build the bundle twice and compile  
patfree-panomatic in between. It uses the vigra-impex framework from  
the bundle itself. It means that I first build the bundle, then I  
compile patfree-panomatic to link it against the in-bundle vigra- 
impex framework, and after patfree-panomatic has been built, I  
rebuilt the bundle without "cleaning". As the bundle hasn't changed  
it only does some minor steps including the fresh patfree-panomatic.
I forgot to recompile patfree-panomatic and to rebuild the bundle. A  
bit too hasty and therefore sloppy. Sorry.


Otherwise, no: the problem still exists for all three control point  
generators.  The finding control points window remains visible and  
cannot be closed.  Can't continue... must force quit Hugin.


Well, more challenges ahead then

 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


--
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] [OSX] Hugin 2010.1.0 svn5116 32/64-bit bundle

[Eric O'Brien]

A G4 Mac running Leopard (OS X 10.5.8)

For your test version, patfree panomatic crashes:

EXC_BAD_ACCESS (SIGBUS)
KERN_PROTECTION_FAILURE at 0x0024

but maybe that has to do with the separate problems we're having with  
patfree panomatic (?)  Note that this one did *not* crash using your  
5116-p2 build.


Otherwise, no: the problem still exists for all three control point  
generators.  The finding control points window remains visible and  
cannot be closed.  Can't continue... must force quit Hugin.


Thanks,

eo

On Apr 23, 2010, at 10:24 AM, Harry van der Wolf wrote:


Hi Eric,

2010/4/23 Eric O'Brien 

The last few lines seen in the fcp window for the run of each  
detector:


But... the fcp dialog remains displayed.  The only button is  
"Cancel."  Pressing Cancel or the close widget on the window resutls  
in the message "Hugin Error.  Failed to kill process 10638, error 3:  
no such process"


There's no way to continue with the "finding control points" dialog  
in this state.  I have to force quit Hugin.



About 15-16 months ago we needed to create a workaround for wxmac on  
Tiger/ppc versus Leopard/ppc as leopard did not behave correctly.
For this exact same error as mentioned above the work-around was  
created (in collaboration with a dev from the wxwindows team). It  
now seems that tiger/ppc misbehaves the same, so I now applied the  
same leopard/ppc workaround also for tiger/ppc.

I have no idea whether it works or not.
For all of you on Tiger on G4/G5, please download <http://hugin.panotools.org/testing/hugin/Hugin.app.zip 
> and see whether it works or not.


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


--
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] [OSX] Hugin 2010.1.0 svn5116 32/64-bit bundle

[Eric O'Brien]

Hmm.  Getting better... ;)

I'm using a G4 Mac, which seems to be significant. (?)

Hugin 5116 now launches.  Good.

But control point generation seems to fail somewhere.

I tried the following control point generators:  Panomatic, Autopano- 
Sift-C and patfree-panomatic.


None of them crashed this time.  Results in the "finding control  
points" window seems to indicate that the each completed successfully,  
but the fcp window remained up, with only a "Cancel" button available,  
which did not work.


The last few lines seen in the fcp window for the run of each detector:

Panomatic:

--- Find matches ---
i0 <> i1 : Find Matches...
i0 <> i1 : Found 136 matches.
i0 <> i1 : RANSAC Filtering...
i0 <> i1 : Removed 1 matches. 135 remaining.
i0 <> i1 : Clustering matches...
i0 <> i1 : Kept 23 matches.

--- Write output ---
Detection took 7.998 seconds.

But... the fcp dialog remains displayed.  The only button is  
"Cancel."  Pressing Cancel or the close widget on the window resutls  
in the message "Hugin Error.  Failed to kill process 10638, error 3:  
no such process"


There's no way to continue with the "finding control points" dialog in  
this state.  I have to force quit Hugin.


 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - -


 Autopano-Sift-C

 2.2 seconds to match keypoints

 Connected component check...
 Connected component identification resulted in 1 component:
 component 1: /DSCF2415.tif, /DSCF2418.tif

 Creating output file "/var/folders/Hg/HgTVbhBpG7GpGWUU2vjMhE+++TI/- 
Tmp-/ap_resj0h6w4"


 You can now load the output file into hugin.
 Notice: guessed image format and field-of-view, please check and  
adjust.


... same problem as above:  Can't close fcp window; can't continue.   
"Hugin Error.  Failed to kill process 13312, error 3: no such process"


 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - -


 patfree-panomatic

 --- Find matches ---
 i0 <> i1 : Find Matches...
 i0 <> i1 : Found 0 matches.
 i0 <> i1 : RANSAC Filtering...
 i0 <> i1 : Too few matches ... removing all of them.
 i0 <> i1 : Clustering matches...

 --- Write output ---
 Detection took 2.742 seconds.

 ... same problem as with the other two.  Can't close fcp window;  
can't continue.  "Hugin Error.  Failed to kill process 16276, error 3:  
no such process"


 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - -

The last few lines in the system.log are:

Image: /Applications/Hugin-Enfuse-Enblend-ImageFuser/hugin- 
mac-2010.1.0-svn5116-p2/Hugin.app/Contents/Resources/xrc/data/ 
transparent.png

CacheEntry: 2last access: 3 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Volumes/lambChop/2820WDravus-Pan/DSCF2415.tif
CacheEntry: 2last access: 4 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Applications/Hugin-Enfuse-Enblend-ImageFuser/hugin- 
mac-2010.1.0-svn5116-p2/Hugin.app/Contents/Resources/xrc/data/ 
transparent.png

CacheEntry: 2last access: 3 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /Volumes/lambChop/2820WDravus-Pan/DSCF2415.tif
CacheEntry: 3last access: 5 8bit: 1 16bit: 1 float: 1 mask: 1
osVersionCheck: os is 2
osVersionCheck: osVersionMajor = 16
osVersionCheck: osVersionMinor = 88
osVersionCheck: Leopard loop 1
Exited: Terminated

 - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -  
- - - - - - - - -


I have no idea how Hugin works internally, but my landing in the  
identical situation with all three detectors implies to me that it's  
more likely the problem is "in" Hugin than in the detectors.  Or in  
the interface between Hugin and the detectors.  I'm guessing that the  
detectors finish their work and (somehow) notify Hugin of the fact and  
"hand off" the generated control points. (??)


Umm... now what?

Thanks,

eo


On Apr 22, 2010, at 9:15 AM, Harry van der Wolf wrote:


Hi all,

2010/4/22 Harry van der Wolf 
Sorry all,


2010/4/22 Eric O'Brien 


But... a dylib error when I first launch:

  Library not loaded: /Users/Shared/development/hugin_related/ 
ExternalPrograms/4way-repository//lib/libiconv.2.dylib
  Referenced from: /Applications/Hugin-Enfuse-Enblend-ImageFuser/ 
hugin-mac-2010.1.0-svn5116/Hugin.app/Contents/MacOS/Hugin
  Reason: Incompatible library version: Hugin requires version 8.0.0  
or later, but libiconv.2.dylib provides version 7.0.0


The path to the not loaded library does not exist on *my* computer.





I had to make some changes and fixes along the way, but I never  
realised it could go wrong in this part.

It's now fixed. I released a patch1 build.



Now the patch 1 as such was OK. It turned out however that the 64bit  
"side" of Pablo's patent free panomatic segfaulted, which means that  
I had to revert to a 32bit patent

Re: [hugin-ptx] [OSX] Hugin 2010.1.0 svn5116 32/64-bit bundle

[Eric O'Brien]

Thank you!

You love us!!

But... a dylib error when I first launch:

  Library not loaded: /Users/Shared/development/hugin_related/ 
ExternalPrograms/4way-repository//lib/libiconv.2.dylib
  Referenced from: /Applications/Hugin-Enfuse-Enblend-ImageFuser/ 
hugin-mac-2010.1.0-svn5116/Hugin.app/Contents/MacOS/Hugin
  Reason: Incompatible library version: Hugin requires version 8.0.0  
or later, but libiconv.2.dylib provides version 7.0.0


The path to the not loaded library does not exist on *my* computer.

eo

On Apr 21, 2010, at 8:47 AM, Harry van der Wolf wrote:


Hi mac users,

Despite my remarks in previous mails I decided to build a full 4- 
architecture Universal 32/64-bit build for ppc/i386/ppc64/x86_64  
(and don't say that I don't love you).
Due to the fact that the 4 CPU-architectures are merged into one  
application, the Hugin.app is now a 188MB in size (including the  
tools). Not 200+MB as I thought before, as the Gui itself is "only"  
32bit.
Next to that a set of several versions of enfuse and enblend are  
included.
Total compressed image size 94MB, uncompressed 261MB. You get a  
whole lotta Hugin for your money.


Everything is compiled for 4 architectures except from the Gui  
itself which is 32bit and everything should run on all hardware  
platforms as of G3 and as of Tiger, apart from enblend/enfuse ((2)  
and see further).
Everything has been built up from scratch again with -O2 compilation  
optimization whereas the last 2 bundles where compiled with -O3  
optimization. These last 2 bundles caused troubles on G4/G5 Tiger  
combinations. The bundle is still compiled against jpeg-8. If that's  
the "evil doer" than it still won't function and I need to go back  
to jpeg-7 (and might be able to use -O3 after all?)


This 32bit/64bit bundle should run in 64bit mode when both your  
hardware (G5, Intel core duo or better) and your MacOSX (Leopard and  
SnowLeopard) support it. Note though that the Gui is 32bit and will  
display as such in Finder(*). The tools will run in 64bit mode.
- Nona, hugin_hdrmerge, enblend, enfuse and all other tools will run  
in 64bit when possible.
- Enfuse and enblend are OpenMP enabled (2).  Those on Tiger should  
use the Tiger build from the "enblend-enfuse-4.0/Tiger" folder in  
the dmg image.
- The optimise step (1) is part of the hugin application/gui and  
therefore a 32bit "part".
- pto_merge and pano_modify (Thomas Modes' new tools)  have been  
added as well in the Tools section (see the accompanying Readme.txt  
in the "Hugin Tools" in the dmg image)


In the "enblend-enfuse-4.0" folder in the dmg image you can find  
several standalone enfuse/enblend versions.

- Tiger -> For all of you still on Tiger, no matter the hardware.
- Leopard-SnowLeopard/32bit-Universal-openMP  -> For G3/G4 and Intel  
mono core and (early) intel duo-core with 32bit EFI.

- Leopard-SnowLeopard/64bit-Universal -> compiled without OpenMP.
- Leopard-SnowLeopard/64bit-Universal-openMP
And off course: Read the Readme.txt inside the folder.

(*): Applications in 32/64-bit build can be set to always run in  
32bit or 64bit mode from Finder (Application, right-click, Get  
info). Hugin Gui is 32bit and doesn't know/show that switch.


Note: I only did some basic testing. I didn't do speed comparisons  
either for 32bit vs. 64bit or OpenMP enabled vs. Non-OpenMP enabled  
or combinations of these. The whole exercise already took quite some  
time.
I am curious though what your test results are, so your feedback is  
most welcome.



As always: Information and binaries via my website
.


(The binaries themselves are served from hugin.panotools.org who  
kindly provide the disk space and bandwidth).


Hoi,
Harry



1: 
2: 


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


--
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] [OSX] Hugin 32bit vs. 64 bit and the way to go forward

[Eric O'Brien]

Indeed, thanks for you work on the Mac builds!

It doesn't sound like it, but is this related to the control point  
generators failing on G4 Macs?


If not... have you (or anyone?) made any progress with *that*  
problem?  I own PTGui, but there are a few things I'd like to try in  
Hugin.  But not if I have to place my control points manually!


Thanks,

eo

On Apr 17, 2010, at 2:53 AM, Harry van der Wolf wrote:


Hi mac users,

(A long mail).




--
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] Crash or other failure - control point generators

[Eric O'Brien]

On Apr 10, 2010, at 10:06 AM, Harry van der Wolf wrote:


Hi Eric,

With regard to patfree-panomatic: This one obviously crashes on G4.  
I had one report from another G4 user and I asked the community for  
more response whether it crashed for them as well. You are now the  
second user with a crash report. This confirms that it has to be  
fixed. I already checked it but haven't found it yet.


Thanks.  Do you need/want the crash report?



For the other two patented CP detectors panomatic and autopano-sift- 
C: They are not delivered with the bundle, due to the license  
restrictions on the used algorithms.
You need to download and install them. Read the readme inside the  
dmg you downloaded, or read the page on <http://panorama.dyndns.org/index.php?lang=EN&subject=Hugin&texttag=Hugin 
>. They both describe simply what to do.


I understand they need to be downloaded separately and installed.  I  
have done that.


As I described, the "finding control points" window *does* appear and  
progress information is displayed in it.  From reading the text in  
that window, it appears that both Panomatic and Autopano-SIFT-C  
complete successfully.  BUT, I'm unable to continue past that point,  
as clicking either the "Cancel" button or the close button (left hand  
dot in the window title bar) results in the message "Hugin Error -  
Failed to kill process X, error 3: no such process."


Nothing that looks "suspicious" (to me) appears in the system log.

Any ideas about how I can track down the cause of this?

Thanks,

eo



Harry


2010/4/10 Eric O'Brien 
So, I'm trying to get control points automatically generated.

I've used both the "Align..." button in the Assistant tab and the  
"Create control points" button in the Images tab, but the result is  
the same:  all three (patfree-panomatic, panomatic and Autopano-SIFT- 
C) fail.  I'm running Hugin version "Hugin 2010.1.0-vsn5102(Mac)."   
The Machine is a rather old G4 Power Macintosh, with a dual  
processor upgrade, but it's still a PPC computer.  The OS version is  
OS X 10.5.8.


Trying to start simply, I'm using 9 full-frame fisheye input  
images.  1200 x 1793 px. 16-bit TIFFs, saved in portrait  
orientation.  I used the "Mask" feature on the two nadir images.


I first try "patfree-panomatic"..

This one explicitly crashes. (I'll be happy to post or send the full  
crash report somewhere... just didn't want to fill this message with  
it.)



   Exception Type:  EXC_BAD_ACCESS (SIGBUS)
   Exception Codes: KERN_PROTECTION_FAILURE at 0x0008


After which, the "finding control points" window cannot be closed.   
[From now on I'll call this the "FCP Window"]  Pressing "Cancel"  
results in message "Hugin Error - Failed to kill process 35432,  
error 3: no such process."


Well I suppose that if a control point generator crashes, then maybe  
that process would no longer exist.  But if so, shouldn’t whatever's  
driving the FCP window be aware (or be made aware) of this fact and  
respond in a more reasonable way to the "Cancel" button?


As it is, I have to Force Quit Hugin to escape from the sitution.

(If using the Assitant tab,behind the FCP window I see another  
window named "Aliging image" - "Finding corresponding points" progress bar> "Elapsed time: 0:00:00")



Try Autopano-SIFT-C

Appears to succeed, with last few lines in "finding control points"  
window reading


   Creating output file "/var/folders/Hg/HgTVbhBpG7GpGWUU2vjMhE++ 
+TI/-Tmp-/ap_reshKdo2t"


   You can now load the output file into hugin.
   Notice: guessed image format and field-of-view, please check and  
adjust.



But the same problem occurs trying to close the "finding control  
points" window. (A different process number is reported, of course.)


By the way, why is it "guessing" the image format and FoV? The  
source files have EXIF data in them and I set a "lens" for the  
images on the Camera and Lens tab.



Try Panomatic.

Also appears to succeed (last two lines read "--- Write output  
--- ... Detection took 73.514 seconds."), but again the FCP window  
stays up and "Cancel" fails.  I must Force Quit Hugin.  No control  
points exist in the project when I re-open it.


Any ideas on what I should do next?

By the way, when this works correctly what IS supposed to happen?   
Does the FCP window just close?


Thanks,

eo



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

To unsubscribe, reply using "remove me" as the subject.

[hugin-ptx] Crash or other failure - control point generators

[Eric O'Brien]

So, I'm trying to get control points automatically generated.

I've used both the "Align..." button in the Assistant tab and the  
"Create control points" button in the Images tab, but the result is  
the same:  all three (patfree-panomatic, panomatic and Autopano-SIFT- 
C) fail.  I'm running Hugin version "Hugin 2010.1.0-vsn5102(Mac)."   
The Machine is a rather old G4 Power Macintosh, with a dual processor  
upgrade, but it's still a PPC computer.  The OS version is OS X 10.5.8.


Trying to start simply, I'm using 9 full-frame fisheye input images.   
1200 x 1793 px. 16-bit TIFFs, saved in portrait orientation.  I used  
the "Mask" feature on the two nadir images.


I first try "patfree-panomatic"..

This one explicitly crashes. (I'll be happy to post or send the full  
crash report somewhere... just didn't want to fill this message with  
it.)



Exception Type:  EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x0008


After which, the "finding control points" window cannot be closed.   
[From now on I'll call this the "FCP Window"]  Pressing "Cancel"  
results in message "Hugin Error - Failed to kill process 35432, error  
3: no such process."


Well I suppose that if a control point generator crashes, then maybe  
that process would no longer exist.  But if so, shouldn’t whatever's  
driving the FCP window be aware (or be made aware) of this fact and  
respond in a more reasonable way to the "Cancel" button?


As it is, I have to Force Quit Hugin to escape from the sitution.

(If using the Assitant tab,behind the FCP window I see another window  
named "Aliging image" - "Finding corresponding points" bar> "Elapsed time: 0:00:00")



Try Autopano-SIFT-C

Appears to succeed, with last few lines in "finding control points"  
window reading


Creating output file "/var/folders/Hg/HgTVbhBpG7GpGWUU2vjMhE++ 
+TI/-Tmp-/ap_reshKdo2t"


You can now load the output file into hugin.
Notice: guessed image format and field-of-view, please check and  
adjust.



But the same problem occurs trying to close the "finding control  
points" window. (A different process number is reported, of course.)


By the way, why is it "guessing" the image format and FoV? The source  
files have EXIF data in them and I set a "lens" for the images on the  
Camera and Lens tab.



Try Panomatic.

Also appears to succeed (last two lines read "--- Write output --- ...  
Detection took 73.514 seconds."), but again the FCP window stays up  
and "Cancel" fails.  I must Force Quit Hugin.  No control points exist  
in the project when I re-open it.


Any ideas on what I should do next?

By the way, when this works correctly what IS supposed to happen?   
Does the FCP window just close?


Thanks,

eo

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

To unsubscribe, reply using "remove me" as the subject.

Re: [hugin-ptx] Hugin crashes consistently on attempted stitching?

[Eric O'Brien]

Well, even if that's the case, *crashing* because of it is bad behavior.

Perhaps someone can add a "sanity check" to Hugin to check for this  
situation.


eo

On Apr 5, 2010, at 3:36 AM, Harry van der Wolf wrote:


Hi,

You didn't download CP detectors or select a default CP detector for  
Hugin. Please read the documentation inside the dmg or read the CP  
detector documentation on .


Hoi,
Harry

2010/4/5 johanna 
I downloaded Hugin 2010.0.0 and tried to stitch together a set of 4
jpgs.  When I hit "align" the software crashes.

I'm including the "Problem details" below -- if anyone has any idea on
how to remedy this (or where I should ask other than this mailing
list) please let me know?  Thanks.




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

To unsubscribe, reply using "remove me" as the subject.

Re: [hugin-ptx] Pano head construction and parallax elimination.

[Eric O'Brien]

If by "deep," you refer to what might be called "Landscape  
Photography," you may well be able to simply IGNORE the "no parallax  
point."  If the nearest objects are miles/kilometers (or even  
thousands of feet/hundreds of meters) away from the camera you  
probably will not be able to resolve ANY errors due to parallax no  
matter WHERE you reasonably place the pivot point.


eo

On Feb 9, 2010, at 12:44 PM, John McAllister wrote:


I most the appreciate the feedback so far.

I am planning to post the details of my pano head when design and  
construction have been completed.


I've been having some good ideas; for example controlling the  
swinging arm with a quick release mechanism and mounting a camera  
quick release plate on the swinging arm (credit to others there).


I think there is a basic set of metrics that should suit the  
majority of cases and users, that's the purpose of this query.


I think that I have been able to prepare a very useful design brief  
based on many years of experience.


It is not intended to be VR head, but to assist deep multirow panos  
at high resolution.


All input and enquiries are gratefully received, and correspondence  
is welcome via w...@w3a2z.net

I don't think this list should be overburdened, I'm a bit off subject.

My panos, of course, can be seen at http://www.panavista.eu/

John McAllister



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


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