[hugin-ptx] Re: morph-to-fit and Hugin with ptomorph

[kfj]

On 20 Apr., 00:34, Rogier Wolff  wrote:

> Yes, I think this is useful.

Every possibility to get away with an imperfect set of images is
welcome indeed. Never mind the theory - at times you can use a spanner
as a hammer and the result will be just as well.

> The drawback of forcing ALL points to fit is that you force all
> control points to be perfect: If there happens to be a rogue control
> point in there, this will have a huge influence on the result.

In a way, I have stopped looking at control points as individual
entities. Instead I see them like a surface attribute with a low
sampling rate compared to the pixels. Upping the cp coverage is simple
- running cpfind or apsc with the right parameters (or woa :) will
create hundreds or even thousands of cps, and just throwing away the
worse half of them is easy enough, eliminating any rogue cps.

> Also there might be "unfixable" parallax errors. One photo might have
> much more between two images.

This is the real issue. Morphing will do a great job on non-
parallactic errors which have produced distortions which aren't
covered by the the panotools optical model. Proper parallactic errors
may in some cases be made invisible by morphing, but some of them just
won't yield. There are other mechanisms to deal with them which try
and identify coherent regions and shift and deform them to match in
the result, and morphing just isn't powerful enough to do that sort of
magic.

> Consider
>
>        1 a b c d 2
>        3    e    4
>
> The 1, 2, 3 and 4 are control points. 1-3 are a vertical line. 2-4
> too. And 1-a-b-c-d-2 are evenly spaced, as are 3-e-4 on a different
> picture.

I suppose this illustrates what I mean but I'm slow to get my head
round it...

> On the other hand, you seem to be getting pretty good results in
> practise. I guess practise trumps theoretical drawbacks.. :-)

Or, as they say, the proof is the pudding

Kay

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

Re: [hugin-ptx] Re: New Leopard and newer, intel only Hugin bundle: hugin-mac-2011.5.0.5758_63173b3a4a4b

[Harry van der Wolf]

Hi George,

Op 20 april 2012 02:05 schreef George R  het volgende:

> To answer my own questions...
>
> Yes the old PTBatcher runs the old versions of the tools.  At least at
> first I thought that I could tell it was the old versions because the
> old MultiBlend ran with its RGB problem and produced some interesting
> results with spookie colours.
>
>
You are right. That's also why I started using the installer some time ago,
which I have abandoned now again for the development builds after multiple
requests.

On OS X apps are "registered" after the first moment they have run. When
having multiple Hugins and PTBatcherGuis, the one that is registered is the
one that has last run.
On an installation though the installed applications are "official"
registered, all 3 at once, which makes that installed one the officially
registered one.

I started building the installer as we had quite some changes in the
PTBatcher at that time, which also changed the "interface" (so to say),
resulting in crashes if a new Hugin called the old automatically registered
ptbatchergui.

All "helper" apps (enblend/enfuse, multiblend, cpfind, align_image_stack)
are since a year (or so) inside Hugin.app. That's also the reason why the
Hugin.app, PTBatcherGui.app and Calibrate_Lens_Gui.app have to stick
together in one folder.
However, when an old PTBatcherGui is started from another folder, it will
take the helper binaries from the old Hugin in that same folder, which
means that it will take the old binaries.

I tried to explain this when I got comments on the installer, but maybe I
wasn't clear enough.

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] Re: morph-to-fit and Hugin with ptomorph

[Jim Watters]

Bruno,
The results look great. will it be possible to implement in Nona so warping and 
morphing is done is one pass?


On 2012-04-19 6:40 PM, Bruno Postle wrote:
Panotools also uses a whole separate interface, control points are specified 
with 'c-lines', whereas panotools morphing uses 'C-lines' and these have a 
completely different format.  ptomorph just uses the existing normal 'c-lines'.
I am guessing I would not be able to feed one image into ptomorph and have it 
morph with 'c-line' control points? This is a good reason to use the 'C-line'.




These 'C-lines' seem a bit superfluous to me, though I suppose there are 
circumstances where you might want to control morphing with a reduced number 
of points - I'm not sure if there ever have been any tools that support a 
reduced set like this.
PTGui has been able to use morph-to-fit for at least 10 years when stitching 
with Panotools. It can be disabled, enabled for all control points, or enabled 
for only selected control points. I believe PTAssembler does it similarly.


