[hugin-ptx] Re: Region of Interest (ROI) for Control Point Finding/Image Alignment?

[Pablo d'Angelo]

Am 13.02.2011 16:25, schrieb kfj:



On 13 Feb., 11:13, Jeffrey Martin<360cit...@gmail.com>  wrote:

I was thinking also...

for panos, the centers of images usually do not overlap.
isn't searching the WHOLE of images a big waste?


There is another aspect which becomes more important with fisheyes and
stereographic images: if you feed the CPG with a partial image, it
can't decipher the warp to adapt it's feature point detector: the
image geometry is quite different from center to margin. So you can't
just use partial images, but you have to use the whole images and mask
them appropriately. Masking means introduction of additional data into
the process, either in the shape of a separate mask or as an alpha
channel. Using an alpha channel might be a reasonalbly inexpensive and
transparent (hah) way of doing the needful, but I'm not sure if the
current CPGs honour alpha channels - I rather doubt it.


cpfind does honor alpha channels and masks defined in the pto file.

It removes any matches found in the alpha channels (this is needed for 
remapped images, otherwise one could get "false" matches at the 
corners/edges of a remapped image.)


It will still analyse all parts of the image, though, so there is not 
much computational benefit. I think the typical savings are not really 
worth the coding effort.



I am currently toying with this mechanism for use in another demo
plugin, but I want to throw in rewarping of the parts of the images
that correspond to the ROIs to a common projection to make them
geometrically as similar as possible, thus improving CPG performance
especially with fisheye images and avoiding warp-related CPG problems
- some sort of high-end matching which would produce very good
quality, well-distributed CPs, particularly for applications like lens
calibration.


Yes, something like that would be very nice. Or one could try Least 
squares matching. (estimates local affine transformation as part of the 
matching process, is typically accurate to ~ 0.1 pixel). However, it 
needs good initialisations (1-2 pixels error, good estimate for the 
initial affine transform).


ciao
 Pablo

--
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] Exposure correction in Hugin 2009.4.0 vs 2010.4.0

[Bruno Postle]

On Mon 14-Feb-2011 at 15:11 -0800, Paperaussie wrote:

I noticed that Exposure Correction does a better job in the preview
window in version 2009.4.0 than in 2010.4.0.

2010.4.0 applies correction but there are still obvious steps at the
corners of images which I do not experience in 2009.4.0. I use the
same parameters in both versions but the outcome in the Preview window
look notably different. The final output is okay though.

Any ideas why 2010.4.0 results are not as smooth?


Newer Hugin has an OpenGL accelerated 'Fast Peview window'.  By 
default most of the photometric adjustments, except for a simple 
exposure adjustment, are now disabled to speed things up.  Does it 
look better if you select the 'Photometrics' checkbox in the 
preview?


Perhaps we should enable this by default, since we now have 
incremental display of photos and the slowdown isn't so problematic.


--
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] Exposure correction in Hugin 2009.4.0 vs 2010.4.0

[Paperaussie]

I noticed that Exposure Correction does a better job in the preview
window in version 2009.4.0 than in 2010.4.0.

2010.4.0 applies correction but there are still obvious steps at the
corners of images which I do not experience in 2009.4.0. I use the
same parameters in both versions but the outcome in the Preview window
look notably different. The final output is okay though.

Any ideas why 2010.4.0 results are not as smooth?

-- 
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-2010.4.0 - cpfind problems & feedback

[Bruno Postle]

On Mon 14-Feb-2011 at 14:54 -0800, Paperaussie wrote:

Cpfind is fast but I experience some problems with cpfind in
Hugin-2010.4.0 on a 64bit Win7 notebook.

1) Cpfind appears to ignore the maximum control points per overlap
setting. I usually set this to 7 but cpfind continues to set up to 20.

2) Cpfind does not find any control points in many neighbouring images
in the second row of 2-row panos whereas autopano finds plenty for
every pair.

3) Cpfind does not find any control points for zenith or nadir when
autopano finds plenty.


There have been a lot of recent changes in cpfind to fix these 
issues, you need a snapshot from about the 23rd January or later.


--
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] Hugin-2010.4.0 - Preview Num. Transf. Apply Button not working

[Paperaussie]

The 2 buttons on the Numerical Transform dialogue of the Preview have
changed from OK/Cancel to Apply/Close. The Apply button does not seem
to do anything and the preview only updates after closing the
dialogue.

