gmane.comp.misc.ptx

Re: Re: Small errors, Projection formula and Preview

David Benes — 2013-05-20T22:48:16

2013/5/20 kfj <_kfj< at >yahoo.com>


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

Re: Re: hugin automation - pto_gen missing in the nightly ppa

Bruno Postle — 2013-05-20T21:18:07

Does this patch need to be pushed to the libpano13 HG repo?

Re: mosaic mode with intuitive warp parameters

Oskar Sander — 2013-05-20T20:50:10

Interesting, I would be happy to test on 32bit Ubuntu or 32bit Win.   I've
had a couple of tricky mosaic procjets a couple of years ago, but gave up
on Hugin.  the problem with the (IMHO) wrong axis was one of the issues I
belive. This sounds better.

Cheers
/O


2013/2/22 Terry Duell <tduell< at >iinet.net.au>

Re: Re: Small errors, Projection formula and Preview

kfj — 2013-05-20T20:13:45


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

Thank you!
 

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

Re: hugin automation - pto_gen missing in the nightly ppa

Andreas Metzler — 2013-05-20T17:02:38

[...]


Hello,
That is strange, I have just doublechecked, testsuite succeeds here on
Debian/unstable both ix86 and am64 with both gcc-4.7 and gcc-4.8.

[...]

Doublestrange, afaik adding -g should not change the outcome. (unlike
-O0 /- O2) - Also the standard Ubuntu/Debian build uses -g.

cu Andreas

Re: Re: hugin automation - pto_gen missing in the nightly ppa

Stefan Peter — 2013-05-20T11:16:03

Dear Andreas Metzler

On 20.05.2013 12:00, Andreas Metzler wrote:

I know, as usual I used the Debian 2.9.18 as a base for 2.9.19.

However, at least when compiled under raring, the tests now fail.
I'd be inclined to drop them if I didn't find that under x86_64, even
the simpleStitch tests fail. There seems to be a problem in PTmender
under x86_64:
libpano.tst/tests/simpleStitch$ ../../tools/PTmender -o output temp.txt
PTmender Version 2.9.19 , originally written by Helmut Dersch, rewritten
by Daniel German
Segmentation fault (core dumped)

However, when I build PTMender with -g, the tests pass.

Currently, I don't have the time to investigate this any further (and no
clue on where to start).

Regards

Stefan Peter

Re: hugin automation - pto_gen missing in the nightly ppa

Andreas Metzler — 2013-05-20T10:00:15



We are successfully running the testsuite on Debian (2.9.18), the only
relevant patch we are using is
<http://anonscm.debian.org/gitweb/?p=pkg-phototools/libpano.git;a=blob;f=debian/patches/20_initfilenameargs.diff;h=cd9bf161e96fcd2f42b009fce91a51c248c268d7;hb=libpano13/unstable>

cu Andreas

Re: hugin automation - pto_gen missing in the nightly ppa

Bruno Postle — 2013-05-20T09:22:21

I'm not sure these tests are relevant, they have never worked for me.
They should be disabled if nobody is working on fixing them.

--
Bruno

Re: hugin automation - pto_gen missing in the nightly ppa

Stefan Peter — 2013-05-20T08:56:51

Hi Terry

On 19.05.2013 01:13, Terry Duell wrote:

No, and it probably will take some time to do so because the nightly
build depends on the yet unreleased libpano13-2.9.19 which fails to
build due to failing tests.

Your best chance to get the latest stable hugin version (2013.0 beta1)
for Ubuntu would be the "next Hugin builds" from the launchpad at
https://launchpad.net/~hugin/+archive/next


For Debian, a 2013.0 beta1 version van be found in the experimental
distribution, see
http://packages.debian.org/experimental/hugin

You may find 2013.0 beta1 packages for other distributions mentioned at
http://www.mail-archive.com/hugin-ptx< at >googlegroups.com/msg19725.html


With kind regards

Stefan Peter

Re: Re: Small errors, Projection formula and Preview

David Benes — 2013-05-20T08:24:04

I have experienced exactly the same behavior as Brian.

2013/5/19 kfj <_kfj< at >yahoo.com>

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'

Re: How to discard automatically the unconnected images ?

Bruno Postle — 2013-05-19T20:56:50

There is no feature to do this in Hugin.  You could maybe try 
something like setting all photos to roll, pitch and yaw = 0, 
optimising, then the unconnected photos will still have these 0 
values so they can be identified and deleted.

If you need to do this lots of times, then it would be possible with 
Panotools::Script.  You would need to write a perl script that 
identifies the connected groups with the ConnectedGroups() method, 
sorts the list to find the biggest group, then creates a new .pto 
project of just the photos in this group using the Subset() method.

Re: Small errors, Projection formula and Preview

kfj — 2013-05-19T15:02:38


On Sunday, May 19, 2013 8:57:47 AM UTC+2, smib wrote:
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.
 


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

Re: Small errors, Projection formula and Preview

smib — 2013-05-19T06:57:47

Getting a little further. Message is now basically:
 
 
The suggetsed mod works with Python2.7
 