I also wonder how it works when three images meet at the same place. Will it 
create vortexes? Rik Littlefields outlined the issue in an old email.

https://www.email-lists.org/pipermail/ptx/2004-May/001597.html

--
Jim Watters
http://photocreations.ca

--
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 Leopard and newer, intel only Hugin bundle: hugin-mac-2011.5.0.5758_63173b3a4a4b

[George R]

To answer my own questions...

Yes the old PTBatcher runs the old versions of the tools.  At least at
first I thought that I could tell it was the old versions because the
old MultiBlend ran with its RGB problem and produced some interesting
results with spookie colours.

To get the new PTBatcher active I launched it manually the first time
and then when Hugin started a stitch session it passed it to the new
PTBatcher.  But it seems this new version of MultiBlend still has the
RGB/BGR problem when stitching 16-bit TIFF images.  So the --bgr
option is still needed to avoid teh spookie colour transformation.

Having said that I do quite like the spookie colours.

all the best

George


On Apr 19, 9:25 pm, George R  wrote:
> Harry,
> Thanks for this.
>
> By way of a first test I have just launched a test stitch of a recent
> project.
>
> I noticed that it invoked the old version of the PTBatcher.
>
> Is that likely to be a problem?  My intuitions tell me it will ... but
> what do they know?
>
> Any idea what I need to do to make the new version invoke the new
> PTBatcher?
>
> all the best
>
> George
>
> On Apr 19, 5:20 pm, Harry van der Wolf  wrote:
>
>
>
>
>
>
>
> > Hi mac users,
>
> > I built a new bundle. It includes lensfun. It's an intel only 32bit/64bit
> > bundle for Leopard and newer.
> > It's without python, that's (again) the next challenge.
>
> > Changelog:
> > = This OSX build
> > - Only built for Intel (i386/x86_64). No longer support for PPC (G4/G5).
> > - Runs on Leopard (10.5) and newer. No more Tiger (10.4.x) support.
> > - enblend/enfuse are openMP enabled and should run on Lion.
> > - multiblend 0.31beta added. Also Openmp enabled.
> > - the 64bit part (as they are universal i386/x86_64) of the panotools
> > binaries (PTBlender, PTOptimizer, etc.) are also openmp enabled.
> > - Many library updates
>
> > = Hugin:
> > - Addition of lensfun functionality by Thomas Modes
> > - multiple bugfixes by Thomas
> > - some updated translations.
>
> > 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
>
> > --
> > Hugin development bundles for Mac OS
> > X
> > ImageFuser for Mac OS X 
> > KImageFuser for
> > Linux

-- 
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] morph-to-fit and Hugin with ptomorph

[Rogier Wolff]

On Thu, Apr 19, 2012 at 09:36:18PM +0100, Bruno Postle wrote:
> doesn't work on Windows.  I'd like to hear some feedback, do you
> think something like this would be useful in Hugin?  Is there a
> better approach than forcing _all_ the control points to fit?

Yes, I think this is useful. 

The drawback of forcing ALL points to fit is that you force all
control points to be perfect: If there happens to be a rogue control
point in there, this will have a huge influence on the result.

Also there might be "unfixable" parallax errors. One photo might have
much more between two images. 

Consider

   1 a b c d 2
   3e4

The 1, 2, 3 and 4 are control points. 1-3 are a vertical line. 2-4
too. And 1-a-b-c-d-2 are evenly spaced, as are 3-e-4 on a different
picture.

On the other hand, you seem to be getting pretty good results in
practise. I guess practise trumps theoretical drawbacks.. :-)

Roger. 

-- 
** r.e.wo...@bitwizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 **
**Delftechpark 26 2628 XH  Delft, The Netherlands. KVK: 27239233**
*-- BitWizard writes Linux device drivers for any device you may have! --*
The plan was simple, like my brother-in-law Phil. But unlike
Phil, this plan just might work.

-- 
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: morph-to-fit and Hugin with ptomorph

[Bruno Postle]

On Thu 19-Apr-2012 at 23:13 +0200, Erik Krause wrote:

Am 19.04.2012 22:36, schrieb Bruno Postle:

I recently added a new tool called 'ptomorph' to Panotools::Script
that helps with stitching Hugin panoramas with parallax errors.  To
give an idea of what it does, here is a 'before and after' example
of a handheld panorama with quite a lot of stitching errors:
http://www.flickr.com/photos/36383814@N00/6948262808


Very interesting. What is the difference to the old panotools Morph-to-fit?


The panotools morph-to-fit isn't available in Hugin/nona...

Panotools also uses a not-very-nice distortion where it splits the 
image up into triangles and performs an affine transformation on 
each triangle separately, so you get steps between adjacent 
triangles (I believe, I haven't looked at it for ten years or 
something).  The ImageMagick morph is a 'rubber-sheet' distortion, 
so it is much smoother.


The reason morph-to-fit was never implemented in Hugin is that there 
were obviously better ways of doing it.


Panotools also uses a whole separate interface, control points are 
specified with 'c-lines', whereas panotools morphing uses 'C-lines' 
and these have a completely different format.  ptomorph just uses 
the existing normal 'c-lines'.


These 'C-lines' seem a bit superfluous to me, though I suppose there 
are circumstances where you might want to control morphing with a 
reduced number of points - I'm not sure if there ever have been any 
tools that support a reduced set like this.


--
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: morph-to-fit and Hugin with ptomorph

[Erik Krause]

Am 19.04.2012 22:36, schrieb Bruno Postle:

I recently added a new tool called 'ptomorph' to Panotools::Script
that helps with stitching Hugin panoramas with parallax errors.  To
give an idea of what it does, here is a 'before and after' example
of a handheld panorama with quite a lot of stitching errors:
http://www.flickr.com/photos/36383814@N00/6948262808


Very interesting. What is the difference to the old panotools Morph-to-fit?

--
Erik Krause
http://www.erik-krause.de

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

[hugin-ptx] morph-to-fit and Hugin with ptomorph

[Bruno Postle]

I recently added a new tool called 'ptomorph' to Panotools::Script 
that helps with stitching Hugin panoramas with parallax errors.  To 
give an idea of what it does, here is a 'before and after' example 
of a handheld panorama with quite a lot of stitching errors: 
http://www.flickr.com/photos/36383814@N00/6948262808


What it does is read all the control points in an existing PTO 
project, and use these to generate a 'morph' distortion for each 
photo that results in all the control points lining up exactly.


The morphing itself is done with ImageMagick.

I'd describe this as experimental, it isn't going to work with HDR, 
may do strange things with masks and circular cropping, and probably 
doesn't work on Windows.  I'd like to hear some feedback, do you 
think something like this would be useful in Hugin?  Is there a 
better approach than forcing _all_ the control points to fit?


To try it you need the current Panotools::Script from SVN, something 
like this:


  svn co 
https://panotools.svn.sourceforge.net/svnroot/panotools/trunk/Panotools-Script

..or wait for the Panotools::Script 0.27 release (not sure when that 
will be).


--
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: New Leopard and newer, intel only Hugin bundle: hugin-mac-2011.5.0.5758_63173b3a4a4b

[George R]

Harry,
Thanks for this.

By way of a first test I have just launched a test stitch of a recent
project.

I noticed that it invoked the old version of the PTBatcher.

Is that likely to be a problem?  My intuitions tell me it will ... but
what do they know?

Any idea what I need to do to make the new version invoke the new
PTBatcher?

all the best

George


On Apr 19, 5:20 pm, Harry van der Wolf  wrote:
> Hi mac users,
>
> I built a new bundle. It includes lensfun. It's an intel only 32bit/64bit
> bundle for Leopard and newer.
> It's without python, that's (again) the next challenge.
>
> Changelog:
> = This OSX build
> - Only built for Intel (i386/x86_64). No longer support for PPC (G4/G5).
> - Runs on Leopard (10.5) and newer. No more Tiger (10.4.x) support.
> - enblend/enfuse are openMP enabled and should run on Lion.
> - multiblend 0.31beta added. Also Openmp enabled.
> - the 64bit part (as they are universal i386/x86_64) of the panotools
> binaries (PTBlender, PTOptimizer, etc.) are also openmp enabled.
> - Many library updates
>
> = Hugin:
> - Addition of lensfun functionality by Thomas Modes
> - multiple bugfixes by Thomas
> - some updated translations.
>
> 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
>
> --
> Hugin development bundles for Mac OS
> X
> ImageFuser for Mac OS X 
> KImageFuser for
> Linux

