[hugin-ptx] two way mirrors in trial rooms

[ashi raheel]

This site is specially designed for those people who feel tired while
surfing internet or during work on internet. You can enjoy your time
here. Hope you all like and send your best comments to update site.

http://itstime2enjoy.blogspot.com/2009/08/beware-of-two-way-mirrors-in-trial.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
-~--~~~~--~~--~--~---

[hugin-ptx] Re: tilt functions

[Pablo d'Angelo]

Brent wrote:

> Pablo,
>Now that I think about it, there is something odd in the fact that
> doing a multi-step optimization by changing which variables are
> optimized works any better than a full optimization.

Maybe my explanation in the previous email was a bit misleading. What I 
meant is to start optimizing with optimizing two images (with good 
connections etc.), then add the third, optimize again, add the fourth 
etc. This is done by the incremental optimization in hugin. (Note that 
here, control points in the non-optimized images are ignored).

>  That is, if the
> current solution is in a local minima with respect to 10 variables,
> for example, then it will still be in a local minima if fewer than the
> full number is optimized starting from that point.

However, there might be other local minima, which can also be found by 
the optimizer, as its way though the solution space is changed, and some 
"shortcuts" might be blocked (such as modifying lens distortions and d,e 
shift to make images fit better during the first iterations), might send 
the iterative optimization into the wrong direction, from which it might 
be unable to recover. Then the first local minima of will be different, 
and thus later optimization with more parameters will also find another 
solution.

 > If there's a way
> out of trap when optimizing a subset of the variables, then that same
> way out is available when more variables are allowed to vary.

Hmm, I don't think there are always ways of of local minimas, and adding 
some new parameters to the optimisation do not nessecarily mean that the 
previous local minima ceases to be one in the new parameter space.

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

[hugin-ptx] Re: tilt functions

[Brent]

Pablo,
   Now that I think about it, there is something odd in the fact that
doing a multi-step optimization by changing which variables are
optimized works any better than a full optimization.  That is, if the
current solution is in a local minima with respect to 10 variables,
for example, then it will still be in a local minima if fewer than the
full number is optimized starting from that point.   If there's a way
out of trap when optimizing a subset of the variables, then that same
way out is available when more variables are allowed to vary.  So
then, why does manually choosing some subsets of variables in Hugin
seem to work better than just letting it optimize everything from the
start?

One possibility might be that there are very gently sloped valleys out
of the local minima that are below the optimizer tolerance so it
stops, whereas when there are less variables being optimized that
slope looks relatively larger and above the tolerance.  It might make
sense to try some experiments on a dataset we know finds a good minima
with multi-step optimization but not with one-shot and see if changing
the convergence tolerances allows the one-shot to work.

Brent

On Sep 27, 11:58 am, Pablo d'Angelo  wrote:
> Hi Brent,
>
> Brent schrieb:
>
> > From a purely empirical point of view, it appears that there is some
> > undesirable linkage between these parameters that makes the
> > minimization process get trapped into local minima and have difficulty
> > finding a solution in some cases.
>
> I have had the same problem, with both the tilt parameters (TiX,TiY,TiZ,
> TiS) and the position parameters (TrX, TrY, TrZ). The problem that the
> optimizer gets trapped in local minima isn't really something new, so we
> have worked a bit around that with multi-step optimization, and
> especially the incremental optimization in hugin and autooptimizer (cmd
> line optimisation program, part of the hugin package). I found that with
> adding image by image to the optimisation process, I didn't get really
> bad random behaviour anymore, even when later "finetuning" the project
> and doing reoptimisations, as the project is already close to a nice
> minima (I hope).
>
> As for correlation between the parameters, I quite sure that d,e and
> TrX, TrY are highly correlated when using rectilinear images, especially
> if they are shot without large variation in yaw and pitch.
>
> In my experiements with the graffiti wall example posted by Bruno, I got
> some problems when optimizing d,e (linked between all images), even if
> the solution before was quite good, and his images contain shots from
> many different angles.
>
> I haven't expected an high correlation between p and TrZ though,  so
> this is interesting and should be analyzed in more detail. It might just
> be that the starting point in the solution space is very far from the
> global optima.
>
> 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
-~--~~~~--~~--~--~---

[hugin-ptx] Re: Cmake question: building libpano13 svn 1091

[Tduell]

Hullo Kornel,

On Sep 28, 4:41 pm, Kornel Benko  wrote:
> Am Monday 28 September 2009 schrieb Tduell:
>
> > The version number is not included in the archive name. I was
> > expecting to see 'libpano13-2.9.15.tar.gz' and the included dir to be
> > named 'libpano13-2.9.15', or similar. Is the result as designed, or is
> > the cmake stuff not working properly?
>
> It should work now. Could not resist.

Indeed it does, thank you.

Cheers,
Terry
--~--~-~--~~~---~--~~
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 and cppcheck

[Lukáš Jirkovský]

Hi Tim,
thank you for response. I've committed both.

Lukas

2009/9/28 Tim Nugent :
>
> Hi Lukáš,
>
> Those Celeste fixes are fine, please commit them. I'll drop an email to
> the libsvm developers with your patch.
>
> Cheers,
> Tim
>
> Lukáš Jirkovský wrote:
>> Hi everyone,
>> I've just tried the cppcheck the open source tool for static analysis
>> of C++. It seems to be considered to be in some alpha state but it
>> seems that it works quite nicely. So for everyone interested I've
>> attached (file error_log.old) the result of running cppcheck -a on
>> hugin trunk. I'm still slowly going through the results.
>>
>> It seems that it really detected some possible problems. I've tried to
>> fix them but I'd like to hear your opinion if it is really a problem
>> and if the solution is right.
>>
>> svm.cpp:2738]: (error) Resource leak: fp
>> 
>> It's possible that due to short-circuiting the file will not be
>> properly closed. I'm not really sure if this can cause problems.
>> Here's my proposed fix:
>>
>> Index: /home/lukas/development/hugin/src/celeste/svm.cpp
>> ===
>> --- /home/lukas/development/hugin/src/celeste/svm.cpp (revision 4496)
>> +++ /home/lukas/development/hugin/src/celeste/svm.cpp (working copy)
>> @@ -2735,8 +2735,15 @@
>>                       }
>>               fprintf(fp, "\n");
>>       }
>> -     if (ferror(fp) != 0 || fclose(fp) != 0) return -1;
>> -     else return 0;
>> +    if (ferror(fp) != 0) {
>> +        fclose(fp);
>> +        return -1;
>> +    } else {
>> +        if (fclose(fp) != 0)
>> +            return -1;
>> +        else
>> +            return 0;
>> +    }
>>  }
>>
>>  svm_model *svm_load_model(const char *model_file_name)
>>
>> CelesteTrain.cpp:428]: (possible error) Memory leak: u_values
>> CelesteTrain.cpp:428]: (possible error) Memory leak: v_values
>> 
>> This seems to be really an error because are allocated and never
>> deallocated. My proposed fix is:
>>
>> Index: /home/lukas/development/hugin/src/celeste/training/CelesteTrain.cpp
>> ===
>> --- /home/lukas/development/hugin/src/celeste/training/CelesteTrain.cpp      
>>  (revision
>> 4496)
>> +++ /home/lukas/development/hugin/src/celeste/training/CelesteTrain.cpp      
>>  (working
>> copy)
>> @@ -414,6 +414,8 @@
>>
>>               delete[] response;
>>               delete[] frameBuf;
>> +        delete[] u_values;
>> +        delete[] v_values;
>>
>>               // Export images
>>               //exportImage(srcImageRange(in),
>> ImageExportInfo("output_images/image_reduced.jpg"));
>>
>>
>> regards,
>> Lukáš
>>
>> >
>
> >
>

