[hugin-ptx] Day/night photo stack how-to

[Ryan Johnson]

Hi all,

This is probably a use of hugin that everyone but me already knew, but 
it's possible to align day and night versions of a panorama even if the 
two sets of photos are fairly different (assuming they do overlap and 
have the same parallax, of course). For example, I have a day/night pano 
of the Pittsburgh skyline here: 
http://www.ece.cmu.edu/~ryanjohn/pittsburgh.html. With javascript 
enabled, mousing over the image will change it from day to night, in 
theory without any buildings changing position.


The process started out straightforward enough:
- add the two batches of photos separately so they get different lenses
- set control points as normal for each batch, then also add 2-3 control 
points per image to connect the two batches with each other

- optimize everything

Unfortunately, exposure optimization was a bit hairy because the 
optimization process did very badly with the hugely different exposures 
between the two batches. The problem persisted even with only one batch 
selected/optimized at a time (everything was either duper-dark, 
super-bright, or super-washed-out). The workaround was to save two 
copies of the geometry-optimized project, then delete one batch of 
photos from each copy and optimize exposure separately (after setting 
appropriate anchors).


Notes:
- the two batches of photos don't have to be taken the same way for this 
to work: in my case the day shot had 9 hand-held portrait photos and the 
night shot had 4 balanced-on-railing landscape photos.
- it doesn't really work to stitch each batch separately and then try to 
align them (maybe because I stitched with a Mercator projection, which 
isn't a valid lens import type?)
- between-batch control points had to be set manually because day and 
night shots tend to be inverted, contrast-wise, which completely 
confuses automatic cp gen


In summary, this is mostly a report on how to stack day/night photos, 
with something of a bug report for the exposure optimization issue.


Enjoy!
Ryan

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

To unsubscribe from this group, send email to hugin-ptx+unsubscribegooglegroups.com or 
reply to this email with the words "REMOVE ME" as the subject.

Re: [hugin-ptx] Re: Repository

[Bruno Postle]

On Fri 19-Mar-2010 at 19:26 -0400, Yuval Levy wrote:


I also don't know how packagers for distros such as Fedora, 
Debian, Ubuntu and the dozens or hundreds of other do get their 
source code. Simply interrupting SVN "read-only" service may 
interrupt the flow.


They should be using the released tarballs, we don't need to worry 
about supporting a distribution that doesn't.


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

To unsubscribe from this group, send email to hugin-ptx+unsubscribegooglegroups.com or 
reply to this email with the words "REMOVE ME" as the subject.

Re: [hugin-ptx] Improvements to the fast preview window

[James Legg]

On Sat, 2010-03-20 at 17:15 +0100, Darko Makreshanski wrote:
> Hi,
> 
> I have some ideas which I would like to present and get feedback of you 
> for a project. It basically includes the "Zooming for Fast Preview" and 
> other improvements to "Fast Preview"
> 
> My ideas are mostly concerned for users that are just beginning with 
> hugin, and users with not much knowledge of map projections and panorama 
> creation.
>   * one goal is to attract more users by giving a fancy and more 
> user-friendly interface to the preview.
>   * another is to give some features, that might be useful to most of 
> you as well
> 
> Basically currently the fast preview is a openGL version of the old 
> preview with some features and some drawbacks (the texture quality), and 
> I believe that OpenGL can provide much more user-friendliness to the 
> preview.
> 
> Here are the problems to the preview that I thing currently are the 
> biggest problem for beginners:
>  - it's completely unintuitive that in the move/drag section, users 
> actually rotate the panorama. The problem of this is that the 3D 
> rotation space commands are represented in a 2D plane, with the vertical 
> axis for two dimensions.
>  - when there are several groups of images, users can handle these 
> independently, however this is also unintuitive, since for a user to 
> handle a specific group he must click/drag the group, and this combined 
> with the previous problem is a pain.
>  - currently with this preview to get a larger overview of the 
> panorama, you must change the field of view or the projection mode.
>  - people with no knowledge of the types of projections, are only 
> left to experiment with the projections and look at the result without 
> actually having a good visualization of the distortions that are occurring
> 
> Also something I didn't like is that in many cases I couldn't spot areas 
> where there was no image data, because the background was black and 
> blended with parts of the image.
> 
> What I propose is the following:
> 
> First the current mode of preview will remain as it is (with some 
> improvements) and will be called a '2D Projection' mode where the user 
> would just use to modify the final result.
> Apart from this mode I also propose two additional modes (3D panosphere, 
> and combination of 3D panosphere and 2D projection):
> 
> First, some features that would be included in both 'Projection' and 
> 'Panosphere' mode:
> - the user could zoom in/out and image resolutions would be 
> dynamically increased for more detail. (the idea on the wiki)
> - better manipulation of image groups where user could select a 
> group or the whole panorama and adjust accordingly

These have been asked for before, so they would be welcome additions.

> - adjustable and very distinctive background for both modes, to spot 
> the areas without image data

This could be useful.

> - a interleaving colorful grid will be displayed to examine distortion

That might help people understand the projections, if they are aware
what the grid means.

> 1. A '3D Panosphere' mode.
> - I read the 'Next GUI' discussion, and I noticed there were some 
> thoughts on this already.
> 
> In this mode the user would basically look into a 3D sphere mapped 
> with the images, with option to look at the sphere either from inside or 
> outside.
> 
> The purpose of the sphere mode is that it is the basic representation of 
> what the panorama actually is, and I believe it is the most intuitive 
> representation.
> 
> The benefits of this mode:
> - primarily to distinguish between looking at the output and looking 
> at an overview of the panorama.
> - the most intuitive and most exact preview of the panorama (in 
> terms of distortions)

I wouldn't say it was more exact. You will still be mapping a spherical
image to a 2D display. It is also not the most intuitive way for linear
panoramas.

> - in here the 3D rotation adjustments would actually make sense and 
> would be intuitive.
> - the layout submode in this mode would also make a lot more sense
> - a very intuitive and eye-candy preview for new users
> 
> Some of the features that would be included in panosphere mode:
> - a look at the panosphere either from outside or inside (all 
> features available in both modes)
>   * from the inside, the viewpoint would be fixed to the center 
> of the sphere and adjustable would be rotation of the camera and field 
> of view (zoom in/out)

Is this the same as using rectilinear projection?

>   * from the outside, the viewpoint would move around a larger 
> virtual sphere, and would be faced always to the center of the sphere 
> (also adjustable FOV)

Is this similar to orthographic projection? However there is a bug with
orthographic projection in the fast preview: it doesn't clip the images
on the back of the sphere.

I don't think using a small field of view in this projection will be a

Re: [hugin-ptx] GSOC 2010 – Accepted

[D M German]

 Bruno Postle twisted the bytes to say:



 Bruno> On Thu 18-Mar-2010 at 21:00 +0100, Lukáš Jirkovský wrote:
 >> I've just got a great news – it seems that hugin was accepted[1] for
 >> the Google summer of code 2010!
 >> 
 >> [1] http://socghop.appspot.com/gsoc/program/accepted_orgs/google/gsoc2010

 Bruno> We have two or three mentors volunteered so far, we need more at least
 Bruno> to do backup roles.  Now is the time to volunteer for mentoring.  We
 Bruno> also need a backup admin as I will have limited connectivity for some
 Bruno> of the SoC period.

-- 
I can volunteer as a backup (given my success rate in the previos
years).

The project that I really want to see materialize is regression testing
for panotools. If it was easier to test it might make life easier for
those who want to hack it. 

Perhaps we can all pitch-in for a regression testing framework that can
be configured for different tools.

what do others think?

--dmg





--
Daniel M. German  
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .

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

To unsubscribe from this group, send email to 
hugin-ptx+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[hugin-ptx] Re: translatable messages

[prokoudine]

On Mar 21, 12:14 am, Bruno Postle  wrote:

> Now that you say it is broken and is removing useful strings, we
> need to know exactly what they are (or just one example) so we can
> figure out where it is going wrong.

Well, I said that before a couple of times. It's good that somebody
finally cares :)