Brian
 
 

On Friday, 17 May 2013 20:10:49 UTC+10, kfj wrote:

Re: hugin automation - pto_gen missing in the nightly ppa

Terry Duell — 2013-05-18T23:13:59

Hello Thomas,

On Sat, 18 May 2013 22:18:05 +1000, Thomas Pryds <thomas< at >pryds.eu> wrote:


Thanks for educating me, I didn't know that.
Is the missing pto_gen now fixed?

Cheers,

Re: Some enfuse questions from a serious and desperate user

cspiel — 2013-05-18T14:46:06

Kai-Uwe -

Am Samstag, 18. Mai 2013 12:40:40 UTC+2 schrieb beku:

        In fact, I can't.

My assumptions of the blending process are ridiculously naive:
        p' = t * p0 + (1 - t) * p1,  0 <= t <= 1.
where the ps are some relevant characteristics of pixels 0 and 1 to be
blended, e.g. some luminance measure.  Obviously, this equation can
return values for p' that are outside a color space for a specific
profile or even for an entire color space; think of p0 and p1 being
very close to the shell.  The Enblend/Enfuse code in question juggles
with three: RGB, JCh, and Lab.  And suddenly you're not in Kansas
anymore.

        In version 2.x LCMS introduced the "Unbounded CMM" (see,
e.g. http://www.littlecms.com/CIC18_UnboundedCMM.pdf), where the
library itself does not take care anymore to keep all values inside
the color spaces, but instead lets the user decide what to do with
"outsiders".  Enblend/Enfuse has picked up that idea and both programs
work on unbounded values as long as possible.  That way, the

Re: hugin automation - pto_gen missing in the nightly ppa

Thomas Pryds — 2013-05-18T12:18:05

Den 18/05/2013 01.53 skrev "Terry Duell" <tduell< at >iinet.net.au>:

A must-have for Hugin users running Ubuntu (if they don't want to build
themselves):

https://launchpad.net/~hugin

There's a ppa with releases, one with upcoming releases (e.g. release
candidates), and one with nightly builds.

From the Hugin download page there's a link to the wiki where enabeling the
ppa in your system is explained.

Thomas

Re: Some enfuse questions from a serious and desperate user

beku — 2013-05-18T10:40:40

Am Samstag, 18. Mai 2013 08:58:58 UTC+2 schrieb cspiel:

Can you describe more specifically what you expected and what changed in 
which version of lcms. So it might be more easy to fill a bug report and 
get proper attention?

kind regards
Kai-Uwe

Re: Some enfuse questions from a serious and desperate user

cspiel — 2013-05-18T06:58:58

Mark -


        Several ideas come into my mind.

(1) Utilize Enfuse's CIECAM-mode either by forcing it with option
    `--ciecam' on input images w/o ICC profiles or, much better, feed
    images into Enfuse that all have the same ICC profile.  16-bit per
    channel in conjunction with the ProPhoto RGB space are promising.

    However, CIECAM-mode is broken with newer versions of the
    LittleCMS library.  Preliminary fixes have been applied to the
    development branch ("compressor road"), but not yet to the
    stable branch.

(2) Play with the `--exposure-cutoff' option, which was designed to
    tame extreme over- or underexposure.  Usually one can leave this
    option's gray projectors alone.

(3) The current development version of Enfuse offers user-defined
    exposure weighting functions.  So, either given enough
    C++-programming proficiency or a grumpy, greasy, growling hacker
    near you, almost any exposure weight is possible.



        These are more or less expected artifacts from no

Re: hugin automation - pto_gen missing in the nightly ppa

Terry Duell — 2013-05-17T23:49:52

Hello Max,

On Fri, 17 May 2013 17:13:08 +1000, Max Killer <hal.from.2001< at >gmail.com>  
wrote:

[snip]


I wasn't aware that the hugin project builds a nightly binary.


I have just built the latest default branch source (for Fedora) and  
pto_gen is included.
I suspect there is an error in the way the ppa is being built.
Probably best to see if you can contact those responsible for the build.
 From where do you get your ppa ?

Cheers,

Re: Small errors, Projection formula and Preview

kfj — 2013-05-17T10:10:49


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 

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

hugin automation - pto_gen missing in the nightly ppa

Max Killer — 2013-05-17T07:13:08

Hello all,

I hope this is the right list, please excuse if not.

I am working with darktable as an RAW image manipulation program and the 
latest addition was Lua scripting for darktable.
With this I am trying to automate the pano (and HDR--> LDR) generation out 
of darktable.

I had a complete script up and running, but now I have the problem that 
either the hugin tools crash (fov <0, from the next versions ppa), or 
pto_gen is missing (in the nightly ppa). Are there good reasons not to 
include pto_gen in the nightlies?

If pto_gen cannot be included in the nightlies, is it included in the 
source so I can build it myself?

I know that theoretically, I could construct a pto file just with Lua, but 
it seems like a lot of work. Maybe I am just overlooking an easy way to 
build a pto without pto_gen.


Any help appreciated.

Max