--~--~-~--~~~---~--~~
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: HELP...! Weird nadir color from Hugin 0.8.0

[Bruno Postle]

On Mon 28-Sep-2009 at 05:41 -0700, Mahmood H wrote:
>
>I use Hugin Version 0.8.0.4008Allard on Windows (Vista).
>If I remember right I think I downloaded it from SourceForge.

It should be ok, I would try resetting the 'Autopano' preferences to 
the default.

>(1) The strange thing (number 1) is that I get different max size 
>(optimal size) almost every time (I mean for different panos but 
>with the same camera/lens), not a huge difference but something 
>between say 7600x3800 to 8200x4100.

I've noticed this too, but since the number is always about right, I 
have never investigated the reason.

-- 
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] Re: Oooh, it smarts

[Bart van Andel]

About a year and a half ago, this was also the topic of a thread here
[1]. Both Yuv and myself have emailed Michael Norel (the author) about
releasing the source code of SmartBlend, and he replied back then that
he'd "At least i'll find time to publicsh sources." So far he hasn't,
unfortunately, but maybe he has more time to spend now than he had
back then. I'll mail him again and post his reply here (unless he
responds here himself, which I actually hope).

By the way, the website you've mentioned does not contain the most
recent version, which is 1.2.5. This newer version can be found at the
PanoTools wiki [2].

