[OSX] 20120115 New Hugin bundle hugin-mac-2011.5.0.5723_cd2f5e37af3b incl. multiblend 0.2 and enblend 4.1 development

[Harry van der Wolf]

Hi mac users,

I built another Hugin bundle including:
- multiblend 0.2 with another patch for blending-int.cpp from David Horman (1).
- the development OpenMP versions of enblend and enfuse 4.1 (4.1-3cba1ed1aaff), which I have now temporary called enblendhg and enfusehg (2). (hg as they come from the mercurial(=hg) repository).

The default openmp 4.0 enblend and enfuse are still completely integrated in the bundle.

Both the development 4.1 enblend/enfuse and multiblend 0.2 are not completely integrated in the bundle yet, so how do you use it:
- In Preferences, goto programs -> use other enblend
- browse to the HuginTools folder (next to your Hugin.app and PTBatcherGui.app) and select either "enblendhg" or "multiblend".
- If you need enfuse for your stacks: browse to the HuginTools folder (next to your Hugin.app and PTBatcherGui.app) and select "enfusehg"

Notes multiblend:
- multiblend can only run on Intel machines (universal i386/x86_64 binary) !!!
- multiblend can now create both tiffs and jpegs.
- multiblend uses a lot of memory, especially with larger panos (logical off course).

