Updated extended enfuse and enblend documentation

[Harry van der Wolf]

Hi all,

On January 21 I posted a mail [1] to the hugin-ptx and the panotools-ng group about extended enfuse and enblend documentation written by dr. Christopher Spiel and published on my site.

Since then Christoph has been busy improving, expanding and bug-fixing enblend and enfuse. He had already started an official spin-off development branch. His developments have recently been merged into the official tree and ARE now the official tree and we are now heading towards a version 4.0 release. You can find this development tree at enblend.sourceforge.net. Enblend/enfuse have switched from CVS to Mercurial.

Next to further developing enblend and enfuse to the next level, he also continued writing and correcting the documentation and expanding the formats in which it is (can be) published.

I updated the  "EandE-documentation" page on my website at <http://panorama.dyndns.org/EandE-documentation/>. This documentation is dated 11 August 2009.
Again: this is not my work at all. All credits go to Christoph Spiel.

Note also that Andrew Mihal is the creator ("father") and main developer of enblend/enfuse until 3.2 when he started working on a GPU enhanced version of nona.


Hoi,
Harry


[1]: http://groups.google.com/group/hugin-ptx/browse_thread/thread/d5b60a281360eae1

[cspiel]

Harry -

Thank you very much for making the new
documentation of Enblend and Enfuse available
online!

I'd like to use this occasion to call for
(1) technical reviewers ("Do the docs describe
the programs exactly and completely?") and
(2) proof readers ("Is the documentation written
in correct and understandable English?")
of the new user guides. Enblend/Enfuse are in
feature freeze for the forthcoming 4.0 release.
Thus, checking the documentation is possible
without hunting the "creeping feature creature".

(1) Technical reviewers should already know
Enblend or Enfuse very well. They don't have to
be developers. In fact we prefer ordinary users
for this job. A technical reviewer should be
adventurous enough to try out the new features
both applications offer now.

If anything more complicated than a double-click
makes your head explode, you probably will not
fit as a technical reviewer.

(2) Proof readers _must_ be native speakers of
the English language _and_ have a rock solid
understanding of its grammar. Experience in
writing technical documentation or using
Enblend/Enfuse is beneficial although not
necessary.

Why these demanding requirements for proof
readers? -- Most of us can write mediocre
English and come up with some incomprehensible
sentences from time to time. There is no lack
in these kind of authors! We are hackers not
poets. However, we want to improve on the
documentation of Enblend/Enfuse as we have
enhanced the programs themselves.

Please either contact me directly for your
shorter problem reports or create a ticket in
Enblend's bug tracker at SourceForge if the
problem size seems to demand it.


Thanks,
Chris

[Erik Krause]

cspiel wrote:

> Thank you very much for making the new
> documentation of Enblend and Enfuse available
> online!

Yes, many thanks!

If I understand correctly, the documentation is not yet for the upcoming
version 4.0, is it?

However, how shall we proceed with the wiki pages at
http://wiki.panotools.org/Enfuse_reference_manual
http://wiki.panotools.org/Enblend_reference_manual ? The wiki would be a
good possibility to cooperatively maintain the manual. However, it would
be needed to update the pages first. If someone could provide me with a
Diff of the older and the current version I could do this.

If you think it's better to maintain the manuals in TeX (which I believe
is the native format) I would prefer to update the wiki with the final
version. Unfortunately I don't know enough about TeX to do the Diff
myself...

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

[cspiel]

Erik -

On Sep 8, 2:04 pm, Erik Krause <erik.kra...@gmx.de> wrote:
> If I understand correctly, the documentation is not yet for the upcoming
> version 4.0, is it?

My approach to the release process is
to always have a revision that passes
make distcheck
and my own test suite. Dunno whether this comes
from "Xtreme Programming" or "The Pragmatic
Programmer". Anyhow, this way we won't have a
Big Bang Release, but (hopefully) approach a
better state with each revision. Someday
somebody will yell "Stop, this is it!" and we'll
tag the revsion with "4.0".

> However, how shall we proceed with the wiki pages at
> http://wiki.panotools.org/Enfuse_reference_manual

> http://wiki.panotools.org/Enblend_reference_manual? The wiki would be a

> good possibility to cooperatively maintain the manual.

The sources of the documentation are in
the "doc" directory of the Enblend-Enfuse
project. The closeness to the code facilitates
to match the documentation with the code and I
pay great attention to the fact that they _do_
match. Accurate and comprehensive documentation
matters to me.

Moreover, some parts of the documentation are
generated directly from the configuration
information of the C++-sources. The amount of
this type of data even grows. E.g.: what is the
default verbosity level? 0 or 1, or what? A
wiki cannot mirror this. In fact the wiki's
contents could be downright wrong. Setting up
immutable pages counters the problem of false
information, though.

> However, it would
> be needed to update the pages first. If someone could provide me with a
> Diff of the older and the current version I could do this.

If you cannot translate it
automatically, you'll drown in different
versions. Promised!

> If you think it's better to maintain the manuals in TeX (which I believe
> is the native format) I would prefer to update the wiki with the final
> version. Unfortunately I don't know enough about TeX to do the Diff
> myself...