After running diff I can say that it removes all references to
translations/xrc.cpp

Alexandre

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

To unsubscribe from this group, send email to 
hugin-ptx+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: [hugin-ptx] Re: translatable messages

[Bruno Postle]

On Sat 20-Mar-2010 at 13:57 -0700, Alexandre Prokoudine wrote:

On Mar 19, 8:09 pm, "Ademar de Souza Reis Jr." wrote:


As far as I can see, extract-messages.sh is doing what it's supposed
to do: it removes old messages and adds the new or changed strings.
Please report the exact strings you think are problematic so that we
can investigate.


As far as _I_ can see it removes a lot of messages that are not
supposed to be removed while adding the ones that were missing. Which
I mentioned in the original email.


Yes extract-messages.sh should be run more often and the results 
committed to the trunk, we don't expect translators to have to do 
this every time they work on a .po file.


I don't run it all the time because I'm not in a position to tell if 
I'm breaking anything, hence nobody has done it.


Now that you say it is broken and is removing useful strings, we 
need to know exactly what they are (or just one example) so we can 
figure out where it is going wrong.


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

To unsubscribe from this group, send email to hugin-ptx+unsubscribegooglegroups.com or 
reply to this email with the words "REMOVE ME" as the subject.

[hugin-ptx] Re: translatable messages