Notes enblendhg/enfusehg:
- enblendhg and enfusehg do run on ppc/i386/x86_64 but can only run on Leopard and SnowLeopard (perhaps now also Lion, but I'm afraid not).
- enblendhg is (much) slower due to it's new primary seam generator (2).


Please experiment and report your findings here in the hugin google group. This means both errors in multiblend and enblendhg/enfusehg itself as well as in my configuration.
enblend and enfuse errors belong technically to the enblend launchpad (3), but please mention them first in the hugin-group as they might well be my build errors.

Tiger and Lion users: Use the Tiger enblend from the enblend-enfuse-4.0 folder inside the .dmg.
(This is the normal reminder if you use enblend. For the new enblendhg see above: it might work for Lion. This info does not relate to multiblend)

Information and binaries via my website
<http://panorama.dyndns.org/index.php?lang=en&subject=Hugin&texttag=Hugin>.
(The binaries themselves are served from hugin.panotools.org who kindly provide the disk space and bandwidth).

Hoi,
Harry

(1): <http://groups.google.com/group/hugin-ptx/browse_thread/thread/b08211b2659a7eab>
(2): <http://groups.google.com/group/hugin-ptx/browse_thread/thread/51b510a317935df1>
(3): <https://bugs.launchpad.net/enblend/>

[AKS-Gmail-IMAP]

Harry, 

These are my findings on a PPC running 10.5.8. I have been out of touch for a while so I have not tested the previous multiblend versions.

- I saw the new (to me) "I am Hugin .. " message regarding preference settings. This is nice.

- The Preferences form did not open wide enough to completely see all the tabs.

- I reset Preferences to default.

- cpfind control point detection clearly failed, instantly, without any error reporting.

- The default multirow line from the cpfind argument list is not the problem.

- The vertical line control point detection functioned properly.

- The Assistant process did not realize no control points were generated. The process happily opened up the fast preview with all the images stacked on each other.

- PTBatcherGUI needs to open in front focus so that its overwrite file form is visible. This has been going on for some time.

- The PTBatcherGUI form window cannot be resized to be smaller in width. The resize height functions properly. The PTBatcherGUI minimum form window width on this machine fits exactly in the 1440 pixel width.

    

Thanks for you bundling.

Allan

--
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 hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

[Harry van der Wolf]

Hi Allan,

2012/1/15 AKS-Gmail-IMAP <akse...@gmail.com>

Harry, 

These are my findings on a PPC running 10.5.8. I have been out of touch for a while so I have not tested the previous multiblend versions.

- I saw the new (to me) "I am Hugin .. " message regarding preference settings. This is nice.

- The Preferences form did not open wide enough to completely see all the tabs.

- I reset Preferences to default.

- cpfind control point detection clearly failed, instantly, without any error reporting.

- The default multirow line from the cpfind argument list is not the problem.

I'm completely flabbergasted. cpfind is only i386 and not ppc. That's the reason it doesn't function. Fortunately it is the only binary, but still I have no clue how this has happened. What's worse is that it's also in the 2011.4.0 release bundle so it's already for a longer time. I'm also astonished that none of the other ppc users ever mentioned this. Thanks that you did.

- The vertical line control point detection functioned properly.
 

- The Assistant process did not realize no control points were generated. The process happily opened up the fast preview with all the images stacked on each other.

 

- PTBatcherGUI needs to open in front focus so that its overwrite file form is visible. This has been going on for some time.

- The PTBatcherGUI form window cannot be resized to be smaller in width. The resize height functions properly. The PTBatcherGUI minimum form window width on this machine fits exactly in the 1440 pixel width.

    

PTBatcherGui's window behavior also needs some improvement on my Intel.


Harry

[Harry van der Wolf]

2012/1/15 Harry van der Wolf <hvd...@gmail.com>

Hi Allan,

I'm completely flabbergasted. cpfind is only i386 and not ppc. That's the reason it doesn't function. Fortunately it is the only binary, but still I have no clue how this has happened. What's worse is that it's also in the 2011.4.0 release bundle so it's already for a longer time. I'm also astonished that none of the other ppc users ever mentioned this. Thanks that you did.

The weird thing is that the setting was OK in the XCode project (1) but it only compiled i386. I changed the setting for another 32bit universal "alias"  setting (2) and now it  does compile as i386/ppc.

I have no idea?!

Now I first have to rebuild the 2011.4 bundle.

Harry

(1:)
ARCHS = "$(ARCHS_STANDARD_32_BIT_PRE_XCODE_3_1)";
ARCHS_STANDARD_32_BIT_PRE_XCODE_3_1 = "ppc i386";

(2): ARCHS = "$(RELEASE_ARCHS_32)";

[Bob Campbell]

On Jan 15, 12:56 pm, AKS-Gmail-IMAP <aksei...@gmail.com> wrote:
> - cpfind control point detection clearly failed, instantly, without
> any error reporting.

I haven't tried this latest test release, but for what it's worth,
I've been seeing this on my G4 Powerbook running 10.5.9.

The Align function in the Assistant tab dies almost immediately, but
if you switch to the Images tab, select all the images, pick your
favorite CP detector, and click Create Control Points, it works just
fine. Seems like it ought to be using the same code segments, but
maybe not? Don't know why there'd be different behavior. (I'm using
cpfind, BTW)


-Bob

[George R]

Harry,
Thanks for this new version.

I gave it a try and eventually got it to complete a stitch - having
noticed a couple of odd things along the way.

First odd thing.
At first when I changed the Program Preferences to use MultiBlend it
seemed to not take me seriously! (I also have this problem sometimes
with humans.:-) When I re-ran an existing project it just used
enblend as it always had. After several tries over a couple of days
it eventually did seem to use Multiblend and after that I couldn't get
it to go wrong. I have made a wild guess that perhaps if PTBatcher
is open (which I suspect it was in my case) when a preference is
changed in Hugin then PTBatcher needs to be quit and restarted before
it will apply the new preferences? That is reasonable behaviour - but
perhaps it could be mentioned in the instructions somewhere.

Second Odd thing
When I did get Hugin to use Multiblend the resulting panorama had
colours that were quite odd. The blues were sort of copper-coloured
or flesh-tones. Greens were shades of turquoise. Browns were shades
of grey. It was an interesting effect ... it looked a bit like the
scene had been shot on something like infrared film. This time my
guess was that the problem lay with my 16-bit Tiff input files. So I
re-created my input-image-set as 8-bit Tiffs and this time the project
ran to completion producing an acceptable stitch.

It would be great if MultiBlend could handle 16-bit Tiffs as the
projects where I have problems with run-time tend to be the ones using
large 16-bit Tiff images.


George

> (1): <http://groups.google.com/group/hugin-ptx/browse_thread/thread/b08211b...
>
> (2): <http://groups.google.com/group/hugin-ptx/browse_thread/thread/51b510a...
>
> (3): <https://bugs.launchpad.net/enblend/>

[Harry van der Wolf]

2012/1/17 Bob Campbell <thebobc...@gmail.com>

Same error as Alan mentioned a few posts back. cpfind is incorrectly compiled: the ppc part is missing.

I will first update the 201.4 release as that one has the same issue. Then I will post the corrected development bundle.

 

Harry

[Harry van der Wolf]

2012/1/17 George R <geor...@gmail.com>

Harry,
Thanks for this new version.

I gave it a try and eventually got it to complete a stitch  - having
noticed a couple of odd things along the way.

First odd thing.
At first when I changed the Program Preferences to use MultiBlend it
seemed to not take me seriously!  (I also have this problem sometimes
with humans.:-)  When I re-ran an existing project it just used
enblend  as it always had. After several tries over a couple of days
it eventually did seem to use Multiblend and after that I couldn't get
it to go wrong.   I have made a wild guess that perhaps if PTBatcher
is open (which I suspect it was in my case) when  a preference is
changed in Hugin then PTBatcher needs to be quit and restarted before
it will apply the new preferences? That is reasonable behaviour - but
perhaps it could be mentioned in the instructions somewhere.

 

I noticed this as well. It happens when you PTBatcherGui already open. PTBatcherGui only reads the hugin preferences on startup, so if you change something inbetween it is not noticed by PTBatchergui.

I have already asked Thomas about this and he asked me to file a "feature request". I will, but he still on holiday.

 

 

 

Second Odd thing
When I did get Hugin to use Multiblend the resulting panorama had
colours that were quite odd.  The blues were sort of copper-coloured
or flesh-tones.  Greens were shades of turquoise. Browns were shades
of grey.  It was an interesting effect ... it looked a bit like the
scene had been shot on something like infrared film.  This time my
guess was that the problem lay with my 16-bit Tiff input files.  So I
re-created my input-image-set as 8-bit Tiffs and this time the project
ran to completion producing an acceptable stitch.

 

There were some mails about this issue and you had to pass a command line to overcome this.

The option to pass is --bgr (for: swap RGB order)

It only happens with tiffs as far as I know.

 

 

It would be great if MultiBlend could handle 16-bit Tiffs as the
projects where I have problems with run-time tend to be the ones using
large 16-bit Tiff images.

 

Please respond to the latest multiblend 0.2 thread and ask David.

 

 

Harry

[Rogier Wolff]

On Tue, Jan 17, 2012 at 03:11:18PM +0100, Harry van der Wolf wrote:
> The option to pass is --bgr (for: swap RGB order)
> It only happens with tiffs as far as I know.

In case someone wants to look into this before I do:

My "working theory" is that many tiffs come with the color planes in
RGB order, and multiblend ignores that and assumes that the first is
R, the second G, and the third B. The tiffs that go wrong happen to
have BGR order in the file. (*)

George, you're welcome to compress and send me one of your 16-bit
tiffs so that I can investigate this theory....

Roger.

(*) Or things could be exactly the other way around. Some program
wrote them out BGR and tagged them RGB, and Multiblend believes the
tags...

--
** R.E....@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.

[Ian Tindale]

Tiffs can be RGB as planar or chunky. Planar is stored as all the red; then all the green; then all the blue. Chunky is stored as a pixel’s RGB; then the next pixel’s RGB; then the next pixel’s RGB; etc. Chunky also pays attention to “bits per sample”, and “samples per pixel” (3 for RGB). I’ve never heard of a tiff chunky format that goes BGR or even RBG or anything that deviates from R first; then G; then B last.

--
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 hugi...@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx+...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx

--
Ian Tindale

[Ian Tindale]

By the way, this is the TIFF 6 spec: http://partners.adobe.com/public/developer/en/tiff/TIFF6.pdf

--
Ian Tindale

[kfj]

On 17 Jan., 14:11, George R <george...@gmail.com> wrote:

> First odd thing.
> At first when I changed the Program Preferences to use MultiBlend it
> seemed to not take me seriously!  (I also have this problem sometimes
> with humans.:-)  When I re-ran an existing project it just used
> enblend  as it always had. After several tries over a couple of days

> ...

I've hit upon this. The reason AFAIK is that changing the hugin
preferences only affects new projects. It's really fiddly to get an
existing project stitched with something different, but as you've
found out, being persistent can do the trick ;-)