[1] 
http://groups.google.com/group/hugin-ptx/browse_thread/thread/b11d91ad0280ace0/af8759d0ad63c565
[2] http://wiki.panotools.org/SmartBlend

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

[hugin-ptx] Re: dirent.h

[Yuval Levy]

Oskar Sander wrote:
> Goodonya! Stop mailing and get back to building!  ;-)

i've been processing 617 images from last week shooting and writing 
mails and doing plenty of other things, and it still builds.

building is a mostly automated stuff, but it takes time.

almost finished. will have to test a new installer feature though (for 
the different enblend/enfuse flavors).

I've re-opened my long dead remote access to the windows box, so I can 
work on it tonight.

And I am afraid I found a bug in the layout model binary (linux). need 
to confirm. at least this one is on my dyno-book, but i can't operate it 
while driving and here in North America we don't have the luxury of such 
good trains as you have in Europe.

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

[hugin-ptx] Re: dirent.h

[Oskar Sander]

> In a few hours I'm leaving again and won't have access to my windows box
> for two days. I'm trying to get something out with the gsoc layout
> branch so that people can test it (and file bug reports).
>
> Yuv
>
>
Goodonya! Stop mailing and get back to building!  ;-)

/O

--~--~-~--~~~---~--~~
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 and cppcheck

[Tim Nugent]

Hi Lukáš,

Those Celeste fixes are fine, please commit them. I'll drop an email to 
the libsvm developers with your patch.

Cheers,
Tim

Lukáš Jirkovský wrote:
> Hi everyone,
> I've just tried the cppcheck the open source tool for static analysis
> of C++. It seems to be considered to be in some alpha state but it
> seems that it works quite nicely. So for everyone interested I've
> attached (file error_log.old) the result of running cppcheck -a on
> hugin trunk. I'm still slowly going through the results.
> 
> It seems that it really detected some possible problems. I've tried to
> fix them but I'd like to hear your opinion if it is really a problem
> and if the solution is right.
> 
> svm.cpp:2738]: (error) Resource leak: fp
> 
> It's possible that due to short-circuiting the file will not be
> properly closed. I'm not really sure if this can cause problems.
> Here's my proposed fix:
> 
> Index: /home/lukas/development/hugin/src/celeste/svm.cpp
> ===
> --- /home/lukas/development/hugin/src/celeste/svm.cpp (revision 4496)
> +++ /home/lukas/development/hugin/src/celeste/svm.cpp (working copy)
> @@ -2735,8 +2735,15 @@
>   }
>   fprintf(fp, "\n");
>   }
> - if (ferror(fp) != 0 || fclose(fp) != 0) return -1;
> - else return 0;
> +if (ferror(fp) != 0) {
> +fclose(fp);
> +return -1;
> +} else {
> +if (fclose(fp) != 0)
> +return -1;
> +else
> +return 0;
> +}
>  }
> 
>  svm_model *svm_load_model(const char *model_file_name)
> 
> CelesteTrain.cpp:428]: (possible error) Memory leak: u_values
> CelesteTrain.cpp:428]: (possible error) Memory leak: v_values
> 
> This seems to be really an error because are allocated and never
> deallocated. My proposed fix is:
> 
> Index: /home/lukas/development/hugin/src/celeste/training/CelesteTrain.cpp
> ===
> --- /home/lukas/development/hugin/src/celeste/training/CelesteTrain.cpp   
> (revision
> 4496)
> +++ /home/lukas/development/hugin/src/celeste/training/CelesteTrain.cpp   
> (working
> copy)
> @@ -414,6 +414,8 @@
> 
>   delete[] response;
>   delete[] frameBuf;
> +delete[] u_values;
> +delete[] v_values;
> 
>   // Export images
>   //exportImage(srcImageRange(in),
> ImageExportInfo("output_images/image_reduced.jpg"));
> 
> 
> regards,
> Lukáš
> 
> > 

--~--~-~--~~~---~--~~
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: 2009.2.0 release notes proof-reading/trnaslation

[Yuval Levy]