[prokoudine]

On Mar 19, 8:09 pm, "Ademar de Souza Reis Jr." 
wrote:

> As far as I can see, extract-messages.sh is doing what it's supposed
> to do: it removes old messages and adds the new or changed strings.
> Please report the exact strings you think are problematic so that we
> can investigate.

As far as _I_ can see it removes a lot of messages that are not
supposed to be removed while adding the ones that were missing. Which
I mentioned in the original email.

> > This is somewhat tiresome really. Does anybody has a grasp on i18n in
> > hugin? Could this please be fixed?
>
> Just give me the details of the problem and I'll be glad to fix it.

I gave them in the original email. Once again: the whole contents of
"Mask" tab including the tab's caption is missing.

> technically speaking, it's working fine, IMO.

What? You mean that a script that is supposed to ease update of
translations re current state of source code and instead removes
useful messages is technically working fine? OMG.

Look, if you want translators to use POT, then POT should always match
real life. If you want translators to create it from scratch, then
make it Just Work *and* no-brainer. I'm used to some extra efforts
like having to run 'make' in some folders of Inkscape before creating
new POT file, because names and descriptions have to be merge from XML
files into a .h file, or running qmake -project and then lupdate
against it in Scribus, but the whole thing with Hugin has been driving
me nuts for years.

Alexandre

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

To unsubscribe from this group, send email to 
hugin-ptx+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

Re: [hugin-ptx] GSOC 2010 – Accepted

[Bruno Postle]

On Sat 20-Mar-2010 at 11:35 +0100, Pablo d'Angelo wrote:

Pablo d'Angelo schrieb:


I'm willing to be a backup admin and backup mentor. I won't be 
available at mid to end of June.


That's fine I'll be around for all of June.  Can you send me your 
'id' on the SoC system and I'll add you as backup admin.


I tried to apply as a mentor for hugin at http://socghop.appspot.com, 
but I couldn't find a way to do so. Hugin is not listed when I select 
"Apply to become a mentor". Hugin is also in the list of projects 
that haven't completed their organisation profile, maybe thats the 
reason.


Should be fixed now.  Could everyone who plans on mentoring or being 
a backup mentor sign up here: 
http://socghop.appspot.com/gsoc/org/show/google/gsoc2010/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

To unsubscribe from this group, send email to hugin-ptx+unsubscribegooglegroups.com or 
reply to this email with the words "REMOVE ME" as the subject.

Re: [hugin-ptx] translatable messages

[Carl von Einem]

Ademar de Souza Reis Jr. schrieb am 19.03.10 18:04:
> On Fri, Mar 19, 2010 at 5:17 AM, Carl von Einem  wrote:
>> You are right, something seems to be missing in the .po file. I use the
>> current translation file as described in
>> 
>>
>> -> 1. Get your *.po file
>> (links to
>> )
> 
> Just to clarify:
> 
> The .po file is not always up-to-date. If someone introduces or
> changes a string in the source-code, the  extract_messages.sh should
> be run. This script will update the .po files with the new strings
> (and remove the old ones).

But as a simple translator who isn't used to touch the sources itself
I'm not familiar with using extract_messages.sh, so my main problem
right now is that the current de.po that I find in
trunk/src/translations/de.po just doesn't contain all strings that
actually are in the latest svn for Mac provided by Harry
(hugin-mac-2010.1.0-svn5031).

I know it's time to dive into the "Become a Power Translator" section of
the Hugin translation guide but right now for me it would be easier to
submit a lat.po in verse format (using Hexameter and Pentameter) than to
follow your (of course valuable) hints. *sigh*

Carl

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

To unsubscribe from this group, send email to 
hugin-ptx+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[hugin-ptx] Improvements to the fast preview window

[Darko Makreshanski]

Hi,

I have some ideas which I would like to present and get feedback of you 
for a project. It basically includes the "Zooming for Fast Preview" and 
other improvements to "Fast Preview"


My ideas are mostly concerned for users that are just beginning with 
hugin, and users with not much knowledge of map projections and panorama 
creation.
 * one goal is to attract more users by giving a fancy and more 
user-friendly interface to the preview.
 * another is to give some features, that might be useful to most of 
you as well


Basically currently the fast preview is a openGL version of the old 
preview with some features and some drawbacks (the texture quality), and 
I believe that OpenGL can provide much more user-friendliness to the 
preview.


