Small errors, Projection formula and Preview

[Giancarlo Todone]

It's something like 6 years I'm trying harder and harder to get the best results possible with panorama photography; by now I achieved significant improvements both in experience and equipment: thanks to a robotic pano head, now taking outside panorama is easy enough for me. 

However i'm rather disappointed that despite of all, when doing interiors, my panoramas are still affected by small errors. 

I did calibration of my lens, i carefully placed nodal point, i personally wrote the program that moves my robotic head, but i still have to optimize because the head has an angle uncertainty of something around 0.1-0.2 deg.

When i use alignment through optimization of CPs, no matter how many point i have, there are lots of small errors (example with ~9000 http://www.stareat.it/viewers/pan0.swf?panoSrc=http://www.stareat.it/img/tropicalZooPano1.jpg&tesselation=100 )

I came to the conclusion that only two ways to overcome this, are

1. to buy a more precise robotic head and avoid alignment through optimization of CPs at all
   
2. to do small adjustment to alignment manually, somehow
   

Given that i would happily avoid spending lots of money for a new head at the moment, I'm pretty surprised that Hugin is so much behind if we speak of preview/manual alignment.

Now: I'm a professional developer and I have a couple ideas on how to use GPU for a nearly perfect realtime preview allowing us to do small adjustments by hand, but i'd need the exact same formula hugin uses to obtain consistent results.

I now I could dig into Hugin sources (and i surely will) but i was wondering if someone more used to it could just point me/lay it down simple, to kickstart me.

E.g. : given a unit sphere and equirectangular projection, A and B being the yaw and pitch angle of a generic point Ps on its surface, Ya and Pi being yaw and pitch of center of an already corrected and placed image, X and Y being the generic point Pi on the image, what is the exact function that maps A, B to X, Y (taking into account all the other parameters i didn't mention, too...). 

I mean: I'm not even sure Hugin does it always passing by equirectangular projection, but you got the point.

In the meanwhile, if someone has other tips for me to better align my images, advices are more than welcome...

Thanks in advance.

[Torsten Bronger]

Hall�chen!

Giancarlo Todone writes:

> It's something like 6 years I'm trying harder and harder to get
> the best results possible with panorama photography; by now I
> achieved significant improvements both in experience and
> equipment: thanks to a robotic pano head, now taking outside
> panorama is easy enough for me. However i'm rather disappointed

> that despite of all, when doing interiors, *my panoramas are still
> affected by small errors*.

I've also spent a lot of time for calibrating my equipment and
finally gave up. I came to the conclusion that remaining stitching
must be eliminated in Gimp.

There are two sources of error that I cannot eliminate fully:

1. The distortion of the lens is modelled with a polynomial, which
always has a deviation from the actual complex distortion field
of the lens.

2. Fisheyes don't have a No Parallax Point, so you have no parallax
only on a circle in your image.

Both errors can be minimized by using a circular crop and
calibrating for this circle, but since the rim of one picture is
inside the rim of another (overlapping pictures after all) this can
never be perfect.

And, point (2) gets worse when doing interiors. It can be a couple
of mm, especially with large overlaps, so noticable mismatches in
straight lines. Maybe one could try a rectilinear lens, but I'm not
willing to do that. I just live with the mismatches.

Tsch�,
Torsten.

--
Torsten Bronger Jabber ID: torsten...@jabber.rwth-aachen.de
or http://bronger-jmp.appspot.com

[Giancarlo Todone]

Hi, and thank you for your reply: I'm afraid I have to say I already use rectilinear pictures... the example i posted before uses 32 images (actually 96 images, 3 exposures for each position) 3x10+zenith+nadir, and they are near perfect

Manual placement at this point is not a deal breaker for me: it's just that i would like to reflect changes in the positions of images into the Hugin project, or the modifications to my workflow would be too heavy: that's why simply aligning in GIMP is not ok for me :(

On Wednesday, April 24, 2013 10:09:19 AM UTC+2, Torsten Bronger wrote:

Hall�chen!

Tsch�,

[Torsten Bronger]

Hall�chen!

Giancarlo Todone writes:

> [...]

>
> Manual placement at this point is not a deal breaker for me: it's
> just that i would like to reflect changes in the positions of
> images into the Hugin project, or the modifications to my workflow
> would be too heavy: that's why simply aligning in GIMP is not ok
> for me :(

I'm afraid I don't fully understand what you need. You can manually
move single images relatively to others with the mouse or by
entering values. Is this what you are looking for?

Tsch�,

[Giancarlo Todone]

Yes, but I would like edititng values in terms of precise angles in Hugin, not pixel displacement in GIMP; 

too bad the preview in Hugin is pretty much useless (no zoom, no quality) when it comes to fixing small details.

In my first post I was asking for either advices on how to better use alignment tools we already have, or a pointer on where to start implementing better preview.

On Wednesday, April 24, 2013 10:38:17 AM UTC+2, Torsten Bronger wrote:

Hall�chen!

Giancarlo Todone writes:

> [...]
>
> Manual placement at this point is not a deal breaker for me: it's
> just that i would like to reflect changes in the positions of
> images into the Hugin project, or the modifications to my workflow
> would be too heavy: that's why simply aligning in GIMP is not ok
> for me :(

I'm afraid I don't fully understand what you need.  You can manually
move single images relatively to others with the mouse or by
entering values.  Is this what you are looking for?

Tsch�,

[Torsten Bronger]

Hall�chen!

Giancarlo Todone writes:

> Yes, but I would like edititng values in terms of precise angles
> in Hugin, not pixel displacement in GIMP;

I suggested Gimp not for alignment, only for final retouche (like
local blurring).

> too bad the preview in Hugin is pretty much useless (no zoom, no
> quality) when it comes to fixing small details.

Well, the quality really is limited -- but you can zoom in. I
personally find resolution sufficient for fine tuning.


Have you tried to filter control points? In my experience, nothing
can beat control points when it comes to the mere alignment.
Fitting everything (ie including distortion + FOV) can be difficult,
but if you already have a fully calibrated lens and only need yaw,
pitch, and roll, CPs are the way to go.

You can also set them manually. If the lens is perfectly
calibrated, two CPs per picture are enough.

As far as the imperfectness of your pano motor is concerned: Is its
misalignment always the same or does it jitter around a mean value?

> In my first post I was asking for either advices on how to better
> use alignment tools we already have, or a pointer on where to
> start implementing better preview.

I must admit that I did not understand this paragraph in your first
post. Probably somebody else can help you with this.

Tsch�,

[Giancarlo Todone]

Wait... I could just be missing something obvious, or we're not speaking about the same program. 

As stated here there's no zoom in fast preview: only zoom I could find is on overview. Both of them (preview/overview) are far from being suitable for a manual precision alignment since (as stated in the linked discussion)

• the images are downsized to very poor resolution 
• distorsion computations are just a coarse approximation of the real stuff and using finer grained texture could do nothing but make it more obvious.

How on earth could you use this to align something as little as 0,01 deg offset??

[Bruno Postle]

Generally we don't use the preview to do fine-alignment of photos because the control point system is far more accurate. Also all you can do is drag the photos around in the preview, whereas misalignment errors can be because of bad lens parameters - I don't see how it could be practical to adjust lens parameters interactively, this is why we use machine optimisation.

Having said that, you should be getting much better results with Hugin than this, the errors are equivalent to 1-2cm camera misalignment. You said you are using a robot head, are you relying on the position data from the robot? or are you creating a full set of control points and optimising positions and lens parameters?

( At some point we would like to add some morph-to-fit functionality in Hugin to correct minor errors, see the prototype here: https://groups.google.com/forum/#!topic/hugin-ptx/UripOuuYXCQ )

--

Bruno

[Giancarlo Todone]

Generally we don't use the preview to do fine-alignment of photos because the control point system is far more accurate. Also all you can do is drag the photos around in the preview, whereas misalignment errors can be because of bad lens parameters - I don't see how it could be practical to adjust lens parameters interactively, this is why we use machine optimisation.

Well, I hoped to calibrate my lens once and for all, and then use the obtained values in subsequent panoramas. Since the robot scans the panorama in rows, I can be pretty sure that regardless of angle errors, all picture are the exact same pitch (since vertical motor doesn't move at all during rows scan) and so i wanted to manually move just yaw and give everything else for granted.

 

Having said that, you should be getting much better results with Hugin than this

 

Yes, I'm telling myself this all the time: it's just not possible that with all this effort and equipment I'm still unable to obtain decent results.

 

the errors are equivalent to 1-2cm camera misalignment. You said you are using a robot head, are you relying on the position data from the robot? or are you creating a full set of control points and optimising positions and lens parameters?

 

At first I bought the robot to replace a manual rig i built myself, hoping to be able to rely on position; this is simply not working because this robot has the already mentioned uncertainty on angles declared (and verified by myself) around 0.2 deg. So usually my workflow is: use already found lens parameters, manually edit PTO file to link pitch of all images on the same row, then optimizing pitch, yaw, roll.

 

( At some point we would like to add some morph-to-fit functionality in Hugin to correct minor errors, see the prototype here: https://groups.google.com/forum/#!topic/hugin-ptx/UripOuuYXCQ )

Yes, i found that some time ago... don't think it's helping here, since this panorama should be almost perfect anyway. I've a steady tripod, and i carefully place nodal point before every session.

Thanks for your help.

[Bruno Postle]

On Wed 24-Apr-2013 at 09:35 -0700, Giancarlo Todone wrote:
>
> Well, I hoped to calibrate my lens once and for all, and then use
> the obtained values in subsequent panoramas. Since the robot scans
> the panorama in rows, I can be pretty sure that regardless of
> angle errors, all picture are the exact same pitch (since vertical
> motor doesn't move at all during rows scan) and so i wanted to
> manually move just yaw and give everything else for granted.

> So usually my workflow is: use already found lens parameters,
> manually edit PTO file to link pitch of all images on the same
> row, then optimizing pitch, yaw, roll.

There could be all sorts of reasons why the pitch may not actually
be consistent, so you need to rule it out as a cause by optimising
pitch for every photo in your project as a test.

Also although the lens distortion parameters should be consistent,
the angle of view can change significantly, e.g. different focus
distances can alter the angle of view, so for a spherical panorama
you really need to _always_ optimise angle of view (v).

(angle of view isn't anything like as critical for partial
panoramas)

So I suggest you try a series of tests with different optimisation
settings:

- roll, yaw and view
- roll, pitch and yaw
- roll, pitch, yaw and view
- everything

--
Bruno

[Torsten Bronger]

Hall�chen!

Giancarlo Todone writes:

> [...]

>
> How on earth could you use this to align something as little as
> 0,01 deg offset??

Well, 0.01� make 300 micrometre offset in a distance of 3 metre but
you have much more than that. Let me put it this way: Misalignments
that are large enough that the enblend process cannot make them
invisible, I can also see in fast preview.

But as I already pointed out, I would never align this way. CP are
the proper way to go. Correct CPs have unbeatable accuracy.

[Giancarlo Todone]

Well, 0.01� make 300 micrometre offset in a distance of 3 metre but

you have much more than that.  

ok. maybe i was exagerating a little bit, but a 60deg fov  divided for 4000pixels makes 0,015deg for a pixel-perfect match, so it's not exagerated to say e.g. 0,03deg for a goodresolution panorama. This said, I believe all of you when you say this should be done with CPs (and so i'm trying to get it working) but i still believe that a better preview wouldn't do anything but good.

@Bruno: i think in these years i tried almost everything, but I'll keep trying, thanks for your help and patience. Eventually I could post some example of what i cannot get to work if you don't mind...

[Felix Hagemann]

On 24 April 2013 21:19, Bruno Postle <br...@postle.net> wrote:
> So I suggest you try a series of tests with different optimisation settings:
>
> - roll, yaw and view
> - roll, pitch and yaw
> - roll, pitch, yaw and view
> - everything

Let me add one more thing here: In my experience you need to add d and
e as parameters to optimize even if you leave the others (like v and
a-c) to the lens calibration. Those vary each time you take the lens
off and mount it again.

Also the posted example to me looks like there isn't a sufficient
spread of control points along the whole overlap between two images
which causes the stitching errors. But then I'm used to ultra wide
angle or fisheye lenses.

Felix

[Giancarlo Todone]

Ok, I'm posting the pictures i used to create my first example; they are 96 pictures organized this way:

3 shots fore each position (normal, stepped down, stepped up)

32 positions: assuming 0deg is pointing to horizon

10 are pointing down -40deg

10 are at 0deg and 

10 are pointing upward +45deg

In each row shots are 0, 36, 72, ... deg longitudinally

last 2 positions are zenit and nadir (last one is not to rely on, since it was taken handheld with no head, no tripod)

Here it is the RAR file (~400Mb) with JPGs straight from the camera (it wasn't suitable to provide RAWs...) so they are already TCA and distorsion corrected to a degree... 

If anyone is interested in trying out and demonstrate that my problems are due to my incapacity with Hugin and not to my hardware, well, that would be great. ;)

[Giancarlo Todone]

Sorry... forgot the link XD

http://www.stareat.it/files/pano_TZTest.rar

[kfj]

If you're on a Linux or windows system, you can try and use the woa plugin on the panorama once you've got it roughly aligned. This can add many more good quality CPs which can help you to get the parameters optimized. You can also play with cpfind's parameters to get more and better CPs; the defaults are quite good but you may be able to up your success by using, e.g. --fullscale and by playing with the various sievesizes. In my experience, lots of control points will help more than painstaking calibration. Calibration is good, but it only gets you so far. The last bit is 'cheating', and you can cheat best with lots of CPs. A good cheat is to decouple the hfovs of the images, but you can only safely do that if you have enough CPs, otherwise the whole thing can fall apart. And if the cheating with CPs still isn't getting you there, you can try and morph the images to fit. I think it's in the latest edition of the panotols-script collection.

When it comes to the abovementioned problem of the lens distortion not being modeled precisely by a polynomial, you can try and help the process by distributing the images so that the optical axes of your images follow a regular pattern, so that all their respective distances to their neighbours are as near to equal as possible. With a wide-angle lens you might follow the tips of an icosahedron, and if you tesselate (is that the term? like, replace all spherical triangles by n (4, 9, 16...) spherical triangles which are parametrized to have as similar characteristics as possible) a spherical icosahedron, you get very regular patterns as well. I'm not sure if your robotic head does it like that; it might just have settings like how many shots it does for each row and that might not result in a regular overlap pattern, if you don't program it very carefully.

Kay

[Giancarlo Todone]

Thank you kfj, your advices are very interesting and I'm experimenting a lot that way. Speaking of that... when I try to execute woa plugin, it immediately returns with mesage "script returned -1"... any clue?

[kfj]

On Saturday, May 4, 2013 10:08:41 PM UTC+2, Giancarlo Todone wrote:

Thank you kfj,

your'e welcome :)
 

your advices are very interesting and I'm experimenting a lot that way. Speaking of that... when I try to execute woa plugin, it immediately returns with mesage "script returned -1"... any clue?

-1 means that the call to the plugin interface has failed. Can you call any of the other plugins? And can you run woa from the command line? What system and what version of hugin are you using?

Kay

[Giancarlo Todone]

-1 means that the call to the plugin interface has failed. Can you call any of the other plugins? And can you run woa from the command line? What system and what version of hugin are you using?

Right now i'm on Windows 8 x64 but I'm using Hugin 2012.0.0 x86 because x64 version gives problems on UI (some missing controls). I tried 2012 and 2013 beta  x86/x64 normal/hsi with same results: all of the scripts return -1.

I tried calling "python woa.py" in the scripts folder: it complains about lack of hsi include. Didn't experiment further (but will with my Ubuntu10.04 install)

[kfj]

Well, lack of hsi means that you don't have a hugin built with python support. If you build yourself, you can get the python interface by building with these cmake flags

-DBUILD_HSI:BOOL=ON -DSWIG_EXECUTABLE=/usr/bin/swig2.0

It should at any rate be much easier getting it to run on
Linux. Just follow the wiki:

http://wiki.panotools.org/Hugin_Compiling_Ubuntu

Once you have built hugin with the python interface, you can
test easily whether you've succeeded by just opening a python
session and typing

import hsi

at the python prompt. If that succeeds, you should be fine.
Why the Windows build you have allows you to call a plugin when
the python interface isn't there, I don't know.

Kay

 

[Giancarlo Todone]

On Wednesday, May 8, 2013 9:18:32 PM UTC+2, kfj wrote:

On Monday, May 6, 2013 9:55:41 PM UTC+2, Giancarlo Todone wrote:

-1 means that the call to the plugin interface has failed. Can you call any of the other plugins? And can you run woa from the command line? What system and what version of hugin are you using?

Right now i'm on Windows 8 x64 but I'm using Hugin 2012.0.0 x86 because x64 version gives problems on UI (some missing controls). I tried 2012 and 2013 beta  x86/x64 normal/hsi with same results: all of the scripts return -1.

I tried calling "python woa.py" in the scripts folder: it complains about lack of hsi include. Didn't experiment further (but will with my Ubuntu10.04 install)

Well, lack of hsi means that you don't have a hugin built with python support. If you build yourself, you can get the python interface by building with these cmake flags

Well, I'm a c/c++/c#/java developer but i never even touched python with a stick so my best guess is that i failed something while trying to invoke woa from shell (e.g. parameters/working folder). Hugin is the official 2012 win32 build with python support (didn't compile it myself). 

Python 3.2 is correctly installed (Hugin 2012 32 bit with python support used to crash on startup without python 3.2 installation; now it just fail on action execution as previously described)

 

[kfj]

On Thursday, May 9, 2013 12:13:03 PM UTC+2, smib wrote:

Hi  Kay

 

I've noticed the same issue with my win 32 bit build using MSVC2010 from last weekend. Woa works fine from the command line and from an earlier build (built with MSVC2008). The 'limit to 5 points' script works from my recent build but the woa script returns -1 after calling Nona and then CPfind. From what I can see woa has not changed so i guess that there must be a recent code change somewhere that is conflicting

 
Interesting. The next thing in line from calling the cpg is calling tiffdump, in order to get the information about the cropping in the cropped TIFF which nona produces - this might be where things go awry. Would you be so kind and run woa from the command line with --verbose to make it more chatty, capture all console output and post that? It might give me more of a clue where things go wrong, particularly if the problem raises an exception and I can see from the stack trace where it tripped.

Of course there's always the possibility of an incompatible change in hugin's API... I don't think anyone cares overly much about breaking the very few extant python plugins. The python interface itself adapts to every new version of the API automatically, but when an 'old' plugin tries to call what it could safely call when it was written, and what is called has changed in the meantime, it may well fail. That's why Yuv coded an API version check into the system, which resulted in all plugins being disabled in a previous release, because noone had minded the mechanism and checked and updated them when they were found compatible... I guess it will take a 'killer plugin' which everyone wants to make the plugin interface more popular, and while all the issues about lacking concurrency and inability of plugins to communicate with the user remain there is probably little chance for that :(

Kay

[kfj]

On Thursday, May 9, 2013 12:23:29 PM UTC+2, Giancarlo Todone wrote: 

Well, I'm a c/c++/c#/java developer but i never even touched python with a stick so my best guess is that i failed something while trying to invoke woa from shell (e.g. parameters/working folder). Hugin is the official 2012 win32 build with python support (didn't compile it myself).

So you're a Windows user. This makes things more difficult for me, but we can try. Can you please invoke woa from the command line with --verbose (plus a pto file; don't use anything valuable unless you also set the --output option which keeps woa from modifying the input pto) and post what the console output is? Maybe I can get a clue.

I used to be a C/C++ developer and still am in a sense, but be assured that python is to C++ roughly what C++ is to C - it's the next level. If you're proficient with the C family, you'll be at home in no time, and it's quite straightforward to incorporate C code into python as well. Give it a try. You may find out you've missed out, big time.

Kay
 

[Giancarlo Todone]

http://www.stareat.it/sp.aspx?g=5902dd94972b4b1eb98989c2442a8081

While I still have to investigate following the path you indicated so kindly, I had the opportunity to make a couple additional tests. I took a shot in a complex location, with lots of people moving, lots of potential parallax errors, etc... and then I tried stitching with Hugin AND with PTGui. 

Hugin = awful. 

PTGui = awesome. 
(for the record: Autopano Pro scored something in between them)

I took a closer glance at how stitch task evolves in the different applications, and realized that sometimes Hugin's optimizer behaves in a very embarassing way. 

Then I did something very interesting: for each picture, I copied the positions optimized in PTGui (and producing there a wonderful pano) into Hugin and told it to just assemble... I still had tons of visible seams, where the shot quickly assembled with PTGui is PERFECT. Same with the previous project (the pet fish store).

After this experiment, I feel the urge to a) buy PTGui, b) try another blender (i.e. smartblend, that I couldn't manage to make work for now)

Is there something I'm missing?

[Giancarlo Todone]

Oh, sorry for the double post: i forgot to mention that linked panorama is the PTGui-optimized, Hugin(nona/enfuse/enblend)-assembled one, with hours of work to fix misalignements with deform tool in GIMP :(

[smib]

Hi Kay

Command line output as requested


checking for availability of tiffdump
checking for availability of nona
checking for availability of cpfind
main: parameters used for this run:
ceiling: 1.0
exclude: []
focus: None
images: []
margin: 0
output: xout.pto
scale: 0.25
stop: None
thresh: 0.01
prolific True
ptofile: b.pto
verbose: True
found 3 images in panorama
image 0: C:\SLR Photos\Europe 2006-7\England + Germany\IMGP0823.JPG
image 1: C:\SLR Photos\Europe 2006-7\England + Germany\IMGP0824.JPG
image 2: C:\SLR Photos\Europe 2006-7\England + Germany\IMGP0825.JPG
processing image set [0, 1, 2]
examining image pair (0, 1)
overlap area: 3946190.434895714 pixels
overlap ratio: 0.6559492079281439
overlap area: 3943129.262840057 pixels
overlap ratio: 0.6554403694880414
setting subpano width to 4722
creating warped overlap images with woa_000_001.pto
nona returned 0, output:
b'woa_000_0010000.tif: LZW compression is not available to due to
Unisys patent enforcement.\r\n'b'woa_000_0010001.tif: LZW compression
is not available to due to Unisys patent enforcement.\r\n'cp
detection: cpfind ['--fullscale', '--sieve2size', '5', '--ransacmode',
'hom', '-o', 'woa_000_001_warped.pto', '_woa_000_001_warped.pto']
CPG found 122 CPs
matching pair (0, 1) failed with TypeError: "can't use a string
pattern on a bytes-like object"
stack traceback:
examining image pair (0, 2)
overlap area: 2098998.746581664 pixels
overlap ratio: 0.3489027171844521
overlap area: 2084369.3272030938 pixels
overlap ratio: 0.3464709652930675
setting subpano width to 4722
creating warped overlap images with woa_000_002.pto
nona returned 0, output:
b'woa_000_0020000.tif: LZW compression is not available to due to
Unisys patent enforcement.\r\n'b'woa_000_0020001.tif: LZW compression
is not available to due to Unisys patent enforcement.\r\n'cp
detection: cpfind ['--fullscale', '--sieve2size', '5', '--ransacmode',
'hom', '-o', 'woa_000_002_warped.pto', '_woa_000_002_warped.pto']
CPG found 110 CPs
matching pair (0, 2) failed with TypeError: "can't use a string
pattern on a bytes-like object"
stack traceback:
examining image pair (1, 2)
overlap area: 3263912.034864002 pixels
overlap ratio: 0.5425385696250004
overlap area: 3262644.4793947963 pixels
overlap ratio: 0.5423278722398265
setting subpano width to 4722
creating warped overlap images with woa_001_002.pto
nona returned 0, output:
b'woa_001_0020000.tif: LZW compression is not available to due to
Unisys patent enforcement.\r\n'b'woa_001_0020001.tif: LZW compression
is not available to due to Unisys patent enforcement.\r\n'cp
detection: cpfind ['--fullscale', '--sieve2size', '5', '--ransacmode',
'hom', '-o', 'woa_001_002_warped.pto', '_woa_001_002_warped.pto']
CPG found 108 CPs
matching pair (1, 2) failed with TypeError: "can't use a string
pattern on a bytes-like object"
stack traceback:


Cheers

> >> Kay- Hide quoted text -
>
> - Show quoted text -

[Stefan Peter]

Dear smib

On 15.05.2013 12:39, smib wrote:
...

> setting subpano width to 4722
> creating warped overlap images with woa_000_001.pto
> nona returned 0, output:
> b'woa_000_0010000.tif: LZW compression is not available to due to
> Unisys patent enforcement.\r\n'b'woa_000_0010001.tif: LZW compression
> is not available to due to Unisys patent enforcement.\r\n'cp

Can you try with not LZW compressed files?


Regards

Stefan Peter

--
In theory there is no difference between theory and practice. In
practice there is.

[Gnome Nomad]

On 05/15/2013 03:35 AM, Stefan Peter wrote:

> On 15.05.2013 12:39, smib wrote:
> ...
>> setting subpano width to 4722
>> creating warped overlap images with woa_000_001.pto
>> nona returned 0, output:
>> b'woa_000_0010000.tif: LZW compression is not available to due to
>> Unisys patent enforcement.\r\n'b'woa_000_0010001.tif: LZW compression
>> is not available to due to Unisys patent enforcement.\r\n'cp

Bizarre ...

https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Welch#Patents



--
David W. Jones
gnome...@gmail.com
wandering the landscape of god
http://dancingtreefrog.com
http://www.clanjones.org/david/
http://dancing-treefrog.deviantart.com/
http://www.cafepress.com/otherend/

[Stefan Peter]

Hi Gnome Nomad

On 16.05.2013 08:32, Gnome Nomad wrote:
> On 05/15/2013 03:35 AM, Stefan Peter wrote:
>
>> On 15.05.2013 12:39, smib wrote:
>> ...
>>> setting subpano width to 4722
>>> creating warped overlap images with woa_000_001.pto
>>> nona returned 0, output:
>>> b'woa_000_0010000.tif: LZW compression is not available to due to
>>> Unisys patent enforcement.\r\n'b'woa_000_0010001.tif: LZW compression
>>> is not available to due to Unisys patent enforcement.\r\n'cp
>
> Bizarre ...
>
> https://en.wikipedia.org/wiki/Lempel%E2%80%93Ziv%E2%80%93Welch#Patents
>

Most probably an old tiff library was used for this compilation, one
that still had the LZW disabled. IIRC, we are talking about a self
compiled windows binary, and keeping up to date with all the
dependencies of hugin and their versions and variants is not easy.

[kfj]

On Wednesday, May 15, 2013 12:39:15 PM UTC+2, smib wrote:

matching pair (1, 2) failed with TypeError: "can't use a string
pattern on a bytes-like object"

Okay. Figured it out. The key is this last message, can't use a string...

The problem is due to the use of python 3. I hadn't tested woa under python 3, and obviously noone else has, either. So an error could stay undetected: to analyze tiffdump's output, the output is matched with regular expressions to filter out the bits which interest us. There, the re search patterns are given as string literals. This is fine in python 2.x, but python 3.x expects byte literals. Now this is easy to fix and doesn't break it for python 2.X either, because the relevant literal modifier, a prefixed 'b', is simply ignored in python 2.x. I'd ask you to midify woa.py in lines 237 and 238. The current version is

        fieldname = re.match ( r'[^\(]+' , t ) . group(0) . strip()
        fieldcontent = re.match ( r'([^<]+<)([^>]+)' , t )

please insert the additional 'b' so that the lines read

        fieldname = re.match ( br'[^\(]+' , t ) . group(0) . strip()
        fieldcontent = re.match ( br'([^<]+<)([^>]+)' , t )

this should fix the problem. If it does, please let me know so that I can send in a patch. If it doesn't , well..., let me know too, but I hope this is it ;-)

Kay

[smib]

Getting a little further. Message is now basically:

 

examining image pair (0, 1)

overlap area: 11736755.252809558 pixels

overlap ratio: 0.729671189939638

overlap area: 11524660.939996947 pixels

overlap ratio: 0.7164853386310013

setting subpano width to 7278

creating warped overlap images with woa_base.pto

cp detection: cpfind ['--fullscale', '--sieve2size', '5', '--ransacmode', 'hom', '-o', 'woa_warped.pto', '_woa_warped.pto']

CPG found 80 CPs

matching pair (0, 1) failed with TypeError: "float() argument must be a string or a number"

stack traceback

The suggetsed mod works with Python2.7

 

Brian

[kfj]

On Sunday, May 19, 2013 8:57:47 AM UTC+2, smib wrote:

Getting a little further. Message is now basically:

 

matching pair (0, 1) failed with TypeError: "float() argument must be a string or a number"

stack traceback

first of all, I can't quite figure out why there is no stack trace. Must be something different in the mechanics between py3k and py2.x. The stack trace would really help... mind you the uses of float() in woa are few and far between and I suppose the problem is still somewhere in get_tiff_offset() (there are for float() calls just right in it) and it may well be something non-trivial. I never liked that routine - wrote it because I couldn't find a better way to obtain the cropped TIFF's crop data.

Sadly just now I can't investigate, I'm busy packing up and going away for a few weeks soon - will be offline, too.
 

The suggetsed mod works with Python2.7

Does the rest? If it's a python 3 problem, then the solution for now is obviously just to run woa under python2.

 
Kay

[David Benes]

I have experienced exactly the same behavior as Brian.

2013/5/19 kfj <_k...@yahoo.com>

On Sunday, May 19, 2013 8:57:47 AM UTC+2, smib wrote:

Getting a little further. Message is now basically:

 

matching pair (0, 1) failed with TypeError: "float() argument must be a string or a number"

stack traceback

first of all, I can't quite figure out why there is no stack trace. Must be something different in the mechanics between py3k and py2.x. The stack trace would really help... mind you the uses of float() in woa are few and far between and I suppose the problem is still somewhere in get_tiff_offset() (there are for float() calls just right in it) and it may well be something non-trivial. I never liked that routine - wrote it because I couldn't find a better way to obtain the cropped TIFF's crop data.

Please find woa output including the stack trace below:

c:\Users\dbenes\Pictures\2013-03-30_prace>"\Program Files\Hugin\share\hugin\data\plugins\woa.py" --verbose test.pto

checking for availability of tiffdump

checking for availability of nona

checking for availability of cpfind

main: parameters used for this run:

ceiling: 1.0

exclude: []

focus:   None

images:  []

margin:  0

output:  None

scale:   0.25

stop:    None

thresh:  0.0

prolific False

ptofile: test.pto

verbose: True

found 2 images in panorama

image 0: IMG_1866.JPG

image 1: IMG_1867.JPG

processing image set [0, 1]

examining image pair (0, 1)

overlap area: 4298493.88568717 pixels

overlap ratio: 0.2855319481169525

overlap area: 4368892.844165321 pixels

overlap ratio: 0.2902082724980578

setting subpano width to 2830

creating warped overlap images with woa_base.pto

cp detection: cpfind ['--fullscale', '--sieve2size', '5', '--ransacmode', 'hom', '-o', 'woa_warped.pto', '_woa_warped.pto']

CPG found 70 CPs

matching pair (0, 1) failed with TypeError: "float() argument must be a string or a number"

stack traceback:

  File "C:\Program Files\Hugin\share\hugin\data\plugins\woa.py", line 1751, in process_image_set

    cps_added = cps_from_overlap ( pano , *pair )

  File "C:\Program Files\Hugin\share\hugin\data\plugins\woa.py", line 1617, in cps_from_overlap

    xoff1 , yoff1 = get_tiff_offset ( nona_output[0] )

  File "C:\Program Files\Hugin\share\hugin\data\plugins\woa.py", line 255, in get_tiff_offset

    xres = float ( gleaned.get ( 'XResolution' ) )

I'm using Hugin 2013.0.0 beta1 built by Matthew Petroff and Python 3.2 on Windows 8.

Regards

David

[kfj]

On Monday, May 20, 2013 10:24:04 AM UTC+2, mad wrote:

I have experienced exactly the same behavior as Brian.

2013/5/19 kfj <_k...@yahoo.com>

On Sunday, May 19, 2013 8:57:47 AM UTC+2, smib wrote:

Getting a little further. Message is now basically:

 

matching pair (0, 1) failed with TypeError: "float() argument must be a string or a number"

stack traceback

first of all, I can't quite figure out why there is no stack trace. Must be something different in the mechanics between py3k and py2.x. The stack trace would really help... mind you the uses of float() in woa are few and far between and I suppose the problem is still somewhere in get_tiff_offset() (there are for float() calls just right in it) and it may well be something non-trivial. I never liked that routine - wrote it because I couldn't find a better way to obtain the cropped TIFF's crop data.

Please find woa output including the stack trace below:

Thank you!
 

  File "C:\Program Files\Hugin\share\hugin\data\plugins\woa.py", line 255, in get_tiff_offset

    xres = float ( gleaned.get ( 'XResolution' ) )

Here we go. As I feared. gleaned is a dictionary containing all values gleaned from tiffdump's output. Normally, all directory entries would be stored with the field name as key, and it's content as value. But I reckon something is going wrong with the regular expression matching, and instead of sensible data for XResolution, the value is None, because the match failed. And then the conversion of None to a float fails, and the exception is raised. This could have several reasons: there might be a unicode vs. ASCII problem, tiffdump's output might have changed... but I'm just guessing. A first step would be to print the contents of the dictionary, by inserting

print(gleaned)

just befor the error happens (so, before line 255). Then if the value for 'XResolution' is in fact None, or something else which can't be made into a float, we could take it from there.

Kay  

[David Benes]

2013/5/20 kfj <_k...@yahoo.com>

  File "C:\Program Files\Hugin\share\hugin\data\plugins\woa.py", line 255, in get_tiff_offset

    xres = float ( gleaned.get ( 'XResolution' ) )

Here we go. As I feared. gleaned is a dictionary containing all values gleaned from tiffdump's output. Normally, all directory entries would be stored with the field name as key, and it's content as value. But I reckon something is going wrong with the regular expression matching, and instead of sensible data for XResolution, the value is None, because the match failed. And then the conversion of None to a float fails, and the exception is raised. This could have several reasons: there might be a unicode vs. ASCII problem, tiffdump's output might have changed... but I'm just guessing. A first step would be to print the contents of the dictionary, by inserting

print(gleaned)

just befor the error happens (so, before line 255). Then if the value for 'XResolution' is in fact None, or something else which can't be made into a float, we could take it from there.

Adding the print(gleaned) outputs following:

{b'YResolution': b'150', b'ResolutionUnit': b'2', b'Magic: 0x4949 <little-endian> Version: 0x2a': b'little-endian', b'Compression': b'5', b'ExtraSamples': b'2', b'XResolution': b'150', b'YPosition': b'0.88', b'BitsPerSample': b'8 8 8 8', b'SampleFormat': b'1 1 1 1', b'XPosition': b'5.17333', b'ImageWidth': b'1097', b'SamplesPerPixel': b'4', b'StripByteCounts': b'619896 627674 587989 463971 90174', b'RowsPerStrip': b'238', b'PlanarConfig': b'1', b'StripOffsets': b'8 619904 1247578 1835567 2299538', b'ImageLength': b'1068', b'Orientation': b'1', b'Photometric': b'2', b'33300': b'2634', b'33301': b'1317', b'SubFileType': b'0'}

So reading something about Python and b prefix I have found that modifying lines 253-256 the same way as you advised earlier in the thread for another lines fixed the woa. So modifying lines 253-256 from:

    xpos = float ( gleaned.get ( 'XPosition' , 0 ) )

    ypos = float ( gleaned.get ( 'YPosition' , 0 ) )

    xres = float ( gleaned.get ( 'XResolution' ) )

    yres = float ( gleaned.get ( 'YResolution' ) )

to (adding prefix b):

    xpos = float ( gleaned.get ( b'XPosition' , 0 ) )

    ypos = float ( gleaned.get ( b'YPosition' , 0 ) )

    xres = float ( gleaned.get ( b'XResolution' ) )

    yres = float ( gleaned.get ( b'YResolution' ) )

fixed it. Now woa works like a charm.

Thank you very much for you help.

Regards

David

[kfj]

On Tuesday, May 21, 2013 12:48:16 AM UTC+2, mad wrote:

Adding the print(gleaned) outputs following:

{b'YResolution': b'150', ... }

So reading something about Python and b prefix I have found that modifying lines 253-256 the same way as you advised earlier in the thread for another lines fixed the woa. So modifying lines 253-256 from:

    xpos = float ( gleaned.get ( 'XPosition' , 0 ) )

    ypos = float ( gleaned.get ( 'YPosition' , 0 ) )

    xres = float ( gleaned.get ( 'XResolution' ) )

    yres = float ( gleaned.get ( 'YResolution' ) )

to (adding prefix b):

    xpos = float ( gleaned.get ( b'XPosition' , 0 ) )

    ypos = float ( gleaned.get ( b'YPosition' , 0 ) )

    xres = float ( gleaned.get ( b'XResolution' ) )

    yres = float ( gleaned.get ( b'YResolution' ) )

fixed it. Now woa works like a charm.

Thank you very much for you help.

You're welcome, and well done for figuring it out! Works like a charm... that's what I like to hear :)

Kay