-- 
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] [OSX] New Leopard and newer, intel only Hugin bundle: hugin-mac-2011.5.0.5758_63173b3a4a4b

[Harry van der Wolf]

Hi mac users,

I built a new bundle. It includes lensfun. It's an intel only 32bit/64bit
bundle for Leopard and newer.
It's without python, that's (again) the next challenge.

Changelog:
= This OSX build
- Only built for Intel (i386/x86_64). No longer support for PPC (G4/G5).
- Runs on Leopard (10.5) and newer. No more Tiger (10.4.x) support.
- enblend/enfuse are openMP enabled and should run on Lion.
- multiblend 0.31beta added. Also Openmp enabled.
- the 64bit part (as they are universal i386/x86_64) of the panotools
binaries (PTBlender, PTOptimizer, etc.) are also openmp enabled.
- Many library updates

= Hugin:
- Addition of lensfun functionality by Thomas Modes
- multiple bugfixes by Thomas
- some updated translations.


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

-- 
Hugin development bundles for Mac OS
X
ImageFuser for Mac OS X 
KImageFuser for
Linux

-- 
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: Samyang 8mm Lens settings

[Carl von Einem]

Thanks for the images, I'll have a look at them later. Maybe I can come 
up with something that illustrates what also Kay says about using the 
right projection.


Cheers,
Carl

Carlos Eduardo G. Carvalho (Cartola) schrieb am 19.04.12 16:31:

Hi,

I also thought Opteka and Samyang were the same or at least very
similar, I have heard that before. As you asked for some samples, I have
some here if you still want to see:

http://cartola.org/arquivos/Sample-6.5mm.tgz

I have calibrated the lens not only using the tutorial at hugin site but
also saving the lens after a good stitch, but always have to do similar
optimization that finishes the necessary lens distortions to make the
lines join correctly. That is why I think it doesn't matter very much if
I define the lens initially as fish eye or stereographic.

Good exchange of information till now. :)


--
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: Samyang 8mm Lens settings

[Carlos Eduardo G. Carvalho (Cartola)]

Hi,

I also thought Opteka and Samyang were the same or at least very similar, I
have heard that before. As you asked for some samples, I have some here if
you still want to see:

http://cartola.org/arquivos/Sample-6.5mm.tgz

I have calibrated the lens not only using the tutorial at hugin site but
also saving the lens after a good stitch, but always have to do similar
optimization that finishes the necessary lens distortions to make the lines
join correctly. That is why I think it doesn't matter very much if I define
the lens initially as fish eye or stereographic.

Good exchange of information till now. :)

Tks,

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



2012/4/19 Carl von Einem 

> Thanks for that hint! A second look at  SAMYANG/Early%20test%20report.**html>
> shows me that Michel Thoby actually pointed to the fact that both the
> 'Samyang 8mm 1:3.5 FISH-EYE CS' and the 'Opteka 6.5mm 1:3.5 FISH-EYE CS'
> are identical products.
>
> Though there is a difference: the Opteka lens ( **aspx >) comes with a detachable lens
> hood (sun shield) while the Samyang has a fixed one:
> 
> >
>  65_II_ALT1.jpg
> >
>
> I really love these marketing heroes... did you know that Mercedes will
> sell the Renault Kangoo soon, just with a big star added?
>
> Carl
>
> Emad ud din Bhatt schrieb am 19.04.12 14:25:
>
>> Thanks all for your support.
>>
>> I feel Optika and Samyang both are same with different brand names.
>> These lenses are sold with different bran names.
>>
>> I will try to create equirects this weekend
>>
>> On Thu, Apr 19, 2012 at 12:58 PM, kfj wrote:
>>
>>I use the Samyang a lot on my 450D. The closest projection type is
>>stereographic, and if you use that, the lens correction coefficients
>>you need are smallest. Here's a values from a typical lens.ini file
>>for it:
>>
>>[Lens]
>>image_width=4272
>>image_height=2848
>>type=10
>>hfov=138.025
>>crop=1.6
>>a=0.00716497
>>b=-0.0360894
>>
>>These settings probably won't be correct for you, as you use a
>>different body, but the lens correction coefficientsshould be similar
>>and the projection type is the same. But you can take it from there.
>>
>>Also keep in mind that every body and every lens, even within a
>>series, is different. You have to calibrate your own equipment if you
>>want really good results.
>>
>
> --
> 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+unsubscribe@**
> googlegroups.com 
> For more options, visit this group at http://groups.google.com/**
> group/hugin-ptx 
>

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