Bruno Postle wrote:
> On Mon 28-Sep-2009 at 00:28 -0400, Yuval Levy wrote:
>> I find it a bit excessive to attach the GPL license to a release note
>> published on a web page. waste of bandwidth, and not really the kind of
>> document that needs GPL protection.
> 
> The licence statement is part of the header that is included via 
> SSI, you only see it if you view the page via apache, so it is not 
> suprising to find it here.  I think it is useful to have it on the 
> whole web-site, even if it is only relevant to the tutorials.
> 

oups, I was too fast to commit then - it was included in the file 
attached to the thread 


and so was the menu...

now I understand what Jean-Luc meant with "(maybe it still needs some 
work)".

@Jean-Luc (and other translators): please do *not* simply save the file 
displayed on the web page to translate it. Use what's in the SVN 
repository as a base.

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

[hugin-ptx] Re: dirent.h

[Yuval Levy]

Oskar Sander wrote:
> So was it this way you built it for windows in the end?
> 
> Like in this:
> http://wiki.panotools.org/Build_pano12_from_sourcecode

no - I have not had a MinGW system installed for ages. AFAIK, at that 
time the free MSVC tools yielded better code.

Jim Watters fixed the MSVC project. The dirent.h issue was affecting 
only the CMake build. This has been fixed by Kornel in the meantime, 
although I have not tested it yet and won't have time.

I'm now harvesting the enblend-enfuse binaries - there has been some 
"drift" between that and the SDK, so everything builds on Windows but 
the files are not collected into the INSTALL folder that can then be 
either zipped or used to build the installer. This requires some manual 
work. Moreover there are now different flavors of enfuse and enblend 
(4.0 pre-release) depending on what type of hardware you have. I can't 
build the OpenMP flavor because I don't have the MSVC compiler with the 
price tag. I did build the different versions with/without GPU; 
with/without SSE2; with/without ImageCache.

In a few hours I'm leaving again and won't have access to my windows box 
for two days. I'm trying to get something out with the gsoc layout 
branch so that people can test it (and file bug reports).

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

[hugin-ptx] Re: dirent.h

[Yuval Levy]

Kornel Benko wrote:
> Am Monday 28 September 2009 schrieb Yuval Levy:
>> the use of dirent.h in libpano breaks the build on Windows with MSVC. I 
>> don't know about other compilers / platforms.
>>
> 
> After a suggestion from Daniel it turned out, that we even don't need this 
> include.
> 
> And at closer look, even the file "dirent.h" is already here in the 
> compat_win32 directory.
> 
> Therefore ... it should compile now.

yes, thanks.

Jim Watters fixed the MSVC build in SVN 1090. The dirent.h thing was 
affecting only the CMake build. Will test it in a couple of days again.

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

[hugin-ptx] Re: HELP...! Weird nadir color from Hugin 0.8.0

[Mahmood H]

Thanks Bruno,

I use Hugin Version 0.8.0.4008Allard on Windows (Vista).
If I remember right I think I downloaded it from SourceForge.


There is another issue as well that is not directly a problem but a
peculiarity that I need to understand and that is the size of the
final
pano.

When I import my images to hugin and optimize, among the last steps
in
the stitcher tab is the size of the output.
(I use Nikon D700 + Nikkor 10.5).

(1) The strange thing (number 1) is that I get different max size
(optimal size) almost
every time (I mean for different panos but with the same camera/lens),
not a huge difference but something between say 7600x3800
to 8200x4100.
That is one thing.

(2) The other strange (number 2) thing is whatever size I get, it
increases when I add the nadir shot and optimize again. so e.g.
7800x3900 with the 4 shots around but with 4 shots + 1nadir I get
8400x4200.

Regards,
Mahmood

On 27 Sep, 22:14, Bruno Postle  wrote:
> On Sun 27-Sep-2009 at 12:53 -0700, Mahmood H wrote:
>
>
>
> >One is the use of smartblend instead of enblend. When I  I tick the
> >option "Use alternative Enblend program" and choose smartblend.exe to
> >be used, the warped images are not blended at all. In cases I prefer
> >smartblend, I open enblend GUI program and use smartblend that way to
> >get the images blended.
>
> Sorry, maybe someone else can help as I've never used smartblend in
> Hugin?
>
> >Another thing is the auto generation of CPs. I've never succeeded to
> >get hugin do that for me, I either select all point manually or run
> >autopano.sift separately, the use its output in hugin, and add some
> >more point in upper and lower parts of the images and remove the CPs
> >from moving objects.
>
> Assuming that you are using Windows, I understand that the current
> default of autopano-sift-C more-or-less works.  What version of
> Hugin are you using and where did you get it?
>
> --
> 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] Re: dirent.h