The GNU coding standards favor
documentation in Texinfo format. This is what
we use right now.

Furthermore, Texinfo is a powerful format, it
comes with fast translators to a variety of
output formats, and the sources are plain ASCII.
FYI, I would fight extremely hard against a
documentation format change.

To address the "collaboration" question: Anyone
can work on the documentation as they would work
on the code. There really is no difference.
Contributions are always welcome.


Cheers,
Chris

[Erik Krause]

cspiel wrote:

> Furthermore, Texinfo is a powerful format, it
> comes with fast translators to a variety of
> output formats, and the sources are plain ASCII.
> FYI, I would fight extremely hard against a
> documentation format change.
>
> To address the "collaboration" question: Anyone
> can work on the documentation as they would work
> on the code.

Well, not anyone. I for example can't. And since you asked for proof
readers which are not necessarily programmers I assume most of them
can't either. TeX is not very common among ordinary users. And you
hardly would find an non-programmer who will be willing to install a
source control system only to commit some better phrases for a manual.

On the other hand the wiki pages are pretty popular, simply because they
are easy to find. They should be up to date IMHO. However, after some
searching I found that texi2html used together with a file
"mediawiki.init" would produce mediawiki text.

Could someone with texi2html installed try to convert one of the manuals
to mediawiki text and see how it displays in the panotools wiki? Or mail
me the result off list that I can try?

[michael crane]

2009/9/8 Erik Krause <erik....@gmx.de>:

> Could someone with texi2html installed try to convert one of the manuals
> to mediawiki text and see how it displays in the panotools wiki? Or mail
> me the result off list that I can try?

I converted enblend.texi to html ok with texi2html then the perl
thingy HTML::WikiConverter::MediaWiki seemed to hang converting to
mediawiki so maybe I did something wrong not having used perl much.
I found an webbased converter for html2wiki but when I paste the
result into a mediawiki page some of the links work and some show the
links as html.It might be me not having used mediawiki 'till just now.
I'll persevere for a bit longer.

mick

[michael crane]

texi2html was moaning about lines that contain @tie

@tie{}C

maybe it is something to do with that ?
mick

[Harry van der Wolf]

Hi Mick,

 

Thanks for your attempts.

 

In the previous round (February/March 2009) is have endlessly tossed around with all kind of converters, also the one you are mentioning and also going through all kind of intermediate formats. I have almost broken my system to get the latest "bleading edge" svn/cvs versions of necessary tools but the conversion from texi to wiki (whatever rout you choose) is very cumbersome and very labour intensive. That's also the reason why I haven't started that yet and have been searching for other conversion routes or extra plugi'n's for the wiki to read/convert whatever intermediate format.

Until now: no results.

If you find some new, not so labour intensive route, from texi to wiki please let us know.

 

