[hugin-ptx] link images parameter with simple function

2012-05-01 Thread jean
First of all thanks a lot to everyone who answered me in my latest 
questions. However I'm here again with another :)
I just learned that i can edit .pto files and do things that the Hugin GUI 
itself doesn't allow, like link arbitrary parameters of images (e.g. yaw of 
image #10 has to be equal to that of image #0)
Now i would like to express that in a more flexible form, like 

yaw of image #1 has to be equal to that of image #0 plus 36°

something like 

y=0+36

This way i could - for instance - optimize relative positions of three rows 
in a situation where all images align perfectly with those of their own 
row, but not with rest of image. 
Provided i already tried the aforementioned notation 'y=0+36' and that it 
unsurprisingly doesn't work, is there a way to do what i want?

On a slightly related note, although still nice to have, this would not be 
needed if there was a way to specify a coarse expected position, as i 
already pointed out: i guess the optimizer works by minimizing some sort of 
error function, and should be trivial to add [distance from image being 
optimized to the originally setted expected coarse position] to the error 
function to minimize; is such a feature present or planned? I couldn't 
figure exactly when i first asked for it. 
In case of two negative answers: would it be difficult to add for a 
professional developer, given proper advice?

-- 
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] Re: multiblend 0.3beta - now with pseudowrapping for 360 degree panoramas

2012-05-01 Thread Bart van Andel
Hi David,

I think I may have seen it, and meant to reply one day, but then I forgot...


No problem :)
 


 Anyway, I will look into adding your MCE support for the next version - 
 thanks for those.


Since the project has been renamed to MXE instead of MCE we'd probably 
better call it by its proper name MXE from now on.

 

 Just curious, why is -lz necessary in the build script?


Both libjpeg and libtiff make use of zlib functions. Normally you'd expect 
the compiler to add this -lz automatically when the build system was 
properly configured and you include -ljpeg of -ltiff. Unfortunately at 
least on my system this seems not to be the case, resulting in lots of 
errors like undefined reference to _inflate. Adding -lz manually resolves 
this (and adding it twice won't hurt the compiler). This may have to do 
with an incomplete pkg-config file in libtiff or libjpeg which may or may 
not have been fixed (note that my MXE system isn't entirely up-to-date, 
I'll check this later).
 

I will add seam saving/loading soon as well, but I will use TGA as it is 
 easily compressed (although PNG may be even better).


TGA may be nice compression wise, but I don't think this format is as 
widely known as TIFF or PNG, so I'd opt for using the latter. Note that 
this is pretty straightforward when using (for example) the freeimage 
library (as opposed to using functions from libtiff or libjpeg directly).


Cheers,
Bart

 


 There may also be some disk caching features added, although the biggest 
 problem at the moment is heap fragmentation (and this may actually be the 
 cause of Evgeny's problems, rather than running out of memory).

 David

 On Thursday, April 19, 2012 9:26:08 AM UTC+1, Bart van Andel wrote:

 Hi David,

 Have you missed the contributions I posted earlier [0] (probably) or are 
 you just ignoring it (unlikely)?

 [0] https://groups.google.com/d/msg/hugin-ptx/JPiViZQ-Ycw/4ygfvPVq4hgJ

 --
 Bart




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


Re: [hugin-ptx] merge enblend and multiblend code?

2012-05-01 Thread Bart van Andel


On Monday, April 30, 2012 9:13:42 AM UTC+2, Monkey wrote:

 I did try multi-threading it in a couple of places, but maybe it was doing 
 it wrong because it didn't make it any quicker. That was with native 
 Windows multithreading - unfortunately Microsoft don't want you to use 
 OpenMP with Visual C++ Express, which is the only option now multiblend is 
 multi-platform. 


Fortunately, cross-compiling using MXE is pretty easy as I've shown in 
another thread [0, 1]. I haven't actually tried compiling anything with 
OpenMP enabled using this approach, but I don't think it should be too much 
of a hassle. And there's a great support community there so if I need help 
all I need to do is ask.

[0] https://groups.google.com/forum/?fromgroups#!topic/hugin-ptx/-3-i9ynuCig
[1] https://groups.google.com/d/msg/hugin-ptx/JPiViZQ-Ycw/4ygfvPVq4hgJ

 

 Besides which, the seaming algorithm can't be multithreaded (at least not 
 easily), and that and image loading are usually the two slowest parts.

 David

 On Monday, April 30, 2012 7:24:32 AM UTC+1, GnomeNomad wrote:

 Thanks, I thought it was multi-threaded. 

 On 04/28/2012 11:41 PM, Monkey wrote: 
  The same benefit it has on any system - it's quicker (but not better) 
  than Enblend :). The multi in multiblend doesn't have anything to do 
  with multicore processing - it's (currently) single-threaded. 
  
  On Sunday, April 29, 2012 1:26:16 AM UTC+1, GnomeNomad wrote: 
  
  What benefit does multiblend have on uniprocessor systems? 

 -- 
 Gnome Nomad 
 gnomeno...@gmail.com 
 wandering the landscape of god 
 http://www.clanjones.org/david/ 
 http://dancing-treefrog.deviantart.com/ 
 http://www.cafepress.com/otherend/ 



-- 
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] merge enblend and multiblend code?