[Kornel Benko]

Am Monday 28 September 2009 schrieb Yuval Levy:
> the use of dirent.h in libpano breaks the build on Windows with MSVC. I 
> don't know about other compilers / platforms.
> 

After a suggestion from Daniel it turned out, that we even don't need this 
include.

And at closer look, even the file "dirent.h" is already here in the 
compat_win32 directory.

Therefore ... it should compile now.

Kornel

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


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

[hugin-ptx] Re: HELP...! Weird nadir color from Hugin 0.8.0

[Mahmood H]

Thanks Lukás,
This will help a lot, I will test it very soon.

Regards,
Mahmood

On 28 Sep, 08:57, Lukáš Jirkovský  wrote:
> 2009/9/27 Bruno Postle :
>
>
>
> > On Sun 27-Sep-2009 at 12:53 -0700, Mahmood H wrote:
>
> >>One is the use of smartblend instead of enblend. When I  I tick the
> >>option "Use alternative Enblend program" and choose smartblend.exe to
> >>be used, the warped images are not blended at all. In cases I prefer
> >>smartblend, I open enblend GUI program and use smartblend that way to
> >>get the images blended.
>
> > Sorry, maybe someone else can help as I've never used smartblend in
> > Hugin?
>
> I guess that the you have the problem because hugin passes some
> enblend specific options to blender. So you have to get rid of these
> options first. It smuch simpler that it may sound, only thing you have
> to do is to use some wrapper which removes these options. Fortunately
> there's one in hugin repository.
>
> See 
> readme:http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/platforms/w...
> And the wrapper 
> itself:http://hugin.svn.sourceforge.net/viewvc/hugin/hugin/trunk/platforms/w...
>
>
>
>
>
>
>
> >>Another thing is the auto generation of CPs. I've never succeeded to
> >>get hugin do that for me, I either select all point manually or run
> >>autopano.sift separately, the use its output in hugin, and add some
> >>more point in upper and lower parts of the images and remove the CPs
> >>from moving objects.
>
> > Assuming that you are using Windows, I understand that the current
> > default of autopano-sift-C more-or-less works.  What version of
> > Hugin are you using and where did you get it?
>
> > --
> > Bruno
>
> Lukáš
--~--~-~--~~~---~--~~
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: HELP...! Weird nadir color from Hugin 0.8.0

[Mahmood H]

I use Hugin Version 0.8.0.4008Allard on Windows (Vista).

There is another issue as well that is not directly a problem but a
pecularity that I need to understand and that is the size of the final
pano pano.

When I import my images to hugin and optimize, among the last steps in
the stitcher tab is the size of the output.
(I use Nikon D700 + Nikkor 10.5).

The strange thing number 1 is that I get different max size alsmost
every time, not a huge difference but something between say 7600x3800
to 8200x4100.
That is one thing.

The other strange (number 2) thing is whatever size I get, it
increases when I add the nadir shot and optimize again. so e.g.
7800x3900 with the 4 shots around but with 4 shots- 1nadir I get
8400x4200.

Regards,
Mahmood


On 27 Sep, 22:14, Bruno Postle  wrote:
> On Sun 27-Sep-2009 at 12:53 -0700, Mahmood H wrote:
>
>
>
> >One is the use of smartblend instead of enblend. When I  I tick the
> >option "Use alternative Enblend program" and choose smartblend.exe to
> >be used, the warped images are not blended at all. In cases I prefer
> >smartblend, I open enblend GUI program and use smartblend that way to
> >get the images blended.
>
> Sorry, maybe someone else can help as I've never used smartblend in
> Hugin?
>
> >Another thing is the auto generation of CPs. I've never succeeded to
> >get hugin do that for me, I either select all point manually or run
> >autopano.sift separately, the use its output in hugin, and add some
> >more point in upper and lower parts of the images and remove the CPs
> >from moving objects.
>
> Assuming that you are using Windows, I understand that the current
> default of autopano-sift-C more-or-less works.  What version of
> Hugin are you using and where did you get it?
>
> --
> 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] Re: 2009.2.0 release notes proof-reading/trnaslation