Here are the problems to the preview that I thing currently are the 
biggest problem for beginners:
- it's completely unintuitive that in the move/drag section, users 
actually rotate the panorama. The problem of this is that the 3D 
rotation space commands are represented in a 2D plane, with the vertical 
axis for two dimensions.
- when there are several groups of images, users can handle these 
independently, however this is also unintuitive, since for a user to 
handle a specific group he must click/drag the group, and this combined 
with the previous problem is a pain.
- currently with this preview to get a larger overview of the 
panorama, you must change the field of view or the projection mode.
- people with no knowledge of the types of projections, are only 
left to experiment with the projections and look at the result without 
actually having a good visualization of the distortions that are occurring


Also something I didn't like is that in many cases I couldn't spot areas 
where there was no image data, because the background was black and 
blended with parts of the image.


What I propose is the following:

First the current mode of preview will remain as it is (with some 
improvements) and will be called a '2D Projection' mode where the user 
would just use to modify the final result.


Apart from this mode I also propose two additional modes (3D panosphere, 
and combination of 3D panosphere and 2D projection):


First, some features that would be included in both 'Projection' and 
'Panosphere' mode:
   - the user could zoom in/out and image resolutions would be 
dynamically increased for more detail. (the idea on the wiki)
   - better manipulation of image groups where user could select a 
group or the whole panorama and adjust accordingly
   - adjustable and very distinctive background for both modes, to spot 
the areas without image data

   - a interleaving colorful grid will be displayed to examine distortion

1. A '3D Panosphere' mode.
   - I read the 'Next GUI' discussion, and I noticed there were some 
thoughts on this already.


   In this mode the user would basically look into a 3D sphere mapped 
with the images, with option to look at the sphere either from inside or 
outside.


The purpose of the sphere mode is that it is the basic representation of 
what the panorama actually is, and I believe it is the most intuitive 
representation.


The benefits of this mode:
   - primarily to distinguish between looking at the output and looking 
at an overview of the panorama.
   - the most intuitive and most exact preview of the panorama (in 
terms of distortions)
   - in here the 3D rotation adjustments would actually make sense and 
would be intuitive.

   - the layout submode in this mode would also make a lot more sense
   - a very intuitive and eye-candy preview for new users

Some of the features that would be included in panosphere mode:
   - a look at the panosphere either from outside or inside (all 
features available in both modes)
 * from the inside, the viewpoint would be fixed to the center 
of the sphere and adjustable would be rotation of the camera and field 
of view (zoom in/out)
 * from the outside, the viewpoint would move around a larger 
virtual sphere, and would be faced always to the center of the sphere 
(also adjustable FOV)
 - the camera adjustment would be done with the mouse or 
keyboard (for mouse drag to rotate, mouse wheel to zoom in/out)
   - a layout mode (same as it is currently) with small images and 
their connections
   - a set of 3 interactive circles drawn around the sphere, which 
could be dragged with the mouse to rotate the whole panorama or a group 
of images (as it is done in 3dsmax) (also shown in [1])

   - a possibility to choose a central point of projection on the sphere


2. Combination of 3D panosphere and 2D projection:
This mode is mostly for people to test the projections and understand 
them easily, or to work with the panosphere and see the results directly 
on the projection
   - it will contain both the panosphere and the projection, which can 
be either:

  * the panosphere and the projection in separate windows
  * the panosph

[hugin-ptx] Re: Repository

[T. Modes]

Hi Yuv,

> distribution. There are plenty of "read-only" application. A user can download
> a tarball, or fetch from SVN. This is particularly handy for source based
> distributions such as Gentoo or FreeBSD, where it is technically possible to
> fetch code from a repository rather than from a downloaded tarball. I also
> don't know how packagers for distros such as Fedora, Debian, Ubuntu and the
> dozens or hundreds of other do get their source code. Simply interrupting SVN
> "read-only" service may interrupt the flow.
>
Thanks for explanation.

But I agree on this point with Pablos opinion. Either switch to
mercurial or stay at svn. But not a twitter approach.
End of last year enblend switch also from csv to mercurial and there
were also no backup or something similiar. So all builder made the
switch. This should not be the problem.

> > > It's easy to lock SVN making it read-only and allowing commits only from
> > > an hgsvnpush cron job.

> We can continue to rely on SVN for distribution. This means that the
> developers use Hg to push around changesets. When they are ready, they push
> them to SVN. This is conceptually not different from what we had now with the
> development branches in SVN. There is just one added point when the code
> transitions into SVN.