I support both Christoph's point of view for having the latest up-to-date versions with the source and Klaus' point of view where it comes to easy access for a broad audience.

 

Harry

 

harry

 

2009/9/9 michael crane <mick....@gmail.com>

[michael crane]

2009/9/9 Harry van der Wolf <hvd...@gmail.com>:

> If you find some new, not so labour intensive route, from texi to wiki
> please let us know.

the newest texi2html seems to make perfect html in no time at all.
texi2html 1.82.
http://www.nongnu.org/texi2html/

The online converters to mediawiki that I tried fail with some
characters missing sometimes and some of the anchor links do not
work.

http://toolserver.org/~diberri/cgi-bin/html2wiki/index.cgi

http://labs.seapine.com/htmltowiki.cgi

I think I can allow import html into my crispy new mikiwiki. I'll try
that and then see if I can export it.

regards

mick

[Erik Krause]

michael crane wrote:

> I converted enblend.texi to html ok with texi2html then the perl
> thingy HTML::WikiConverter::MediaWiki seemed to hang converting to
> mediawiki so maybe I did something wrong not having used perl much.
> I found an webbased converter for html2wiki but when I paste the
> result into a mediawiki page some of the links work and some show the
> links as html.It might be me not having used mediawiki 'till just now.

Thanks for your efforts. The current wiki pages where converted from the
HTML version using one of this online converters and then manually
corrected using TeX for the formulas taken directly from the texi docs.
The PDF version was used to proof the formula layout (wiki TeX is a bit
different to texi).

It seems as if there is some information lost in any conversion step.
Hence my hope was, that all this should be possible to do automatically
with texi2html and the help of mediawiki.init

If the result isn't usable without manual tweaking and if you decide to
not use he wiki version for proof reading and user contributions it
probably would be best to have the wiki page pointing to the versions on
panorama.dyndns.org (or any other up to date version).

However, I think you should consider it: The wiki has a nice DIFF tool
with the possibility to revert to any previous versions easily, it has
section editing and a related discussion page. And it's much easier to
use than a source control system, at least for a non-programmer.

[Yuval Levy]

Harry van der Wolf wrote:
>conversion from texi to wiki (whatever rout you choose) is very cumbersome
> and very labour intensive.

and IMO the wrong way to go about the issue. Wiki format only makes
sense if you want the pages to be editable in the Wiki. Good luck
syncing with the official documentation if you do.

IIRC it is possible to put HTML markup inside a Wiki page (which would
need to be write-protected anyway). And maybe it is also possible to
forward a Wiki page to a static HTML URL?

I'd go the route of generating automatically non-editable versions of
the official documentation.

How about parsing the generated HTML and put around it a wiki "skin",
with the same links (e.g. navigation/tools/search/toolbox) on the side?

> I support both Christoph's point of view for having the latest up-to-date
> versions with the source

+2

> Klaus' point of view where it comes to easy access for a broad audience.

+1 - a static HTML page is easy access enough. A PDF is an added bonus.
A wiki page has no benefit IMO.

Yuv

[michael crane]

2009/9/9 Yuval Levy <goo...@levy.ch>:
>

> and IMO the wrong way to go about the issue. Wiki format only makes
> sense if you want the pages to be editable in the Wiki. Good luck
> syncing with the official documentation if you do.
>

it's clear that there should be one source of documentation or it
could get silly.

I'm fiddling about with the texi, info files largely because I've no
idea till yesterday how they are done.

Can somebody explain what @ref{Figure:photographic-workflow} is ? in
workflow.texi

some programs ( texi2html, texi2dvi, texi2pdf, dvipng expect a txt
file, some a pdf, some a ps, some a jpg.

which causes an error.
I made .pdf .jpg , ps from the .fig file and they seem happy with that
but what is "supposed" to happen ?

regards

mick

[Carl von Einem]

I know nothing about Texinfo but that looks very much like QuarkXPress
"ASCII/XPress Tags" I usually work with. That's basically content as
plain ascii text files together with formatting instructions which start
with a '@'. Cool :-)