Hugin-2010.4.0 on Win7 64bit

-- 
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 Coding Style Guide

[Yuval Levy]

Hi Thomas,

On February 14, 2011 11:37:03 am T. Modes wrote:
> Why did you not extended the existing version?

Short answer: because Doxygen is the wrong place for this kind of document.

I know of very few projects that keep this kind of document in doxygen.


> There should only be one version.

Agree.  And I vote for the one on the website.


> I vote for the version inside hugins doc instead an external version.

The website is as internal to the project as anything else.

I vote for doxygen, its ugly markup and poorly organized output to be used for 
source code comments reference only.

For every other piece of documentation, including policy documents like this 
one, there is a wiki; and there is a website.  Both more reader-friendly, 
writer-friendly, search-engine-friendly.


> PS: Here the link to the existing version:
> http://hugin.sourceforge.net/docs/html/#code

and here is the ugly markup from which it is generated
http://hugin.hg.sourceforge.net/hgweb/hugin/hugin/file/659715c139bb/src/dox/mainpage.dox

with the page stating itself that is "completely out of date".

I very much prefer http://hugin.sourceforge.net/community/coding_style/
(note that it is on the same internal website).

And the other sections in that doxygen formatted document are better placed in 
the Wiki, where they have a higher chance to get updated, e.g. the build 
instructions at http://wiki.panotools.org/Hugin_Compiling_Ubuntu

Yuv


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

[hugin-ptx] Hugin-2010.4.0 - cpfind problems & feedback

[Paperaussie]

Cpfind is fast but I experience some problems with cpfind in
Hugin-2010.4.0 on a 64bit Win7 notebook.

1) Cpfind appears to ignore the maximum control points per overlap
setting. I usually set this to 7 but cpfind continues to set up to 20.

2) Cpfind does not find any control points in many neighbouring images
in the second row of 2-row panos whereas autopano finds plenty for
every pair.

3) Cpfind does not find any control points for zenith or nadir when
autopano finds plenty.

4) On 1 occasion cpfind could not find any control points when running
it first. When running it again without making any changes it found
over 200.

It will be good to have a build-in CP finder and I am looking forward
to future releases.

Please let me know if more infos are required.

-- 
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] exposure getting changed in preview window

[Stefan Peter]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Jeffrey

This [0] is the preview I get from a new project using hugin
2010.5.0.ad4e44f10418 and your pictures,

The final image looks like  [1]. You can find the project file at [2].
- From my point of view, there is nothing wrong with the stitching of
these images done by hugin. Or did I miss something?

Of course, I used the photometric optimization from the Exposure tab,
but that is what it is for, isn't it? And WB is something that should be
handled by your raw converter (or in-camera if you shoot jpgs). You can
not really expect that hugin will handle that.

BTW, where did you get that dog from? I somehow never managed to get
such a perfect fitting extra in any of my images;)


With kind regards

Stefan Peter

[0] http://www.stepet.ch/docgraves/docgravesPreview.png
[1] http://www.stepet.ch/docgraves/P197-P1000112.tif
[2] http://www.stepet.ch/docgraves/P197-P1000112.pto

Am 14.02.2011 17:37, schrieb Jeffrey Martin:
> here are some of the images:
> 
> www.vrlog.net/temp/dog-grave-1row.zip (69MB)
> 
> if you put them in Hugin, and generate control points, and then
> optimize, you should see that the exposure was also changed on all the
> images.
> 

- -- 
In theory there is no difference between theory and practice. In
practice there is.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNWalHAAoJEBgqi52L7+L/GHIIAIlhwmZWpBGhGydH+2LYMM/B
X2O+gRgMQZWlYfCtUACwKG4V1RuYvXoRTwHFBUyQwOlULGg8GGL/+lB5YFJuUuJA
aD15NUPLP6mMMTFXj/85zHY2b8h3sTqVRGVQPdV/asJq+86i8ZvoVshXPNIYN3EA
//sieMfakMZFvnv5xEUtAtwnoz+eDxygPZ6yXRtL1OCy3u0aXeVd17QvxYx9tJHl
fFqJ89pGCFB1xqqKF7xf6FLGLN0fEquYz4yKBTlVKkKNSHPK94c0QxyFpGWBXmIM
ujo2wevzn1L3gbQAvIaE/jXvL/BJd91yr4oMCnM2WvGFBAvQi4jy5MgS2FkqLDs=
=XazG
-END PGP SIGNATURE-



