headers
karpi | 1 Feb 2006 18:13
Picon

Re: PTstereo - still kinda no support?

27/01/06 05:39, ed <at> halley.cc napsal(a):
> 
> I've gotten into 3D modeling lately, and thought that the features of 
> the PTstereo solver would be useful for taking two reference photos and 
> building up the key vertices for my model.  But I recall from years past 
> that none of the GUIs had any real support for generating control points 
> for the 3D solver?  Is that still the case?
> 
> -- 
> [ e d  <at>  h a l l e y . c c ]

unfortunatelly not gui lacks only, PTstereo binaries not working on
linux, and on wins give some results only sometimes :(
Permalink | Reply | 0 comments |
headers
manouchk | 2 Feb 2006 17:28
Picon

Re: bug (?) in viewer when FOV is small

Le Jeudi 26 Janvier 2006 11:21, manouchk a écrit :

I've put a very simple example that crash :
get files 02.jpg 03.jpg proj.pto from
http://emmanuelfavrenicolin.free.fr/Public/Divers/Test/1/

optimize opsitions and then run preview and click on button "center" (centrer 
in French which is the first button on the left of previewer window) 

> Hi,
>
> I have a crash when doing centering in previewer when FOV is small about 1°
> (microscope shots)
>
> in the terminal where hugin where started, it gives the following message :
>
> terminate called after throwing an instance of
> 'vigra::PreconditionViolation' what():
> Precondition violation!
> basicImage::upperLeft(): image must have non-zero size.
> (../../src/foreign/vigra/basicimage.hxx:611)
>
> when increasing FOV (decreasing focal length the crash desappear but
> stitching is worst). As centering is not possible, stitiching is difficult
> too because the pictures are very far from the center. A workaround would
> be to have the possibility to click the center to get the pano centered
> that could/may replace the center button?
>
> pto files starts like that :
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
manouchk | 2 Feb 2006 19:02
Picon

Re: dirty lens and autopano-sift?

Le Lundi 30 Janvier 2006 11:12, Sebastian Nowozin a écrit :

Hy, thank you for considering my mail! (I've such a low rate of respost in 
most mailing-list I participate)

> Hi Bruno,
>
> nice idea to use only the HS and drop the rest.

I tried the Bruno's methods and the results is that autopano-sift does not 
find any control point!

May be there is a need to tweek autopano-sift parameters ?

Sebastian your code modification is somehow the same thing as Bruno or not?

> On Mon, Jan 30, 2006 at 12:19:52PM +0000, Bruno Postle wrote:
> > Unfortunately autopano-sift depends on the brightness intensity to
> > locate features, so you need to flatten the image and discard two of
> > the colour channels to get something with usable features.
>
> Alternatively, if you are a little familar with programming, you can
> try modifying the file "src/util/BasicImagingInterface.cs", which has a
> method.
>
> public double Convert (byte r, byte g, byte b) {
> 	return ((r + g + b) / (255.0 * 3.0));
> }
>
> There the intensity value is calculated, here by just taking the mean
(Continue reading)

Permalink | Reply | 1 comment |
headers
Craig Andrews | 4 Feb 2006 14:20

Strange optimiser problems

Hi,

I have just finished building Hugin 0.5, and I have installed the
Slackware packages I have made onto my desktop and laptop machines.
However, there appears to be a problem with my desktop machine.

Compare the preview screenshot for the laptop:

http://simplyspiffing.com/images/laptop_screenshot.gif

with a preview screenshot from the desktop:

http://simplyspiffing.com/images/desktop_screenshot.gif

I have used exactly the same images and pto file for each, and the only
difference appears to be the way the optimiser works. The machines are
both using:

Slackware 10.2
linux 2.6.15
wxWidgets GTK 2.6.2
hugin 0.5
libpano12 2.7.0.15
boost 1.33.1
gtk+2-2.8.9
gcc-3.4.5

The laptop is a PIII 800MHz IBM Thinkpad with 256MB RAM, and the desktop is a 1.8GHz
Athlon XP with 1GB RAM.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Pablo d'Angelo | 4 Feb 2006 18:39
Picon

Re: Strange optimiser problems

Craig Andrews schrieb:
> Hi,
> 
> I have just finished building Hugin 0.5, and I have installed the
> Slackware packages I have made onto my desktop and laptop machines.
> However, there appears to be a problem with my desktop machine.

Can you post the .pto file.
Then load this file with both machines, and optimize (using the same
parameter). Then immidiately save the projects and at post them.

> libpano12 2.7.0.15

libpano12 2.7.10 and .11 (iirc) had some problems with optimisations. are
you sure that both machines used the same lib (no leftover from former
installs).

> I have tried building each library (including wxGTK) natively on each
> machine, and it just doesn't seem to work properly on the Athlon
> machine. I'm really stuck for ideas now :-(

Strange, works for me out of the box, both wxGTK 2.6 and hugin.. (on ubuntu
breezy).

ciao
  Pablo
Permalink | Reply | 1 comment |
headers
Craig Andrews | 4 Feb 2006 18:42

Re: Strange optimiser problems

On Sat, Feb 04, 2006 at 06:39:56PM +0100, Pablo d'Angelo wrote:
> Can you post the .pto file.
> Then load this file with both machines, and optimize (using the same
> parameter). Then immidiately save the projects and at post them.

OK, will do. I'll post them later when I get back to my desk.

> libpano12 2.7.10 and .11 (iirc) had some problems with optimisations. are
> you sure that both machines used the same lib (no leftover from former
> installs).

There are no former installs - both machines are fresh installations.
They are using exactly the same binary package, so there are no compile
time differences at all.

> Strange, works for me out of the box, both wxGTK 2.6 and hugin.. (on ubuntu
> breezy).

It worked first time on the laptop for me, too. It's just the desktop
issue.

Thanks,

--

-- 
Craig Andrews <craig <at> simplyspiffing.com>
Permalink | Reply | 0 comments |
headers
Piotr Popik | 5 Feb 2006 22:23
Picon

hugin - optimization

I think, I am doing something wrong with optimization... First, I run
autopano by
autopano-complete.sh -o autopano-v1.pto -s 2400 -p 25 *.tif

Next, I open hugin and open 'autopano-v1.pto'. Hugin asks for the focal
length of the lens and crop factor -- OK.

Now, when I optimize, it says something like:
Strategy 2, iteration 42, average distanca 7.29
Results:
average control point distnce: 0.0000, standard deviation: 0.0000, maximum
0.000

I think, the average control point distance should be higher than 0,
right? But why this is not passed to hugin file?

Do I need to set the crop?
Do I have to check/uncheck the 'Inherit' buttons if the images were taken
by the same lens?

Question 2: the Correction-Photometric -- this is something new... Can one
point me to a tutorial of how to use it?

Thanks | Piotr
Permalink | Reply | 0 comments |
headers
Pablo d'Angelo | 5 Feb 2006 23:32
Picon

vignetting function estimation

Hi all,

I have uploaded some code to the CVS recently:

1. OSX changes:
     Enabled PTStitcher choice in OSX port -> it should be possible to use
     PTmender with hugin.
     Additinally, the progress window for PTOptimizer has been disabled. I
     hope this fixes the crashes some people have experienced under OSX.

     PTStitcher progress reporting uses similar code, so it might be
     exibit the same behaviour as well. :(

2. Graphical display of vignetting correction polynomial.
3. Feature to optimize this polynomial based on the overlapping images.
    This function can only estimate the polynomial for the quotient approach
    right now.

    I will post a tutorial on this later (in a week or two).

    Basic usage:
      1. assemble panorama, optimize positions until they fit very well.
      2. open vignetting correction dialog, select "correction by division"
         and polynomial
      3. use the "estimate" button on the vignetting correction dialog. The
         default parameters should be fine for the first try.
      4. click apply and switch to preview window. Update preview and check
         if the vignetting has been corrected.

      Notes: its probably a good idea to try this on a static pano without
(Continue reading)

Permalink | Reply | 3 comments |
headers
JD Smith | 6 Feb 2006 07:13
Picon

Re: vignetting function estimation


On Feb 5, 2006, at 3:32 PM, Pablo d'Angelo wrote:
>
> 2. Graphical display of vignetting correction polynomial.
> 3. Feature to optimize this polynomial based on the overlapping  
> images.
>    This function can only estimate the polynomial for the quotient  
> approach
>    right now.
>
>    I will post a tutorial on this later (in a week or two).

Very cool.  I look forward to trying it out.  One possibility for  
corrections which should be stable, especially these vignetting  
correction features, is to average many many results from different  
panos.  A possible means of doing this is to read/write a small file  
which just lists the parameters along with how many different values  
were averaged to arrive at them, and then allow users to "read and  
average" with the current fit.  Eventually the values averaged in  
this way should stabilize (assuming you don't mix focal length etc.).  
The user can obviously do this herself by hand as well, assuming the  
parameters are visible/available.

JD
Permalink | Reply | 1 comment |
headers
JD Smith | 6 Feb 2006 07:47
Picon

HDR workflow


Does Hugin support the float or logluv encoded TIFF HDR files output  
by Greg Ward's Photosphere?  A reasonable HDR panorama workflow might  
then be:

1. Capture 3 photos at -2EV,0EV,2EV in Raw.
2. Follow the suggestions at http://www.panotools.info/mediawiki/ 
index.php?title=HDR_workflow_with_hugin to convert RAW files into  
16bit TIFFs.
3. Read the 16bit TIFFs into Photosphere (I'm actually not sure if  
Photosphere can read 16bit TIFFs: Greg's example mentions doing this  
with JPEG camera output).
4. Align and build HDR images for each position in the pano,  
outputting to LOGLUV or FLOATING TIFF HDR images.
5. Load these HDR images into HUGIN and stitch.
6. Enblend the results.
7. Bring the result back into Photosphere (or where ever) to tonemap.

Where are the holes in this workflow?  I presume there is not a  
convenient way to find control points on the HDR images.  Can Hugin  
output in the input image type, i.e. and HDR TIFF format?  What else  
am I missing?

JD
Permalink | Reply | 2 comments |

Gmane