Carl

michael crane wrote:
> 2009/9/9 Yuval Levy <goo...@levy.ch>:

[Carl von Einem]

from the texinfo.pdf on page 225:

@ref{node, [entry], [node-title], [info-file], [manual]}

Make a plain reference that does not start with any special text.
Follow command with a punctuation mark. Only the first argument
is mandatory. See Section 8.6 [@ref], page 70.

and...

8.6 @ref
@ref is nearly the same as @xref except that it does not generate
a ‘See’ in the printed output, just the reference itself. This
makes it useful as the last part of a sentence. (...)

[Harry van der Wolf]

2009/9/10 Carl von Einem <ca...@einem.net>

Or to put it simple : @ref{Figure:photographic-workflow}  refers to a figure which is an eps file called "photographic-workflow.eps". You will find this "photographic-workflow.eps" in the same directory (in this "pathless"  case) as the texi file.

Harry

[michael crane]

2009/9/10 Harry van der Wolf <hvd...@gmail.com>:

> Or to put it simple : @ref{Figure:photographic-workflow}  refers to a figure
> which is an eps file called "photographic-workflow.eps". You will find this
> "photographic-workflow.eps" in the same directory (in this "pathless"  case)
> as the texi file.

there is only the .fig file there. other programs seem to expect a jpg or a pdf.
where does it say that it is an .eps.

What program is meant to view the .texi file directly in all it's
composed glory ?
I've installed so many now I'm not sure what's going on.

regards

mick

[Carl von Einem]

Harry van der Wolf wrote:
>
>

> 2009/9/10 Carl von Einem <ca...@einem.net <mailto:ca...@einem.net>>

>
>
> from the texinfo.pdf on page 225:
>

> (...)
> >
> > michael crane wrote:
> >> 2009/9/9 Yuval Levy <goo...@levy.ch <mailto:goo...@levy.ch>>:

> >>
> >> Can somebody explain what @ref{Figure:photographic-workflow} is ? in
> >> workflow.texi
>
>
> Or to put it simple : @ref{Figure:photographic-workflow} refers to a
> figure which is an eps file called "photographic-workflow.eps". You will
> find this "photographic-workflow.eps" in the same directory (in this
> "pathless" case) as the texi file.
>
> Harry

That was too simple ;-)
I haven't worked out that .eps part I must admit, and texi is really
interesting!

[Harry van der Wolf]

2009/9/10 michael crane <mick....@gmail.com>

2009/9/10 Harry van der Wolf <hvd...@gmail.com>:

> Or to put it simple : @ref{Figure:photographic-workflow}  refers to a figure
> which is an eps file called "photographic-workflow.eps". You will find this
> "photographic-workflow.eps" in the same directory (in this "pathless"  case)
> as the texi file.

there is only the .fig file there. other programs seem to expect a jpg or a pdf.
where does it say that it is an .eps.

Sorry. I didn't pay attention well enough. You are working with the source of the documentation and not with the generated documentation when you build enblend.

 

What program is meant to view the .texi file directly in all it's
composed glory ?
I've installed so many now I'm not sure what's going on.

regards

mick

As far as I know texi is only the text formatting ascii file which you edit in a ascii editor like vi(m). You must first convert it to texinfo (makeinfo file.texi) or to pdf (texi2pdf file.texi) or to html (texi2html) or to whaever format.
I suppose you already read <http://en.wikipedia.org/wiki/Texinfo>.

At that stage I looked at texi to xml and xml to wiki as there are converters for that, but none is really sufficient.
Also texi to html to wiki as there are also converters for that but none really sufficient.

I'm sorry I can't help. I could only give some explanations.
I hope you find something useful.

Harry

[Harry van der Wolf]

Yes, you are right. I was mistaken. I thought Mick was working on the genreated documentation, not on the source document data.

Harry

[michael crane]