Now I'm confused. Are we discussing two different approaches?

> It's even more complicated than this: I can pull changesets selectively. You
> need to abandon the sequential thinking in terms of revisions that is at the
> ground to SVN. The result is that we will need to manage a version number,
> something that has been done conveniently for us by SVN. SVN has not only
> disadvantages. Version numbers are needed on testing and distribution version.
> Not necessarly on developers stuff. So one solution would be to keep SVN in
> place, with a bridge from Hg. Development is in Hg (like it is currently in
> branches/) and it is pushed from Hg to SVN with the same criteria as we have
> today of merging an SVN branch into trunk. All building, testing, distribution
> works from SVN. We take bug reports against SVN. Of course we can (and should)
> not prevent power users to build from Hg, but with Hg based version people are
> as much on their own as with self-brewed / modified versions of a tarball.
>
I don't think sequential. When I have a state from which I compile
hugin I'm at a defined point. Also users and beta testers are at a
defined point. This point needs a label. That can be a branch and rev.
number in subversion or a changeset in mercurial. It does not make a
difference on which way I'm come to this point (this is how the
systems differ)
Maybe when we switch to mercurial we could use the changeset as label/
identification. Or does this make problems because it is not an
increasing number?

> Can't you have multiple repositories inside the same Hugin SDK? IIRC, when I
> was building on Windows I had the SDK (which was a heavy beast) and then
> checked different versions of the source code from SVN to different folders
> inside the SDK.
>

That's the way I work it. I have only one SDK, but can have different
branches.

> > this approach will take much space.
>
> how is it different from having multiple SVN branches build?
>

This is not different, because this depends on the build system. But
now you are thinking in mercurial and not in subversion ;-)
In SVN I can work in only one repo and don't need several repos. So we
need to consider the whole workflow.

>
> First I have a question for you. 2010.0 branch? Bruno told me he needs a
> report that it builds and works correctly on Windows to finalize release. Can
> you please give him that feedback? thanks.
>

Done.

> In terms of solution, let me understand this. We are talking 1-3 GB for a
> single Hugin build. I recall something similar from my time in Windows. That
> is the whole SDK, right? the dependecies, wxWidgets, libboost, etc.?
>

No. This is the size of the build folder for hugin only. The SDK/
dependecies takes additional more than 1 GB.

> Inside that SDK folder for each branch of Hugin you are following there are
> two folders, a source folder and a build folder. Is this correct?
>

Yes.

> With Hg the source folders should be clones, and theoretically they should be
> cheap because of hard links. However hard links on Windows have some
> requirements:
>
> 
>

When I understand this site correctly, I have to compile mercurial for
myself. Than I will also need an other compiler, because Visual C++ is
not support by mercurial, but for hugin I use it. This is much effort.
It is also barrier for new user for hugin (at least when they are on
windows). To get work you need to compile first the tool to get the
source code.
But these hard links are not the main problem.

When we switch to mercurial, we should do it now, before gsoc starts.

For me some points are clearer now.

Thomas

-- 
You received this message b

[hugin-ptx] Re: hugin-2010.0.0_rc1 released

[T. Modes]

Hi Bruno,

> Hi all, we can push this as a stable release soon if we get some
> reports that this builds and runs ok on Win/OS X/Linux.
>

Branch 2010.0, last changed rev 5059 builds and runs ok on Windows.

Thomas

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

To unsubscribe from this group, send email to 
hugin-ptx+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.

[hugin-ptx] Re: triple me

[Thomas Steiner]

> If this isn't enough help, just post another question. And of course,
> showcase your output here :)

Find a very smal version attached. Hope you enjoy it! :)
Overlapping parts were pain, but I'm happy now. Thank you hugin!
Thomas

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

To unsubscribe from this group, send email to 
hugin-ptx+unsubscribegooglegroups.com or reply to this email with the words 
"REMOVE ME" as the subject.
<>

Re: [hugin-ptx] GSOC 2010 – Accepted

[Pablo d'Angelo]

Hi Bruno,

Pablo d'Angelo schrieb:


I'm willing to be a backup admin and backup mentor. I won't be available 
at mid to end of June.


I tried to apply as a mentor for hugin at http://socghop.appspot.com, 
but I couldn't find a way to do so. Hugin is not listed when I select 
"Apply to become a mentor". Hugin is also in the list of projects that 
haven't completed their organisation profile, maybe thats the reason.


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

To unsubscribe from this group, send email to hugin-ptx+unsubscribegooglegroups.com or 
reply to this email with the words "REMOVE ME" as the subject.