I've forgotten what precisely you have to do to change the setting for
an existing project (modifying the relevant line in the pto and
restarting hugin before loading the pto might do the trick - the line
I mean is "#hugin_blender enblend" towards the end) - and pressing the
'Apply' button in the preferences might also have an effect - opposite
to standard GUI behaviour where pressing Okay will apply a setting, I
think in hugin it may not override the existing project's settings.

> it eventually did seem to use Multiblend and after that I couldn't get
> it to go wrong.   I have made a wild guess that perhaps if PTBatcher
> is open (which I suspect it was in my case) when  a preference is
> changed in Hugin then PTBatcher needs to be quit and restarted before
> it will apply the new preferences? That is reasonable behaviour - but
> perhaps it could be mentioned in the instructions somewhere.

Indeed the bahaviour is confusing. I think the rationale, if any, is
to make sure a given pto will create the same output every time, so if
an existing PTO is loaded, it's settings will rule.

> Second Odd thing
> When I did get Hugin to use Multiblend the resulting panorama had
> colours that were quite odd.  The blues were sort of copper-coloured
> or flesh-tones.  Greens were shades of turquoise. Browns were shades
> of grey.  It was an interesting effect ... it looked a bit like the
> scene had been shot on something like infrared film.  This time my
> guess was that the problem lay with my 16-bit Tiff input files.  So I
> re-created my input-image-set as 8-bit Tiffs and this time the project
> ran to completion producing an acceptable stitch.