2009/9/10 Harry van der Wolf <hvd...@gmail.com>:
>
>

> 2009/9/10 Carl von Einem <ca...@einem.net>
>>
>
>
>

> Yes, you are right. I was mistaken. I thought Mick was working on the
> genreated documentation, not on the source document data.

'working' is the wrong expression. "rag in teeth ?" "gnawing on bone ?"

so what is the way to view the document in all it's composed glory ?

"man" shows some of it
"info" shows some of it
"perldoc" shows some of it but I forget the syntax
?
mick

[cspiel]

Michael -

On Sep 10, 11:08 pm, michael crane <mick.cr...@gmail.com> wrote:
> so what is the way to view the document in all it's composed glory ?

As a long time user of Texinfo, I'd say
the question is not well defined. Please let me
explain why.

Texinfo as a file format is powerful enough
encode different output for different target
formats. The key point is that we can run
various translators on Texinfo source files to
produce for example
Info,
Plain text,
HTML, XML,
DVI, PS,
PDF, and
DocBook
documentation. Each of these can in theory
contain different contents, though they were
generated from the _same_ Texinfo source,
because we can select what gets processed with
so called "Conditional Commands". like, e.g.,
@ifhtml
...
@end ifhtml
or
@iftex
...
@end iftex

What looks like sheer exuberance at first glance
actually makes sense if you want e.g. to show a
graphic. It is easy to show it in HTML. With a
simple conversion it is as easy to include it in
the PostScript and PDF variants, too, but what
about the text based formats? Here, either your
generator program for the graphic helps you (as
e.g. Gnuplot does) or you have to draw corny
ASCII line art (which is done for all Fig-files
of the documentation).

Moreover, the freedom to select particular
presentations for a specific output translation
allows the savvy documentation author to optimize
the target representation. Mathematical
formulas in particular benefit from this
treatment.

So, to finally answer your question: In the
general case there is no one and only document
that represents a set of Texinfo files. And
this is a good thing.

> "man" shows some of it
> "info" shows some of it
> "perldoc" shows some of it but I forget the syntax

Some of my favorites are
- Acrobat for PDF
- Ghostview (and Evince) for PostScript
- pinfo and Emacs for Info
- Firefox for XML&MathML

Usually the PDF and the HTML/XML are the richest
target formats. It has been a larger effort to set up the
Enblend/Enfuse documentation with that much of
flexibility. Now you can choose your preferred format
and enjoy reading.

I hope I could clarify the issue.

Cheers,
Chris

[michael crane]

2009/9/11 cspiel <csp...@freenet.de>:

>
> Michael -
>
> On Sep 10, 11:08 pm, michael crane <mick.cr...@gmail.com> wrote:
>> so what is the way to view the document in all it's composed glory ?
>
>        As a long time user of Texinfo, I'd say
> the question is not well defined.  Please let me
> explain why.

<snipped useful stuff>

these are the files

in enblend/doc

authors.texi entropy.gp.in sharp-edge.gp.in
auxmac.tex fdl.texi smooth-edge.data
auxmac.texi focus-stack-decision-tree.fig smooth-edge.gp.in
config-edge.gp gaussian.gp.in tidy.cfg
config.gp helpful-programs.texi tuning-memory-usage.texi
default.css laplacian-of-gaussian.gp.in understanding-masks.texi
enblend.info local-analysis-window.fig versenblend.texi
enblend.texi Makefile.am versenfuse.texi
enfuse.info mask-template-characters.texi workflow.texi
enfuse.texi photographic-workflow.fig
entropy-cutoff.gp.in sharp-edge.data

Which pogram do I use to print to screen the enblend documentation
showing all the equations and illustrations?

regards

mick

[Bruno Postle]

On Fri 11-Sep-2009 at 12:25 +0100, michael crane wrote:
>
>these are the files
>in enblend/doc

[snip]

>Which pogram do I use to print to screen the enblend documentation
>showing all the equations and illustrations?