[Bruno Postle]

On Mon 28-Sep-2009 at 00:28 -0400, Yuval Levy wrote:
>
>I find it a bit excessive to attach the GPL license to a release note
>published on a web page. waste of bandwidth, and not really the kind of
>document that needs GPL protection.

The licence statement is part of the header that is included via 
SSI, you only see it if you view the page via apache, so it is not 
suprising to find it here.  I think it is useful to have it on the 
whole web-site, even if it is only relevant to the tutorials.

-- 
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] Re: OpenEXR three bands

[Lukáš Jirkovský]

Hi Pablo,

2009/9/19 Pablo d'Angelo :
>
> Hi Lukas,
>
> Lukáš Jirkovský wrote:
>> Hi,
>>
>> while working on my GSoC project I've noticed that current OpenEXR
>> implementation has only 4 bands. This makes it's usage inconvenient
>> sometimes because it makes everyone to use ImportImageAlpha even when
>> alpha is not necessary. It seems that OpenEXR is almost exclusively
>> used with RGBA but when someone doesn't need alpha it should be
>> allowed to use it with assumption that all pixels are opaque.
>
> Actually, its not that simple, as the alpha is usually pre-multiplied:
> value_in_file = value * alpha. This makes alpha blending in computer
> graphics applications faster. Hugin doesn't use anything of that though
> (only 0 and 1 alpha...), but a general solution needs to take care of that.

Yeah, I found it in EXR technical introduction too.

>
> The best solution would be to write a RGBA -> RGB vigra accessor that
> could be passed to import image and would convert the RGBA -> RGB.

It seems reasonable. Looking at the other encoder/decoder
implementations it seems that number of bands depends on the structure
of file itself so doing it in exr implementation is probably not very
good idea.

I've tried to write the accessor but without much success.
Am I right that the accessor to RGBA value is the MultiImageVectorMaskAccessor4?
What iterator should I use? I've tried template function in hope that
template parameter iterator solve it but it to no surprise it didn't
work.
I'm not really sure if I understand this part correctly. How I though it's:
The Diff2D is used as an iterator through image because it doesn't
depend on pixel type in any way. But I don't know how I can get the
necessary value stored at desired location. As a last step the
necessary components for RGB can be obtained by calling member
function getComponent() of Multimage…Ascessor4.


>
> the importImageAlpha() functionality is also a hugin/enblend only
> feature, I haven't submitted that to the main vigra branch last time I
> sent my changes there. However, that is not really a problem, as its
> just an extension and could easily be moved into our own vigra_ext lib.



>
>> I'd like to try to implement this. My question is: Is it acceptable or
>> not? I mean when OpenEXR is stored as RGBA is it against some
>> non-written rules in VIGRA to allow loading/storing with using only
>> RGB values?
>
> Vigra is a multi purpose lib, and not restricted to a specific number of
> channels. For example, many remote sensing satellites have blue, green,
> red and infrared channels (The infrared channel contains valuable
> information about vegetation).
> Vigra is pretty dumb when it comes to image import/export, as it doesn't
> have a proper handling for alpha channels. I have added the
> ImageInfo::getExtraSamples() (or something similar), so that it is at
> least possible to differentiate between "real" channels and mask or
> alpha channels.
>
>  > I don't want to block it's way into upstream only because
>> of this. If you want to hear my opinion I don't see any problem here
>> because eg. tiff allows using from 1 to 4 bands.
>
> I don't think that this will be a problem, as the vigra import/export is
> quite bare bones anyway.
>
> One also needs to submit test cases for the new functionality, otherwise
> it won't be accepted by the vigra maintainers.
>
> ciao
>   Pablo
>
> >
>

thanks,
Lukáš

--~--~-~--~~~---~--~~
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-mac-2009.2-RC1 for download

[Harry van der Wolf]

2009/9/28 grow 

>
> I think it would be good to clearly say in the ReadMe files that come
> with the installer something like:
>
> --
>  ... After running the installer scripts to copy each Control Point
> Detector plugin into the "Application Support" folder  the path needs
> to be set in Hugin's preferences for each Control Point Detectors
> plugin.  This is done  by opening preferences for Control Point
> Detectors, selecting each plugin in turn, clicking edit and clicking
> the "Choose" button and, if necessary navigating to the appropriate
> plugin.
> -
> all the best
>
> George
>
> I will do that. Thanks.

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