This is a common problem with multiblend. You need to pass it the -bgr
flag. For some reason it sometimes uses BGR instead of RGB.

> It would be great if MultiBlend could handle 16-bit Tiffs as the
> projects where I have problems with run-time tend to be the ones using
> large 16-bit Tiff images.

I also use 16bit TIFFs. With the -bgr switch, the colours come out all
right.

Kay

[Harry van der Wolf]

2012/1/18 kfj <_k...@yahoo.com>

On 17 Jan., 14:11, George R <george...@gmail.com> wrote:

> First odd thing.
> At first when I changed the Program Preferences to use MultiBlend it
> seemed to not take me seriously!  (I also have this problem sometimes
> with humans.:-)  When I re-ran an existing project it just used
> enblend  as it always had. After several tries over a couple of days

> ...

I've hit upon this. The reason AFAIK is that changing the hugin
preferences only affects new projects. It's really fiddly to get an
existing project stitched with something different, but as you've
found out, being persistent can do the trick ;-)

I've forgotten what precisely you have to do to change the setting for
an existing project (modifying the relevant line in the pto and
restarting hugin before loading the pto might do the trick  - the line
I mean is "#hugin_blender enblend" towards the end) - and pressing the
'Apply' button in the preferences might also have an effect - opposite
to standard GUI behaviour where pressing Okay will apply a setting, I
think in hugin it may not override the existing project's settings.

As mentioned by me a few posts before: Both Thomas and me discussed this already and PTBatchgerGui only reads preferences at startup.
I will file a "feuture request" so that PTBatcherGui reads the preferences before starting a new project.

Harry

[Harry van der Wolf]

Hi mac users on ppc,

2012/1/15 Harry van der Wolf <hvd...@gmail.com>

Hi Allan,

2012/1/15 AKS-Gmail-IMAP <akse...@gmail.com>

Harry, 

These are my findings on a PPC running 10.5.8. I have been out of touch for a while so I have not tested the previous multiblend versions.