The docs are integrated in the build system, you should be able to
do something like this (untested):

make -f Makefile.scm
./configure
cd doc
make pdf

--
Bruno

[michael crane]

2009/9/11 Bruno Postle <br...@postle.net>:

>
> On Fri 11-Sep-2009 at 12:25 +0100, michael crane wrote:
>>
>>these are the files
>>in enblend/doc
>
> [snip]
>
>>Which pogram do I use to print to screen the enblend documentation
>>showing all the equations and illustrations?
>
> The docs are integrated in the build system, you should be able to
> do something like this (untested):
>
>   make -f Makefile.scm

aclocal -I m4
autoheader
automake --add-missing
doc/Makefile.am:132: user target `enblend.dvi' defined here...
/usr/share/automake-1.9/am/texibuild.am: ... overrides Automake target
`enblend.dvi' defined here
doc/Makefile.am:148: user target `enfuse.dvi' defined here...
/usr/share/automake-1.9/am/texibuild.am: ... overrides Automake target
`enfuse.dvi' defined here
autoconf

>   ./configure

..........................
OPENGL_LIBS: -lGLEW
EXTRA_LIBS (optional): <none selected>

can build all documentation: yes

feature selection:
split *.info and *.html files: yes
enable debugging support: no
enable malloc debugging: no
OpenEXR image format yes
use image cache: yes
build GPU acceleration: no, because of missing GLUT
use OpenMP: no