2012-05-01 Thread Gnome Nomad
Yah, probably would be, especially for complex image sets. Maybe could 
make it a manual option user could specify on starting a stitch; maybe 
even select which image to start with for each thread. Then if it blows 
up, user can try it again without it. But, yah, be just faster to run 
seaming in a single thread!


On 04/30/2012 02:54 AM, Monkey wrote:

I suspect that any code required to work out if and how a particular
image layout could be broken down into parallelisable chunks would be
far more complicated and far slower than seaming itself!

David

On Monday, April 30, 2012 10:09:17 AM UTC+1, GnomeNomad wrote:

Could you multi-thread seaming by working from opposite sides of the
panorama simultaneously? For example, a strip panorama - do the seaming
for the first 2 images while also doing the seaming for the last 2
images (assuming there's enough images in the pano for that to work).
Maybe use opposite corners for multi-row/multi-column panos.

On 04/29/2012 09:13 PM, Monkey wrote:
  I did try multi-threading it in a couple of places, but maybe it was
  doing it wrong because it didn't make it any quicker. That was with
  native Windows multithreading - unfortunately Microsoft don't
want you
  to use OpenMP with Visual C++ Express, which is the only option now
  multiblend is multi-platform. Besides which, the seaming
algorithm can't
  be multithreaded (at least not easily), and that and image
loading are
  usually the two slowest parts.
 
  David
 
  On Monday, April 30, 2012 7:24:32 AM UTC+1, GnomeNomad wrote:
 
  Thanks, I thought it was multi-threaded.
 
  On 04/28/2012 11:41 PM, Monkey wrote:
   The same benefit it has on any system - it's quicker (but not
  better)
   than Enblend :). The multi in multiblend doesn't have anything
  to do
   with multicore processing - it's (currently) single-threaded.
  
   On Sunday, April 29, 2012 1:26:16 AM UTC+1, GnomeNomad wrote:
  
   What benefit does multiblend have on uniprocessor systems?


--
Gnome Nomad
gnomeno...@gmail.com mailto:gnomeno...@gmail.com
wandering the landscape of god
http://www.clanjones.org/david/ http://www.clanjones.org/david/
http://dancing-treefrog.deviantart.com/
http://dancing-treefrog.deviantart.com/
http://www.cafepress.com/otherend/ http://www.cafepress.com/otherend/



--
Gnome Nomad
gnomeno...@gmail.com
wandering the landscape of god
http://www.clanjones.org/david/
http://dancing-treefrog.deviantart.com/
http://www.cafepress.com/otherend/

--
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] Re: multiblend 0.3beta - now with pseudowrapping for 360 degree panoramas

2012-05-01 Thread Monkey


 TGA may be nice compression wise, but I don't think this format is as 
 widely known as TIFF or PNG, so I'd opt for using the latter. Note that 
 this is pretty straightforward when using (for example) the freeimage 
 library (as opposed to using functions from libtiff or libjpeg directly).


It's all coded up now - I've gone for PNG as TGA can only give you up to 
1/256 compression, and as you say it is more widely known. -lpng will be a 
requirement for the next version (just waiting on some test files for a 
TIFF variant).

David

-- 
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] Re: What's wrong Hugin tiff implementation?

2012-05-01 Thread AlekseyM
What library Hugin uses to create tiff files? Maybe it is possible to
add some options to specify different tiff format?

-- 
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: multiblend 0.3beta - now with pseudowrapping for 360 degree panoramas

2012-05-01 Thread Carlos Eduardo G. Carvalho (Cartola)
Hi David,

I have finally tested the 0.31beta on FreeBSD and it looks pretty ok. Maybe
it could be good to add a note on the build.txt file to also use the
options -I/usr/local/include -L/usr/local/lib to compile it on FreeBSD.

Thanks!

Carlos E G Carvalho (Cartola)
http://cartola.org/360