Re: [hugin-ptx] Re: Samyang 8mm Lens settings

[Carl von Einem]

Thanks for that hint! A second look at 
 shows 
me that Michel Thoby actually pointed to the fact that both the 'Samyang 
8mm 1:3.5 FISH-EYE CS' and the 'Opteka 6.5mm 1:3.5 FISH-EYE CS' are 
identical products.


Though there is a difference: the Opteka lens 
() comes with a detachable lens hood 
(sun shield) while the Samyang has a fixed one:




I really love these marketing heroes... did you know that Mercedes will 
sell the Renault Kangoo soon, just with a big star added?


Carl

Emad ud din Bhatt schrieb am 19.04.12 14:25:

Thanks all for your support.

I feel Optika and Samyang both are same with different brand names.
These lenses are sold with different bran names.

I will try to create equirects this weekend

On Thu, Apr 19, 2012 at 12:58 PM, kfj wrote:

I use the Samyang a lot on my 450D. The closest projection type is
stereographic, and if you use that, the lens correction coefficients
you need are smallest. Here's a values from a typical lens.ini file
for it:

[Lens]
image_width=4272
image_height=2848
type=10
hfov=138.025
crop=1.6
a=0.00716497
b=-0.0360894

These settings probably won't be correct for you, as you use a
different body, but the lens correction coefficientsshould be similar
and the projection type is the same. But you can take it from there.

Also keep in mind that every body and every lens, even within a
series, is different. You have to calibrate your own equipment if you
want really good results.


--
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: Samyang 8mm Lens settings

[Emad ud din Bhatt]

Thanks all for your support.

I feel Optika and Samyang both are same with different brand names. These
lenses are sold with different bran names.

I will try to create equirects this weekend

Thanks



On Thu, Apr 19, 2012 at 12:58 PM, kfj <_...@yahoo.com> wrote:

> On 18 Apr., 14:38, Emad ud din Bhatt  wrote:
> > I have Canon 40d which is a cropped sensor.
> > My Samyang is not shaved as I have cropped sensor DSLR.
> >
> > I create 360x180 panos. I have simply put 8mm in lens type and hugin
> > automatically calculates values. But the final image has strange
> distorted
> > look.
>
> I use the Samyang a lot on my 450D. The closest projection type is
> stereographic, and if you use that, the lens correction coefficients
> you need are smallest. Here's a values from a typical lens.ini file
> for it:
>
> [Lens]
> image_width=4272
> image_height=2848
> type=10
> hfov=138.025
> crop=1.6
> a=0.00716497
> b=-0.0360894
>
> These settings probably won't be correct for you, as you use a
> different body, but the lens correction coefficientsshould be similar
> and the projection type is the same. But you can take it from there.
>
> Also keep in mind that every body and every lens, even within a
> series, is different. You have to calibrate your own equipment if you
> want really good results.
>
> 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
>



-- 


*Emaad*
www.flickr.com/emaad

-- 
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: Dropping support for Hugin on Mac OS X 10.4 (Tiger) and PCC hardware

[kfj]

A few remarks on the python interface and hugin on non-***ix
platforms:

To run a python-enabled hugin, swig is not needed. Swig is only needed
to create the python module which gives python access to hugin's
functionality. The python module is simply a shared library which can
be distributed as-is.

To run python-enabled hugin on a Linux machine, AFAIK (Linux machines
always have python anyway) python isn't necessary. I've written the
python interface so that it is only activated and initialized when the
first call to it happens. So if python isn't there, hugin will run
just fine, but trying to use python plugins will simply not work. On
MacOS this should be the same. On Windows, the story is probably
different:

AFAIK, on Windows, all of hugin is linked statically. So I suppose the
idea is that the shared library which constitutes the python module
also has to be statically linked-in somehow. This is wrong. The python
module is loaded by python when the need arises (like, a plugin is
called). It may be though that trying to link everything statically
also results in the python interpreter being statically linked to
hugin (I'm not sure if or how this is done). I see no reason why this
should be done, but on the other hand it's no big deal, since python
is made to allow for such behaviour as well.

I think the fixation on statically linking hugin with everything and
using MSVC for the process is part of the problem. If you look at
hugin as a ***ix-born program (is it?), MSVC is alien territory. Using
MinGW would be much more appropriate, and then, along with using
MinGW, all the libraries could be linked dynamically, just as on
***ix. The static linking comes, I think, from a specific notion:

'DLL hell', the problem that arisies from the fact that on Windows
there seems to be confusion about where shared libraries should live,
and from the fact that Windows doesn't have package management. I've
heard that these issues have been adressed to some extent and the
situation is much better now than it was a few years back, but the old
fears still persist.

So static linking and using MSVC becam the norm. The code is full of
ugly conditional compiles and make directives which reflect the
wrestling with WIndows'/MSVC's alien nature. From my (limited)
experience with the code I would say that they often are expressed
along the lines of '#ifdef Windows', rather than saying that they are
for the specific 'statically linked+MSVC' combination. So if anyone
tried to do the sane thing and use MinGW to create a dynamically-
linked hugin using precisely the same tools which are used on ***ix,
they would still be building for a Windows system, '#ifdef Windows'
would be true, and the conditionals meant for statically-linked+MSVC
hugin would fire, bending the code so that compiling a dynamically-
linked+MinGW hugin is bound to fail.

What to do? Someone with intimate knowledge of the code would have to
go through the whole thing with a fine tooth comb to set things right.
I doubt there is anyone willing to do that, after all the statically-
linked+MSVC product works.

I wonder: is there anyone (Thomas?) who has compiled an hsi module on
Windows and would be willing to share it? Hsi is useful in itself, as
it allows most of hugin's backend functionality to be used from
python. The first step would be to try if and how this module works
(or fails) on other Windows machines and what is really required to
get it to run there. Then the next step would be to try out a python-
enabled hugin to see if it can run on a system without python. I will
not compile hugin on Windows myself, but I'll gladly test someone
else's hsi module and python-enabled hugin on my Windows systems if
this can help advance the cause of my brainchild. I can't help with
MacOS, though.

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

[Bart van Andel]

Hi David,

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

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

--
Bart


On Tuesday, March 27, 2012 1:01:56 AM UTC+2, Monkey wrote:
>
> Hi all, 
>
> Previous discussion: 
> http://groups.google.com/group/hugin-ptx/browse_thread/thread/b08211b2659a7eab
>  
>
> There's a new beta (I say beta; I probably really mean alpha) of 
> multiblend available at http://horman.net/multiblend 
>
> I've implemented a feature I'm calling "pseudowrapping" to blend 
> around the left/right borders for 360 degree panoramas, a much- 
> requested feature. 
>
> There are no command-line switches to access this; pseudowrapping is 
> enabled any time multiblend is run with only a single uncropped TIFF 
> (such as that already created by a normal multiblend run) as its 
> input. 
>
> This is really only a stepping-stone to a properly integrated wrapping 
> solution - it can't be called straight out of Hugin, for example, 
> because it only wraps a previously blended panorama. 
>
> Questions, comments, and complaints please :) 
>
> David

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

[hugin-ptx] Re: Samyang 8mm Lens settings

[kfj]

On 18 Apr., 14:38, Emad ud din Bhatt  wrote:
> I have Canon 40d which is a cropped sensor.
> My Samyang is not shaved as I have cropped sensor DSLR.
>
> I create 360x180 panos. I have simply put 8mm in lens type and hugin
> automatically calculates values. But the final image has strange distorted
> look.

I use the Samyang a lot on my 450D. The closest projection type is
stereographic, and if you use that, the lens correction coefficients
you need are smallest. Here's a values from a typical lens.ini file
for it:

[Lens]
image_width=4272
image_height=2848
type=10
hfov=138.025
crop=1.6
a=0.00716497
b=-0.0360894

These settings probably won't be correct for you, as you use a
different body, but the lens correction coefficientsshould be similar
and the projection type is the same. But you can take it from there.

Also keep in mind that every body and every lens, even within a
series, is different. You have to calibrate your own equipment if you
want really good results.

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