>   cd doc
>   make pdf
.................
Package thumbpdf Warning: Thumbnail data file `enfuse.tpt' not found.

)) (/home/mick/hugin_src/enblend/doc/../texinfo.tex
Loading texinfo [version 2005-07-05.19]: Basics, pdf,
(/usr/share/texmf/tex/plain/pdfcolor/pdfcolor.tex) fonts, page headings,
tables, conditionals, indexing, sectioning, toc, environments, defuns, macros,
cross references, insertions, (/usr/share/texmf/tex/generic/epsf/epsf.tex)
localization, and turning on texinfo input format.) (./auxmac.texi)
(./versenfuse.texi) [1{/usr/share/texmf-var/fonts/map/pdftex/updmap/pdftex.map}
] [2] [-1] [-2] (List of Tables) (List of Figures) [-4] Chapter 1 [-5]
Cross reference values unknown; you must run TeX again. [1] Chapter 2 [2]
(./workflow.texi
Error: pdfetex (file photographic-workflow.pdf): cannot find image file
==> Fatal error occurred, the output PDF file is not finished!
/usr/local/bin/texi2dvi: pdfetex exited with bad status, quitting.
make: *** [enfuse.pdf] Error 1

there is a photographic-workflow.png file in the directory
the enblend.pdf that is made is corrupt and will not open
if I put a photographic-workflow.pdf in the directory

and type

make pdf
.............

Transcript written on enblend.log.
/usr/local/bin/texi2dvi: pdfetex exited with bad status, quitting.
make: *** [enblend.pdf] Error 1

I get an enblend.pdf but I don't know if it is complete.
I'll put it here
http://www.panagito.com/MISC/enblend5.pdf
regards

mick

>
> --
> Bruno

[Harry van der Wolf]

I get an enblend.pdf but I don't know if it is complete.
I'll put it here
http://www.panagito.com/MISC/enblend5.pdf
regards

mick


>
> --

> Bruno

--

Hi Mick,

I understood that you really wanted to build everything yourself. If you want a complete generated docset, go to my webpage <http://panorama.dyndns.org/EandE-documentation/>

You find everything there and you can also download the complete pre-compiled set in a .tgz (botom of page)

Harry

[michael crane]

2009/9/11 Harry van der Wolf <hvd...@gmail.com>:

Hi,
Yes I saw that earlier. I started seeing if I could help by generating
a wikipage from the sources
but I'm having problems understanding how it's done.

regards

mick
> Harry

[michael crane]

so any idea why I get an error building the pdf ?

I assume enblend can be built separately ? without all the hugin stuff ?

I tried to build Hugin but I have freeglut not glut and it won't work.
Is there a way to say use freeglut ?

regards

mick

[Harry van der Wolf]

2009/9/12 michael crane <mick....@gmail.com>

so any idea why I get an error building the pdf ?

I get the exact same errors you get and I'm on OSX. They are from the transfig package. I'm using transfig 3.2.5_1 which is the latest main version. the subversion (not svn) is now at 3.2.5_3 or something .

 

I assume enblend can be built separately ? without all the hugin stuff ?

hugin stuff ? You don't need to build hugin for enblend. enblend/enfuse is  a stand-alone package.
 

I tried to build Hugin but I have freeglut not glut and it won't work.
Is there a way to say use freeglut ?

Last time I built on Linux I used freeglut. Just tried on my Intrepid server and Jaunty virtual machine, but it doesn't build anymore. I suppose someone changed that.

Harry

[Kornel Benko]

Am Samstag 12 September 2009 schrieb Harry van der Wolf:
> 2009/9/12 michael crane <mick....@gmail.com>
>
> > so any idea why I get an error building the pdf ?
> >
> > I get the exact same errors you get and I'm on OSX. They are from the
>
> transfig package. I'm using transfig 3.2.5_1 which is the latest main
> version. the subversion (not svn) is now at 3.2.5_3 or something .
>
> > I assume enblend can be built separately ? without all the hugin stuff ?
>
> hugin stuff ? You don't need to build hugin for enblend. enblend/enfuse is
> a stand-alone package.
>
> > I tried to build Hugin but I have freeglut not glut and it won't work.
> > Is there a way to say use freeglut ?

You need the development version of freeglut. Something like freeglut3-dev and libglut3-dev on ubuntu.

> Last time I built on Linux I used freeglut. Just tried on my Intrepid
> server and Jaunty virtual machine, but it doesn't build anymore. I suppose
> someone changed that.
>
> Harry

Kornel

--
Kornel Benko
Kornel...@berlin.de

[michael crane]

2009/9/12 Kornel Benko <Kornel...@berlin.de>:

> You need the development version of freeglut. Something like freeglut3-dev
> and libglut3-dev on ubuntu.

I thought I had the devel package but apparently not.
but now it says.

[mick@xxxx:~/hugin_src/hugin]$ cmake -DCMAKE_INSTALL_PREFIX=/usr/local
-- Current SVN revision is 4385
LOG2 1
-- Found wxWidgets: TRUE
-- Found TIFF: /usr/include
-- Found JPEG: /usr/include
-- Found PNG: /usr/include
-- WARNING: you are using the obsolete 'PKGCONFIG' macro use FindPkgConfig
-- Found OPENEXR:
/usr/lib/libImath.so;/usr/lib/libIlmImf.so;/usr/lib/libIex.so;

/usr/lib/libHalf.so;/usr/lib/libIlmThread.so
-- GLUT Found
-- Found Glew:
-- Boost version: 1.33.1
-- Found the following Boost libraries:
-- thread
-- Program msgfmt found (/usr/bin/msgfmt)
-- Using shared internal libraries
CMake Error: The following variables are used in this project, but
they are set to NOTFOUND.
Please set them or make sure they are set and tested correctly in the
CMake file s:
GLUT_Xmu_LIBRARY (ADVANCED)
linked by target "align_image_stack" in directory
/home/mick/hugin_src/hugin
/src/tools
linked by target "nona" in directory /home/mick/hugin_src/hugin/src/tools
linked by target "hugin" in directory
/home/mick/hugin_src/hugin/src/hugin1/
hugin
linked by target "nona_gui" in directory
/home/mick/hugin_src/hugin/src/hugi
n1/nona_gui

-- Configuring incomplete, errors occurred!

regards

mick

[Kornel Benko]

This one is here set to /usr/lib/libXmu.so, which is part of libxmu-dev on ubuntu.
...
>
> regards
>
> mick