smime.p7s
Description: S/MIME Cryptographic Signature

Re: [hugin-ptx] exposure getting changed in preview window

[Bruno Postle]

On Mon 14-Feb-2011 at 08:37 -0800, Jeffrey Martin wrote:

here are some of the images:

www.vrlog.net/temp/dog-grave-1row.zip (69MB)

if you put them in Hugin, and generate control points, and then optimize,
you should see that the exposure was also changed on all the images.


It looks fine to me using just the three steps on the Assistant tab, 
did you try stitching?


Preview after 'Align': 
http://www.flickr.com/photos/36383814@N00/5446434550/


Preview with 'Photometrics' enabled: 
http://www.flickr.com/photos/36383814@N00/5446435194/


Preview after setting red/blue to 0.54/1.62: 
http://www.flickr.com/photos/36383814@N00/5445835355/


Final stitched output: 
http://www.flickr.com/photos/36383814@N00/5446447682/



additionally you'll notice the WB for these images is wrong - I know that it
is possible to make it look correct using Hugin, but I can't for the life of
me find the right numbers for red/blue weight to make that work. there must
be a better way, right? :-)


We need buttons for adjusting global white balance, maybe a colour 
picker, and support for displaying photos in the preview using icc 
profiles. http://wiki.panotools.org/SoC_2010_ideas#Colour


--
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] Photoshop PSB file format in libpano

[Bruno Postle]

On Sun 13-Feb-2011 at 17:51 -0400, Jim Watters wrote:


I uploaded to SourceForge into an experimental folder a windows build 
32&64bit of the PTtiff2psd tool for testing.  Use this tool to 
combine many tiff files into a single multilayer PSD or PSB file.

https://sourceforge.net/projects/panotools/files/experimental/
http://wiki.panotools.org/PTtiff2psd


Note that the Hugin .pto.mk files have a rule for assembling 
multilayer PSD files using PTtiff2psd, so if you have this in your 
PATH you should be able to create a multilayer PSB like this:


  make -f project.pto PREFIX_multilayer.psd

..or for stacked projects:

  make -f project.pto PREFIX_fused_multilayer.psd

(where PREFIX is the prefix you picked in Hugin)

--
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: Mac OS and hugin scriping/plugin interface: help needed

[Harry van der Wolf]

Hi

2011/2/14 kfj <_...@yahoo.com>

>
> - Open a shell prompt
> - set your PYTHONPATH environment variable to the target directory
> where cmake has placed hsi.py and _hsi.so
>  (like, type export PYTHONPATH=)
> - start a python interpreter session by typing 'python'
> - at the python prompt, type 'import hsi'
>
>
cmake hadn't installed it. So I had to set the python path to the cmake
build folder.

I got the following error upon importing:
$ python
Python 2.6.6 (r266:84292, Dec 27 2010, 17:46:10)
[GCC 4.2.1 (Apple Inc. build 5664)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import hsi
Traceback (most recent call last):
  File "", line 1, in 
  File "hsi.py", line 25, in 
_hsi = swig_import_helper()
  File "hsi.py", line 21, in swig_import_helper
_mod = imp.load_module('_hsi', fp, pathname, description)
ImportError: dlopen(./_hsi.so, 2): no suitable image found.  Did find:
./_hsi.so: mach-o, but wrong architecture
>>>


The "./_hsi.so: mach-o, but wrong architecture" is is a weird error. The
_hsi.so is an i386 library like all the rest.

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] exposure getting changed in preview window

[Jeffrey Martin]

here are some of the images:

www.vrlog.net/temp/dog-grave-1row.zip (69MB)

if you put them in Hugin, and generate control points, and then optimize, 
you should see that the exposure was also changed on all the images.

additionally you'll notice the WB for these images is wrong - I know that it 
is possible to make it look correct using Hugin, but I can't for the life of 
me find the right numbers for red/blue weight to make that work. there must 
be a better way, right? :-)

Jeffrey

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

[hugin-ptx] Re: Hugin Coding Style Guide

[T. Modes]

Hi Yuv,