2012/3/27 Monkey davidhorma...@gmail.com

 Some pseudowrapping bugs cleared up (including one that *created* a seam
 in the middle - oops!) - now at version 0.31beta.

 Windows binaries: http://horman.net/multiblend/multiblend0.31beta.zip
 Source for Linux/Mac/FreeBSD etc:
 http://horman.net/multiblend/multiblend0.31beta.tar.gz

 David



 On Tuesday, March 27, 2012 12:01:56 AM UTC+1, Monkey wrote:

 Hi all,

 Previous discussion: http://groups.google.com/**
 group/hugin-ptx/browse_thread/**thread/b08211b2659a7eabhttp://groups.google.com/group/hugin-ptx/browse_thread/thread/b08211b2659a7eab

 I've implemented a feature I'm calling pseudowrapping to blend
 around the left/right borders for 360 degree panoramas, a much-
 requested feature.

 There are no command-line switches to access this; pseudowrapping is
 enabled any time multiblend is run with only a single uncropped TIFF
 (such as that already created by a normal multiblend run) as its
 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


-- 
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] Re: link images parameter with simple function

2012-05-01 Thread kfj


On 1 Mai, 10:28, jean giancarlo.tod...@gmail.com wrote:

 Now i would like to express that in a more flexible form, like

 yaw of image #1 has to be equal to that of image #0 plus 36°

 something like

 y=0+36
 ...

panotools scripting, again, is the answer. And if you're python-
literate, you may also want to have a look at

http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/README.parse_pto
http://bazaar.launchpad.net/~kfj/+junk/script/view/head:/main/parse_pto.py

This is pure python and will run on any system with python 2.6 or 2.7
and may run on 3.X.

and if you're on a linux system, you may be able to use hsi/hpi as
well from python (it might be part of your package already), which is
a swig module for most of hugin's backend functionality. It's complex
but fast and largely undocumented, for your purpose it's probably
overkill.

What the optimizer minimizes is the distance of the 'legs' of the
control points, when projected to the output projection. This sounds
confusing, but you have to keep in mind that each control point refers
to two coordinate pairs: one x/y pair in each image. Hugin has a
notion of where these two points would turn up on the output under the
current transformation, and since the match is never perfect, the
projected positions of the two 'legs' aren't in precisely the same
spot - hence they are in a certain distance from each other. The
optimizer tries to modify the projection so that the distance between
the projected legs is minimized. It doesn't look at the image content
at all, it only works on the control point coordinates and their
projected positions.

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: What's wrong Hugin tiff implementation?

2012-05-01 Thread Bruno Postle

On Tue 01-May-2012 at 03:35 -0700, AlekseyM wrote:

What library Hugin uses to create tiff files? Maybe it is possible to
add some options to specify different tiff format?


It would be possible, but the alpha channel in the enblend TIFF 
output is useful since a lot of panoramas have transparent areas.


--
Bruno

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


[hugin-ptx] viewer that uses image pyramid

2012-05-01 Thread Evgeny Toropov
I'm not sure if this is a right place to ask, but does anyone know an
open-source panorama tool/viewer that constructs an image pyramid and
uses it to display a panorama (that is, doesn't load the whole image at
once, but rather loads separate tiles when necessary as google maps does)?

A proprietary alternative I know is Panorama Studio

Thank you!

-- 
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] Re: viewer that uses image pyramid

2012-05-01 Thread Erik Krause

Am 01.05.2012 22:12, schrieb Evgeny Toropov:

I'm not sure if this is a right place to ask, but does anyone know an
open-source panorama tool/viewer that constructs an image pyramid and
uses it to display a panorama (that is, doesn't load the whole image at
once, but rather loads separate tiles when necessary as google maps does)?


PanoSalado2 should do this: http://wiki.panotools.org/PanoSalado

--
Erik Krause
http://www.erik-krause.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] Re: viewer that uses image pyramid

2012-05-01 Thread Carlos Eduardo G. Carvalho (Cartola)
I have used Salado Player and Converter a lot:

http://panozona.com/wiki/SaladoPlayer:Quick_start

Carlos E G Carvalho (Cartola)
http://cartola.org/360



2012/5/1 Erik Krause erik.kra...@gmx.de

 Am 01.05.2012 22:12, schrieb Evgeny Toropov:

  I'm not sure if this is a right place to ask, but does anyone know an
 open-source panorama tool/viewer that constructs an image pyramid and
 uses it to display a panorama (that is, doesn't load the whole image at
 once, but rather loads separate tiles when necessary as google maps does)?


 PanoSalado2 should do this: 
 http://wiki.panotools.org/**PanoSaladohttp://wiki.panotools.org/PanoSalado

 --
 Erik Krause
 http://www.erik-krause.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_FAQhttp://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+unsubscribe@**
 googlegroups.com hugin-ptx%2bunsubscr...@googlegroups.com
 For more options, visit this group at http://groups.google.com/**
 group/hugin-ptx 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