- I saw the new (to me) "I am Hugin .. " message regarding preference settings. This is nice.

- The Preferences form did not open wide enough to completely see all the tabs.

- I reset Preferences to default.

- cpfind control point detection clearly failed, instantly, without any error reporting.

- The default multirow line from the cpfind argument list is not the problem.

I'm completely flabbergasted. cpfind is only i386 and not ppc. That's the reason it doesn't function. Fortunately it is the only binary, but still I have no clue how this has happened. What's worse is that it's also in the 2011.4.0 release bundle so it's already for a longer time. I'm also astonished that none of the other ppc users ever mentioned this. Thanks that you did.

I rebuilt the bundle now (after having corrected the 2011.4.0 release bundle first).
If you are on ppc, please download again and try again: cpfind should now work.
For those on Intel: Nothing has changed for you. Please continue using and testing.

Harry
 

[George R]

The --bgr option produced normal behaviour.

On reflection ... the image with the colours "wrong" looked really
great - much more interesting than the "real" one. Would the --bgr
option create the colour swap effect if this is ever fixed?

George

On Jan 17, 2:11 pm, Harry van der Wolf <hvdw...@gmail.com> wrote:
> 2012/1/17 George R <george...@gmail.com>

[George R]

Roger,

Thanks I have sent you an email with a link to a shared file with a
65Mb compressed 16-bit TIFF.

On reflection I do like the effect that this bug creates.

George

On Jan 17, 10:49 pm, Rogier Wolff <rew-googlegro...@BitWizard.nl>
wrote:

> On Tue, Jan 17, 2012 at 03:11:18PM +0100, Harry van der Wolf wrote:
>
> > The option to pass is --bgr (for: swap RGB order)
> > It only happens with tiffs as far as I know.
>
> In case someone wants to look into this before I do:
>
> My "working theory" is that many tiffs come with the color planes in
> RGB order, and multiblend ignores that and assumes that the first is
> R, the second G, and the third B. The tiffs that go wrong happen to
> have BGR order in the file. (*)
>
> George, you're welcome to compress and send me one of your 16-bit
> tiffs so that I can investigate this theory....
>
>         Roger.
>
> (*) Or things could be exactly the other way around. Some program
> wrote them out BGR and tagged them RGB, and Multiblend believes the
> tags...
>
> --

> ** R.E.Wo...@BitWizard.nl **http://www.BitWizard.nl/** +31-15-2600998 **

[George R]

... ooops I hadn't meant to change the Subject ... have put it back
to Harry's version. (I think)

On Jan 18, 5:32 pm, George R <george...@gmail.com> wrote:
> Roger,
>
> Thanks  I have sent you an email with a link to a shared file with a
> 65Mb compressed 16-bit TIFF.
>
> On reflection I do like the effect that this bug creates.
>
> George
>
> On Jan 17, 10:49 pm, Rogier Wolff <rew-googlegro...@BitWizard.nl>
> wrote:
>
>
>
>
>
>
>
> > On Tue, Jan 17, 2012 at 03:11:18PM +0100, Harry van der Wolf wrote:
>
> > > The option to pass is --bgr (for: swap RGB order)
> > > It only happens with tiffs as far as I know.
>
> > In case someone wants to look into this before I do:
>
> > My "working theory" is that many tiffs come with the color planes in
> > RGB order, and multiblend ignores that and assumes that the first is
> > R, the second G, and the third B. The tiffs that go wrong happen to
> > have BGR order in the file. (*)
>
> > George, you're welcome to compress and send me one of your 16-bit
> > tiffs so that I can investigate this theory....
>
> >         Roger.
>
> > (*) Or things could be exactly the other way around. Some program
> > wrote them out BGR and tagged them RGB, and Multiblend believes the
> > tags...
>
> > --

> > ** R.E.Wo...@BitWizard.nl **http://www.BitWizard.nl/**+31-15-2600998 **

[AKS-Gmail-IMAP]

Cpfind works on ppc for me with this bundle.

Thanks Harry,

Allan