On 14 Feb., 06:23, Yuval Levy  wrote:
> Hi Hugin developers,
>
> back in August 2009 we had a discussion about coding style consistency.  The
> result of that discussion have been a needle in a haystack on my hard disk.
>
> today I found it, polished it, and published it on the Hugin website at [0].
>

> [0]http://hugin.sf.net/community/coding_style/
>

Why do we need 2 different version of the document on 2 different
places? There is a document in the hugin doc [0] which you used as
base of your extended version. Why did you not extended the existing
version? There should only be one version. I vote for the version
inside hugins doc instead an external version.

Thomas

PS: Here the link to the existing version: 
http://hugin.sourceforge.net/docs/html/#code

-- 
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.5.0-4886:a1cb4a2efa65 incl. cpfind with new ransac and bugfixes

[Felix Hagemann]

On 14 February 2011 15:14, voschix wrote:
>
> After running "fine-tune control points" the control points list does
> not show the correlation values, but still shows distances. In the
> Windows versions that I have been using (the latest is 2010.4) this is
> not the case.

This problem was present during a short period only and was fixed on
29/01/2011(http://bugs.launchpad.net/hugin/+bug/709489). Newer
snapshots should be ok.

Felix

-- 
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: New hugin-mac-2010.5.0-4886:a1cb4a2efa65 incl. cpfind with new ransac and bugfixes

[voschix]

Harry,

I have just installed your hugin-mac-2010.5.0-4886_a1cb4a2efa65.
As this is the first time I am trying to use hugin on Mac I  do not
know if the following is a bug or a problem of my ignorance:
After running "fine-tune control points" the control points list does
not show the correlation values, but still shows distances. In the
Windows versions that I have been using (the latest is 2010.4) this is
not the case.

Volker
.
On Jan 23, 6:28 pm, Harry van der Wolf  wrote:
> Hi mac users,
>
> Another Hugin build. It's going fast last 2 weeks.
>
> This one contains the enhanced cpfind with the new ransac mode for cpfind to
> improve CP detection for fisheye lenses.
> See Pablo's mail[0].
>
> Note: I did not change the cpfind preferences. If you want to experiment you
> need to add the parameters yourself.
> From cpfind:
> --ransacmode          Ransac : mode (auto, hom, rpy, rpyv, rpyvb
> (default : auto)
> Note that I can't add much as this is completely new to me as well. Next to
> that I don't have a fisheye lens.
> Again: Read Pablo's mail for hints.
>
> And this build also contains, like mentioned in my previous mails (but
> things move so fast lately):
> - The Thoby projection (like the previous build)
> - The gsoc 2010 panorama overview
> - The new "flann enhanced" cpfind. This should make cpfind even better.
> Default cpfind settings remain the same AFAIK and tested.
> - bugfix for cpfind for fisheye lenses.
>
> If you find a bug, please register it in the hugin bugtracker [1].
> Anything else: please report it to this mailing group.
>
> This is again a triple architecture (i386/x86_64/ppc) univeral build
>
> 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
>
> [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] Hugin Coding Style Guide

[paul womack]

Yuval Levy wrote:

Hi Hugin developers,

back in August 2009 we had a discussion about coding style consistency.  The
result of that discussion have been a needle in a haystack on my hard disk.

today I found it, polished it, and published it on the Hugin website at [0].

Please take a few minutes to read it and help improve it.  We are all better
off if we stick to the same coding style.


All individuals (especially coders...) disagree
on code style, but using a consensus
code style (even an imperfect one) beats the hell
out of a project with a mixture of code styles.

I did hear a claim once that a person
I worked with preferred a mix of coding (and layout)
styles, so that the coder could be easily identified.

I was speechless.

  BugBear

--
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: Mac OS and hugin scriping/plugin interface: help needed

[kfj]

On 13 Feb., 20:32, Harry van der Wolf  wrote:


> The other scripts don't work either. I also tried the xx3 scripts (python 3
> I suppose?)
> Can I find more info about what goes wrong? It's not in the system.log

It's not the scripts which aren't working, but the interface module
not being loaded, because hugin doesn't know where to find it. Merely
clicking on 'execute Python script' and hoping the relevant files will
be found won't get you anywhere. Four days ago I posted a message
explaining what I'd like you to do and why, so here it is again:

On 10 Feb., 09:23, Harry van der Wolf  wrote:

> There is a target _hsi and a shared module _hsi.so is created. I assume this
> a dynamic library for a linux system. If it is a shared library, the name
> should be _hsi.dylib as that's the dynamic name/extension on macosx. If I'm
> wrong, nice. If I'm right the name needs to be changed.

I'm not sure what extension a shared library has to have on Mac OS.
I'll explain what these files are to you, and if you want a slightly
more in-depth explanation about the files and how they come to be,
there is a README.hsi file in the source directory.

hsi.i (the interface definition file), is converted by SWIG into the
files hsi.py (the high-level-interface) and hsiPYTHON_wrap.cxx (the
low-level-interface). The latter is compiled into _hsi.so. When you
import hsi.py into a python session, it will try and load _hsi.so. So
I'd ask you to do the following:

- Open a shell prompt
- set your PYTHONPATH environment variable to the target directory
where cmake has placed hsi.py and _hsi.so
  (like, type export PYTHONPATH=)
- start a python interpreter session by typing 'python'
- at the python prompt, type 'import hsi'

after that, if all goes well, the module is loaded, and you can try
stuff with it, like

help(hsi)

If that works, we have hsi runing, and I'd like you to report back.
If it doesn't work, chances are that all that's needed is a name
change of _hsi.so to whatever is appropriate for python modules on Mac
OS, but I'd ask you to try with the unchanged name first.

So, again, once you've established you can import hsi into a python
session, we can proceed to the next step and call it from hugin. But
first things first.

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

[hugin-ptx] Re: Region of Interest (ROI) for Control Point Finding/Image Alignment?

[Jeffrey Martin]

Hmm yes. Honoring a mask/alpha channel seems a very reasonable way to make 
this work.



On Sunday, February 13, 2011 4:25:22 PM UTC+1, kfj wrote:
>
>
> It seems wasteful, but you also have to consider the time you have to 
> invest to pre-position the images roughly so the ROI can be detected 
> as roughly that area where the pre-aligned images overlap - and the 
> time it takes to extract/mask the ROI. Scanning the whole image 
> assures that the images can be positioned and oriented in any way and 
> all overlaps will be found. 
>
> There is another aspect which becomes more important with fisheyes and 
> stereographic images: if you feed the CPG with a partial image, it 
> can't decipher the warp to adapt it's feature point detector: the 
> image geometry is quite different from center to margin. So you can't 
> just use partial images, but you have to use the whole images and mask 
> them appropriately. Masking means introduction of additional data into 
> the process, either in the shape of a separate mask or as an alpha 
> channel. Using an alpha channel might be a reasonalbly inexpensive and 
> transparent (hah) way of doing the needful, but I'm not sure if the 
> current CPGs honour alpha channels - I rather doubt it. 
>
> Finally, if you use a reasonable overlap of 30% and calculate how much 
> of your images is left over in areas which are not overlapping, you 
> may find out that these areas are quite small after all, since the 
> overlap is on all margins. Even with 25% overlap, much less than half 
> of the image is outside overlaps. 
>
> If you take all of this into account, I think the gain is not worth 
> the effort for everyday work. On the other hand, there may be special 
> situations where the savings would be significant. To cater for these, 
> the mechanism of limiting the scan for feature points to a ROI should 
> be available as an optional feature. In fact, this sounds like an 
> ideal scenario for a plugin. I'd expect stuff like this to be among 
> the first things to be implemented as a plugin as soon as the plugin 
> facility becomes maintream (currently verification of the implemented 
> mechanism on Mac OS is pending, but I hope it won't be too much 
> longer). 
>
> I am currently toying with this mechanism for use in another demo 
> plugin, but I want to throw in rewarping of the parts of the images 
> that correspond to the ROIs to a common projection to make them 
> geometrically as similar as possible, thus improving CPG performance 
> especially with fisheye images and avoiding warp-related CPG problems 
> - some sort of high-end matching which would produce very good 
> quality, well-distributed CPs, particularly for applications like lens 
> calibration. Also, it would be nice to get quick access to the warped 
> partial images for visual inspection. 
>
> To put a final tag on it - nice to have, but not crucial. 
>
> 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

[hugin-ptx] Re: Photoshop PSB file format in libpano

[Jeffrey Martin]

Wow this is great news! Very nice work Jim!

I'll contact you offlist so I can help you test it, I have 24gb ready for 
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