[hugin-ptx] Re: buliding panomatic fails on Ubuntu 9.10 / AMD64

[Kornel Benko]

Am Sonntag 04 Oktober 2009 schrieb marc:
> Hi Yuv,
>
> I used the following patches to files in subfolder panomatic/tclap.
> it seems to work, but this is mostly a guess of what the functions
> should do.
>
> marc
...
> > ./tclap/ValueArg.h:103: error: ‘EOF’ was not declared in this scope
> > In file included from ./tclap/UnlabeledMultiArg.h:29,
> >   from tclap/CmdLine.h:29,
> >   from main.cpp:25:

Maybe a include of a header file which defines EOF would be more appropriate.
I don't have ubuntu 9.10, only 9.04. Here it is defined in 
"/usr/include/stdio.h"


Kornel
-- 
Kornel Benko
kornel.be...@berlin.de


signature.asc
Description: This is a digitally signed message part.

Re: man pages (was Re: [hugin-ptx] Re: here we go again)

[Yuval Levy]

thanks for the investigations, Jean-Luc

Jean-Luc Coulon (f5ibh) wrote:
> * po4a can manage the following format:

more than what we need.

I'd appreciate if at the end of your investigation you could suggest 
which format to use and how.


> We needs 
> 1 - export mediawiki existing pages
> 2 - convert them to a user (and program) firendly format (neutral 
> format)
> 3 - convert them to .pot/.po using po4a
> 4 - tranlate then (easy ;) )
> 5 - convert them back to the neutral format)
> 6 - import them in the mediawiki.

would the user (and program) friendly format in step 2 be the single 
source then, from which the target formats like mediawiki, PDF, HTML, 
etc. would be generated?

Yuv

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

Re: man pages (was Re: [hugin-ptx] Re: here we go again)

[Yuval Levy]

Bruno Postle wrote:
> I'll just explain how the manual is done at the moment, there are 
> obviously flaws in this approach, but it does result in a usable 
> help menu in the Hugin application itself.

thanks for the explanation. I think it would make sense to document this 
somewhere - either in the translator handbook or in the development 
process document.


> The advantage of importing the wiki into SVN is that (in principle) 
> the wiki tracks development and the snapshot that goes into the 
> release is relevant to that release - i.e. people using 0.7.0 will 
> find that the help-menu version of the manual makes more sense than 
> the newer pages in the wiki.

I'd be inclined to add another advantage: editors and translators have 
more affinity with a wiki (similar to a text editor; very direct access) 
than the mediated access through SVN.

On the other hand, it would be cleaner if the process worked the other 
way around, with a single source format translated to different output 
formats, including wiki and bundled handbook (which could be done in 
HTML but also as a large single HTML page and as a PDF).

Yuv

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

[hugin-ptx] Re: (Probably very basic) help needed for build process on WinXP: missing files?

[Yuval Levy]

Hallo Joachim,

J. Schneider wrote:
> real life interfered a bit in the meantime but now I am back. And next 
> weekend I'm going to help my sister move all across Germany and won't be 
> at home much, but anyway, step by step ...

I hope the move went well and you did not have the same weather we're 
having here (pouring rain, and cold wind).


>> * wxWidgets-2.9.10  wxWidgets-2.8.10

...

> So the only difference is the wxWidgets version. Don't ask me why it 
> wasn't there before.

I think this was a typo of mine. It is 2.8.10 here too. That said, 
wxWidgets evolves steadily and improves the user interface to Hugin, so 
it is good to know / document how to build the latest stable version, 
which currently is 2.9.0, released 2009-09-08. Info on releases at 
http://www.wxwidgets.org/ and http://trac.wxwidgets.org/wiki/Roadmap

...

> ..\..\include NO

if I am not mistaken we can ignore this one.


> ..\..\tiff-3.8.2\libtiff  NO but now changed to
>..\..\wxWidgets-2.8.10\src\jpeg

I don't think it will work, and anyway it is not a good thing to do. 
libtiff inside wxWidget is 3.6.1, very old. 3.8.2 was the current stable 
version in 2007 IIRC. In the meantime it's 3.9.1 and they are already 
releasing 4.0.0 beta.

There is a libtiff-3.8.2 in my SDK folder. I don't recall its origin, 
but I have built 3.9.1 and replaced it successfully:

* homepage: http://www.libtiff.org/
* master download site ftp://ftp.remotesensing.org/pub/libtiff/
* download tiff-3.9.1.zip
* unpack into SDK folder
* inside tiff-3.9.1 folder, edit nmake.opt and add JPEG support and ZLIB 
support:

JPEG_SUPPORT= 1
JPEGDIR = ../../wxWindows-2.8.10/src/jpeg
JPEG_INCLUDE= -I$(JPEGDIR)
JPEG_LIB= ../../wxWindows-2.8.10/lib/wc_lib/wxjpeg.lib

ZIP_SUPPORT = 1
ZLIBDIR = ../../wxWidgets-2.8.10/src/zlib
ZLIB_INCLUDE= -I$(ZLIBDIR)
ZLIB_LIB= ../../wxWidgets-2.8.10/lib/vc_libwxzlib.lib

* start a MSVC shell
* execute the following commands
   VCVARSALL
* cd into the tiff folder
* execute the following commands
  nmake /f makefile.vc clean
  nmake /f makefile.vc

It will fail (while building some tools), but all we need is the library 
and it is produced before.

If you are using anything else but tiff-3.8.2, remember to adjust the 
project properties (C/C++ and Linker for each target) in MSVC before 
launching the build.

One thing I saw different in 3.9.1 from 3.8.2 is support for JBIG-KIT, a 
lossless type of compression. It seems to be patent-encumbered until 
February 2011, so I did not investigate further its use (but may be 
interesting later on)


> ..\..\lcms-1.18\include   YES

did you document the instructions for this in the wiki (do you edit as 
you go along) ?



> 1. STLport
>>> ..\..\STLport-trunk\stlport   NO
>> ok, we'll need to build that one. Instructions for 64 bit are at 
>> 
>> we'll need to adapt them for 32bit.
> Suppose this is just exchanging "x64" with "x32"
>> ... get them with SVN from 
>> https://stlport.svn.sourceforge.net/svnroot/stlport/trunk/STLport 
> OK. Rev 6512. I have got STLport now in my huginbase. Is it later to be 
> renamed STLport-trunk?

yes.

> 
>> the instructions to build it are in the INSTALL file, and make use of 
>> nmake (that you have installed with MSVC).
> What I read on the wiki page mentioned above seems to be the same in 
> short. Am I going to build the STLport iostreams library?

Is that what is said in stloport-trunk\INSTALL ?


> Anyway on the MSVC command line I get:
> setenv: The command was either misspelled or couldn't be found.
> Looks like I started somehow completely wrong.

where in the instructions did you find "setenv" ? have you followed the 
instructions in stlport-trunk\INSTALL ?

I see that STLport released 5.2.1 recently
http://sourceforge.net/projects/stlport/files/

might be a good idea to switch from SVN to 5.2.1 and see if it is good 
enough, rather than deal with the rough edges of an SVN checkout.


> 2. libxmi-1.2
>>> ..\..\libxmi-1.2  NO
>> 
>>
>> You can download it from 
>> http://sourceforge.net/projects/gnuwin32/files/libxmi/1.2-1/libxmi-1.2-1-src.zip/download
> OK, now I have libxmi-1.2-1 in my huginbase,
> 
>> there is a libxmi.sln inside it, IIRC you just need to start it. 
> No. But the wiki says, I have to apply the libxmi-1.2.diff patch.
> Where do I get it and how to apply a patch?

I think the patch is for 64bit. you don't need to patch for your 32bit 
Windows XP. is there no libxmi.sln inside?


> 3. glut
>>> ..\..\glut\includeNO
>> http://www.xmission.com/~nate/glut.html - I am not sure if just 
>> unpacking the bin.zip file inside huginbase will be enough. try that. if 
>> it does not work, get src.zip, there are instructions ins

[hugin-ptx] Re: here we go again

[RizThon]

> > I feel we should say that english is our "primary" language, meaning it's
> > the most up-to-date version, so that every translator, who's supposed to
> > understand English, can update his/her part.
>
> that's one way to do it. but what if a Russian speaking person come up
> with a much better text / idea? I don't think we should limit the
> creativity of our international users by focusing on a "primary"
> language. English is a good lingua franca; and the application's
> language is primarily English. But for the handbooks and tutorials I
> prefer to see the international creativity set free. If a tutorial in
> Traditional Chinese is better than what we have in English, somebody
> will translate it to English. And if French users prefer a different
> style of tutorials than German users, who am I to impose a uniform style
> and translation?
>
We could at least say on the Wiki that it's better to try and improve the
English version at the same time as your own language version. And if you
make some new documents (tutorial, ...) in your own language, it would be
good to also translate them into English. So no "You must do that!!!" but
more "It would be better to do that."

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

[hugin-ptx] Re: [OSX] hugin-mac-2009.4.0-Beta1 for download

[AKS-Gmail-IMAP]

Thank you again for your seemingly tireless efforts to compile Hugin  
OS X.  I have been stitching scores of rough hand held images lately  
and there have been a few very difficult scenes that would not come  
together without considerable effort.  I tested this new version on  
the worst of these. The new Clean Points feature makes an amazing  
difference. These difficult scenes were now previewing right after the  
first optimization pass.

Thanks,
Allan


On Oct 3, 2009, at 3:59 PM, Harry van der Wolf wrote:

> Hi Mac users,
>
> I just published the new 32bit Hugin 2009.4-Beta1 bundle.
>
> See the Changelog: 
>   
> >
>
> Note: This build features the new Autopano generator setup.
>
>
> Please test and give feedback.
>
> Information and binaries via my website
>  >.
> (The binaries itself are, as always, served from hugin.panotools.org  
> who kindly provide the disk space and bandwidth).


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

[hugin-ptx] Re: buliding panomatic fails on Ubuntu 9.10 / AMD64

[marc]

Hi Yuv,

I used the following patches to files in subfolder panomatic/tclap.
it seems to work, but this is mostly a guess of what the functions
should do.

marc

*** ValueArg.h~ 2008-02-26 00:35:12.0 +0100
--- ValueArg.h  2009-10-04 04:59:32.0 +0200
***
*** 100,106 
  int valuesRead = 0;
  while ( is.good() )
{
! if ( is.peek() != EOF )
  is >> _value;
  else
  break;
--- 100,107 
  int valuesRead = 0;
  while ( is.good() )
{
! //if ( is.peek() != EOF )
! if ( ! is.eof() )
  is >> _value;
  else
  break;


*** MultiArg.h~ 2008-02-26 00:35:12.0 +0100
--- MultiArg.h  2009-10-04 04:59:50.0 +0200
***
*** 100,107 

while ( is.good() )
{
!   if ( is.peek() != EOF )
!   is >> temp;
else
break;

--- 100,108 

while ( is.good() )
{
!   //if ( is.peek() != EOF )
!   if ( ! is.eof() )
!   is >> temp;
else
break;




On Sep 26, 9:28 pm, Yuval Levy  wrote:
> it builds on Ubuntu 9.04 and my 32bit dyno-book. but on my 64bit box it
> fails with the following error:
>
> In file included from ./tclap/UnlabeledValueArg.h:30,
>                   from tclap/CmdLine.h:28,
>                   from main.cpp:25:
> ./tclap/ValueArg.h: In member function ‘int
> TCLAP::VALUE_ARG_HELPER::ValueExtractor::extractValue(const
> std::string&)’:
> ./tclap/ValueArg.h:103: error: ‘EOF’ was not declared in this scope
> In file included from ./tclap/UnlabeledMultiArg.h:29,
>                   from tclap/CmdLine.h:29,
>                   from main.cpp:25:
> ./tclap/MultiArg.h: In member function ‘int
> TCLAP::MULTI_ARG_HELPER::ValueExtractor::extractValue(const
> std::string&)’:
> ./tclap/MultiArg.h:103: error: ‘EOF’ was not declared in this scope
> In file included from PanoDetector.h:31,
>                   from main.cpp:32:
> ../zthread/include/zthread/PoolExecutor.h: At global scope:
> ../zthread/include/zthread/PoolExecutor.h:58: warning:
> ‘ZThread::PoolExecutor’ has a field ‘ZThread::PoolExecutor::_impl’ whose
> type uses the anonymous namespace
> make[1]: *** [main.o] Error 1
> make[1]: Leaving directory
> `/home/yuv/src/panomatic/panomatic-0.9.4/panomatic'
> make: *** [all-recursive] Error 1
>
> any idea?
> Yuv
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
"hugin and other free panoramic software" group.
A list of frequently asked questions is available at: 
http://wiki.panotools.org/Hugin_FAQ
To post to this group, send email to hugin-ptx@googlegroups.com
To unsubscribe from this group, send email to 
hugin-ptx-unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~--~~~~--~~--~--~---

Re: man pages (was Re: [hugin-ptx] Re: here we go again)

[Bruno Postle]

On Sat 03-Oct-2009 at 15:39 +0200, Jean-Luc Coulon (f5ibh) wrote:
>
>* For the wiki:
>We have tho think if the wiki format is the only needed one, or if wee
>need other output formats.

I'll just explain how the manual is done at the moment, there are 
obviously flaws in this approach, but it does result in a usable 
help menu in the Hugin application itself.

The manual is just a scraped selection of pages and accompanying 
images from the panotools wiki: http://wiki.panotools.org/

We don't want everything from the wiki, it is mostly not relevant.  
There are two types of pages we use:

There are very Hugin specific pages.  These are a bit behind at the 
moment and are currently at the 0.8.0 level, they need some work to 
refer to 2009.2.0 and 2009.4.0 features: 
http://wiki.panotools.org/Category:Software:Hugin

There are general 'glossary' pages, explanations of terms and 
concepts (this is what the wiki was created for in the first place, 
most users of the wiki don't use Hugin): 
http://wiki.panotools.org/Category:Glossary

The list of pages we use are maintained in the 'pages.txt' file and 
they are scraped directly from the web-site with 'fetch.sh' and 
'dewiki.pl'.

The advantage of importing the wiki into SVN is that (in principle) 
the wiki tracks development and the snapshot that goes into the 
release is relevant to that release - i.e. people using 0.7.0 will 
find that the help-menu version of the manual makes more sense than 
the newer pages in the wiki.

-- 
Bruno

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

[hugin-ptx] [OSX] hugin-mac-2009.4.0-Beta1 for download

[Harry van der Wolf]

Hi Mac users,

I just published the new 32bit Hugin 2009.4-Beta1 bundle.

See the Changelog: <
http://groups.google.com/group/hugin-ptx/browse_thread/thread/cd7d3d242821bdc
>

*Note: This build features the new Autopano generator setup.*


Please test and give feedback.

Information and binaries via my website
.
(The binaries itself are, as always, served from hugin.panotools.org who
kindly provide the disk space and bandwidth).

Hoi,
Harry

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

[hugin-ptx] Re: Oups, I've added two strings!

[Yuval Levy]

Jean-Luc Coulon (f5ibh) wrote:
> Sorry, but I want to checkout the related branch but I'm not sure which 
> one it is...
> 
> is it hugin/2008.4/obsolete_branches/  ?

please work in trunk. I don't know where you get the above path from, it 
does not exist.

Yuv

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

[hugin-ptx] Re: Oups, I've added two strings!

[Jean-Luc Coulon (f5ibh)]

Le 01/10/2009 22:45:44, Yuval Levy a écrit :
>
>Hi all, particularly translators.
>
>I have done something that is not very nice IMO: i've just added two
>new 
>strings to the release branch (and to trunk, but that's less critical) 
>after syncing the PO files and calling for translation.


Sorry, but I want to checkout the related branch but I'm not sure which 
one it is...

is it hugin/2008.4/obsolete_branches/  ?

Regards

Jean-Luc


pgpt9KZIWSTY4.pgp
Description: PGP signature

[hugin-ptx] Re: Oups, I've added two strings!

[Yuval Levy]

Kornel Benko wrote:
> Am Samstag 03 Oktober 2009 schrieb Yuval Levy:
>> #define _t(String) gettext (String)
>>
>> sounds the same like with the log2 thing. I'll try to solve it the same
>> way we solved that.
> 
> I think, it is not the same. Here it is defined in wx/intl.h as a macro  (not 
> a function)

AFAIK wx/intl.h is wxWidgets' own implementation of gettext. But we 
don't want to make non-GUI stuff dependent on wxWidgets. This is the 
reason why non-GUI stuff is currently non translatable. IMO making it 
translatable is a good thing. Making it wx-dependent is not.

Hence I linked directly to gettext with
#include 

that's the first error on Windows: CMake does not seem to tell directly 
where gettext is (even though IIRC we have it in the SDK).

the second error, which I think is the same like the log2 thing, is 
completely unrelated to the CMake build.

It is similar to the log2 thing in that Hugin defined it as a macro in 
FreeBSD and as a function in Windows.

anyway, I will look into this as soon as I am on the Windows side of 
things again.

Yuv

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

[hugin-ptx] Re: here we go again

[Yuval Levy]

RizThon wrote:
> Would this mean that we would use po4a to manage the translation of the
> wiki?

I am no po4a expert, but I doubt this would work. I think we'd use po4a 
to manage the translations inside the SVN repository. I like how things 
are linked and managed in Enblend (though I don't think Enblend is 
translated?).


> Has I don't really have the courage (yet?) to really dive into Hugin code, I
> try to help where I can, meaning for translations and enhancing the wiki.

thank you, every help is appreciated.


> If we knew which string correspond to the GUI (meaning which strings are
> really useful for the user), we would be able to compute a percentage or
> something...We should really try to pin down those "useful" string and add a
> keyword to them in the comment part of the po file.

You can also add indications, and complete the important terms, in the 
translation [guide] on the wiki.

> That way translators will know exactly which strings are mandatory.

Use/update the [guide].


 or about a manual that refers to Hugin 0.5?
> That's a lot worse (I feel) than having a not fully translated GUI, as it
> shows that the project isn't really well supported / updated. Also it's most
> probably useless...

agree. this is why I would like to separate the manual translation from 
the application. we can have a supported / updated application; ten 
languages that are supported and updated almost in sync; and then two 
languages that are stale. The stale parts taint on the reputation of the 
whole.


> The problem of a wiki is really to update it. At least with your code, it
> first need to compile, and you also have tests. For the wiki you have
> nothing, and unless you *stumbles* upon an old page, you have no way to know
> it's there and it needs to be updated...I guess if we want to have a good
> wiki, we need someone (or several) to review it from time to time...

updating is a problem of both wiki and code. They just require different 
type of reviews. I look at the documentation that we have of the [build] 
process and I constantly see little things that become outdated, could 
use some care, etc.


> The only thing we can do about it is tell the user that unfortunately the
> translation in his/her language isn't fully up-to-date (we're an open source
> project and don't pay translators, but if you can understand english, you
> can help us, blablabla). Then he/she would choose a language accordingly.

the most explicit way to tell that is to remove the translation all 
together (and avoid the overall impression of being outdated). The 
outdated translation may be useful for a new translator not to start 
from scratch though, this is why I would not like deleting it.


> What I don't really like in wikipedia is that articles are not translated
> from one language to the other (but it would be hard to maintain if you
> don't set a "primary" language) but are quite often totally different: not
> the same layout, not the exactly the same info.

that's a problem with most multi-language website (actually all that I 
have seen). the system is not set for exact translations, so unless you 
control your contributors (which is not the case in open source) there 
is no way to guarantee that they "follow the rule" and translate (rather 
than create). and I understand them: I'd rather create original content 
in my language than translate somebody's else content.


> I feel we should say that english is our "primary" language, meaning it's
> the most up-to-date version, so that every translator, who's supposed to
> understand English, can update his/her part.

that's one way to do it. but what if a Russian speaking person come up 
with a much better text / idea? I don't think we should limit the 
creativity of our international users by focusing on a "primary" 
language. English is a good lingua franca; and the application's 
language is primarily English. But for the handbooks and tutorials I 
prefer to see the international creativity set free. If a tutorial in 
Traditional Chinese is better than what we have in English, somebody 
will translate it to English. And if French users prefer a different 
style of tutorials than German users, who am I to impose a uniform style 
and translation?

What counts to me is that
1. things are up to date or out of sight - bad quality translations 
taint the overall image of the project.
2. different language communities are empowered to create content around 
Hugin, not constrained
3. internationalization of the code is manageable
4. possibly a single source for the more technical stuff (like manpage, 
help, etc.)
5. handbook is sperated from code but available for co-distribution


> What we need to know is when a translated page is outdated, so that
> translators can work on it.

there is a very low tech way to do that: the TODO file :-)


> *The po4a (po for anything) project goal is to ease translations (and more
> interestingly, the maintenance of translations)

[hugin-ptx] Re: improving Hugin's responsiveness - patch attached

[James Legg]

On Sat, 2009-10-03 at 16:43 +0100, James Legg wrote:
> On Fri, 2009-10-02 at 23:57 -0400, Yuval Levy wrote:
> > Hi all,
> > 
> > One thing that bothers me about Hugin is how slow it is in opening the 
> > fast (pun intended) preview. Start Hugin. Load a project. Click on the 
> > fast preview icon and wait. Wait. Starr at the status bar with the (not 
> > yet localized ;-) ) "Loading image:" messages, while one image after the 
> > other is loaded. And the Ubuntu equivalent of the sandglass trying to 
> > hypnotize me...
> > 
> I'll try to make a patch to use the small image cache in the fast
> preview where it doesn't reduce image quality.

With the attached patch the fast preview uses the small images. If they
are smaller than the texture it wants to produce, it uses the large
image as it did previously instead.

This means:
 1. Loading one preview speeds up loading the other.
 2. Loading the fast preview speeds up display of the image previews
in the images tab, just like the traditional preview.
 3. If Yuv's patch is modified to generate the small images, the
fast preview will (in general) display much faster with large
projects. The traditional preview would be faster if the small
images were loaded in the background too.
 4. The fast preview does not loose any more image quality than it
did previously.
 5. Without having the small images cached to start with, loading
the fast preview is a little slower, as it has to scale images
twice instead of once.

-James

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

Index: src/hugin1/hugin/TextureManager.cpp
===
--- src/hugin1/hugin/TextureManager.cpp	(revision 4566)
+++ src/hugin1/hugin/TextureManager.cpp	(working copy)
@@ -591,7 +591,6 @@
 // add more detail textures. We need to get the biggest one first.
 // find the original image to scale down.
 // TODO cache full texture to disk after scaling?
-// TODO use small image if don't need bigger?
 // It is also possible to use HDR textures, but I can't see the point using
 // them as the only difference on an LDR display would be spending extra 
 // time reading the texture and converting the numbers. (float and uint16)
@@ -599,10 +598,24 @@
 ImageCache::getInstance().softFlush();
 DEBUG_INFO("Loading image");
 std::string img_name = src_img.getFilename();
-ImageCache::EntryPtr entry = ImageCache::getInstance().getImage(img_name);
-DEBUG_INFO("Converting to 8 bits");
-boost::shared_ptr img = entry->get8BitImage();
-boost::shared_ptr mask = entry->mask;
+// Use the small image cache if it is large enough.
+ImageCache::EntryPtr small_entry = ImageCache::getInstance().getSmallImage(img_name);
+boost::shared_ptr small_img = small_entry->get8BitImage();
+boost::shared_ptr img;
+boost::shared_ptr mask;
+if (small_img->height() >= height &&
+small_img->width() >= width)
+{
+img = small_img;
+mask = small_entry->mask;
+}
+else
+{
+// load the full image, since the small one is too small.
+ImageCache::EntryPtr entry = ImageCache::getInstance().getImage(img_name);
+img = entry->get8BitImage();
+mask = entry->mask;
+}
 // first make the biggest mip level.
 int wo = 1 << (width_p - min), ho = 1 << (height_p - min);
 if (wo < 1) wo = 1; if (ho < 1) ho = 1;
@@ -627,23 +640,15 @@
 }
 }
 } else {
-// I think this takes to long, although it should be prettier.
-/*vigra::resizeImageLinearInterpolation(srcImageRange(*img),
+// rescale
+vigra::resizeImageLinearInterpolation(srcImageRange(*img),
destImageRange(out_img));
 if (has_mask)
 {
-vigra::resizeImageLinearInterpolation(srcImageRange(*(entry->mask)),
-  destImageRange(out_alpha));
-}*/
+vigra::resizeImageLinearInterpolation(srcImageRange(*(mask)),
+  destImageRange(*out_alpha));
+}
 
-// much faster. It shouldn't be so bad after it
-vigra::resizeImageNoInterpolation(srcImageRange(*img),
-  destImageRange(out_img));
-if (has_mask)
-{
-vigra::resizeImag

[hugin-ptx] Re: improving Hugin's responsiveness - patch attached

[Yuval Levy]

Harry van der Wolf wrote:
> WOW! We have a new programming kid on the block!

not so fast. I am just "hacking around" (and I hope to find the time to 
write in my blog a "hacking Hugin for dummies" kind of article).

> Well done.

thanks.


> It compiles and works fine as well on OSX, both via a cmake build and an
> XCode build.
> It seems a bit faster but I don't have big projects at hand.

good, now I can continue improving it :-)

Yuv

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

[hugin-ptx] Re: improving Hugin's responsiveness - patch attached

[James Legg]

On Fri, 2009-10-02 at 23:57 -0400, Yuval Levy wrote:
> Hi all,
> 
> One thing that bothers me about Hugin is how slow it is in opening the 
> fast (pun intended) preview. Start Hugin. Load a project. Click on the 
> fast preview icon and wait. Wait. Starr at the status bar with the (not 
> yet localized ;-) ) "Loading image:" messages, while one image after the 
> other is loaded. And the Ubuntu equivalent of the sandglass trying to 
> hypnotize me...
> 
> No more, I said to myself. A little bit of research later and here comes 
> a patch for a more proactive cacheing: rather than loading the images 
> (and wait for them) at the time of (first) use, I do that during the 
> idle loop.

This doesn't help me for large projects.

Big images take a long time to load. Since you do this in the idle loop,
the UI actually gets less responsive. For example: I load a project and
click on the optimiser tab. Hugin is currently loading an image, so I
have to wait for it to finish the image it is on before it can work on
drawing the optimiser tab. Before, it could show the optimiser tab
straight away. This extra delay might be fine for small images, but it
takes a while to decode the huge jpegs many cameras produce.

Ideally, one would solve this problem by loading the images in another
thread with a lower priority.

Another issue I see is that it eats memory. If I load a project where
all the decoded images don't fit into RAM, this makes my whole system
unresponsive as it eventually it starts moving stuff I'm trying to use
to swap memory.

If I try to load the fast preview while this is going on, the following
happens:
  * The preview gets the first image from the image cache. It is now
loaded, where it wasn't before, saving a file load.
  * The preview tries to free up some space, in case there are more
images in the cache than fit the allowed memory. There is, so
the image cache frees most of the images that have been
preloaded.
  * The preview tries to get the second image from the image cache.
There is a high probability it was freed by the last step, so it
loads it off the disk again.
  * The preview again asks the image if it would like to free some
memory. It is likely to free the image accessed the earliest,
which is another preloaded one.
  * ...
So it only saves one file load if left too long to preload images.
Although I think the first image is loaded to show in the control points
tab when the project is loaded, so if I load a project, wait for the
cache to fill up, and then press the fast preview button, not even that
has made it appear faster than it used to.

After a while, the idle task has loaded all the images. Most of them
have since been freed by something else I used in the GUI, so many
images aren't loaded now.

The image tab's previews and the old preview use the small image cache,
which requires scaling the large images. So there is still a pause that
could be removed by doing something in the background.

I have some suggestions to get around these issues:
 1. Load images in a low priority thread separate to the GUI thread
if possible.
 2. Load the small images from the small image cache. These are not
freed, as they occupy a small amount of memory each. They are
used in the images tab and the traditional preview.
 3. Only load the small images in reverse order. The small images
are generated from the large ones, so the large images will be
loaded. However when space is getting tight, the larger ones
will be freed. When you have finished you'll have all the small
ones, and just the lower numbered large images. These are
generally used first by algorithms that require all the images,
so if the user waits long enough before starting one of these
algorithms they will run quicker.

I wrote the fast preview to use the large image cache to create the
textures it uses. This is so that if you are, for instance, just
remapping an equirectangular pano to a little planet, the image is
sharper as it knows it can allocate more texture memory to it.

We could make the fast preview use the small image cache for the smaller
textures so that the above routine has a better effect on performance of
displaying the fast preview: All the textures could be derived from the
small image cache on a sufficiently large project.

Textures have to have power of two sizes, and the small image cache
scales images down by a half continuously until they are less than or
equal to 512 pixels in each direction. So for instance a 4000 by 3000
image gets scaled to 500 by 375, and the nearest texture size that
doesn't interpolate between pixels is 256 by 256, so this is the largest
texture that can be used from the small image cache for that image. The
amount of texture memory the fast preview aims for means that for a
project with equal size images, you would 

[hugin-ptx] Re: improving Hugin's responsiveness - patch attached

[Harry van der Wolf]

WOW! We have a new programming kid on the block!
Well done.


It compiles and works fine as well on OSX, both via a cmake build and an
XCode build.
It seems a bit faster but I don't have big projects at hand.

Harry

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

[hugin-ptx] Re: Oups, I've added two strings!

[Kornel Benko]

Am Samstag 03 Oktober 2009 schrieb Yuval Levy:
> Hi Thomas,
> thanks for the feedback.
>
> T. Modes wrote:
> > does not compiles on Windows. Compiler complains about not finding
> > libintl.h.
>
> it's part of gettext. I see that CMake has defines if gettext is found.
> I'll boot into Windows later this weekend and have a look.
>
> > Also in imagecache.cpp it complains about function "_" not found.
>
> it is very well possible that MSVC does not understand
>
> #define _t(String) gettext (String)
>
> sounds the same like with the log2 thing. I'll try to solve it the same
> way we solved that.

I think, it is not the same. Here it is defined in wx/intl.h as a macro  (not a 
function)

> Slowly but surely I'll learn the pitfalls of cross-plattform development
> ;-)
>
> Yuv
>
Kornel

-- 
Kornel Benko
kornel.be...@berlin.de


signature.asc
Description: This is a digitally signed message part.

Re: man pages (was Re: [hugin-ptx] Re: here we go again)

[Jean-Luc Coulon (f5ibh)]

Le 02/10/2009 00:18:28, Bruno Postle a écrit :


This is a global answer for all the message from you and Yuv related to 
the documentation.

* po4a can manage the following format:
 - dia: uncompressed Dia diagrams.
  - docbook: Docbook XML.
  - guide: Gentoo Linux's xml documentation format.
  - ini: .INI format.
  - kernelhelp: Help messages of each kernel compilation option.
  - latex: LaTeX format.
  - man: Good old manual page format.
  - pod: Perl Online Documentation format.
  - sgml: either debiandoc or docbook DTD.
  - texinfo: The info page format.
  - tex: generic TeX documents (see also latex).
  - text: simple text document.
  - wml: WML documents.
  - xhtml: XHTML documents.
  - xml: generic XML documents (see also docbook).


* For the manpages:
Yes, the manpages are created mostly from the --help (all the .pod 
files). As the program in comand line arent translated by themselves, 
tranlating these manpages is better than nothing.
Obviously, a real manpage would be better...


* For the wiki:
We have tho think if the wiki format is the only needed one, or if wee 
need other output formats.

We needs 
1 - export mediawiki existing pages
2 - convert them to a user (and program) firendly format (neutral 
format)
3 - convert them to .pot/.po using po4a
4 - tranlate then (easy ;) )
5 - convert them back to the neutral format)
6 - import them in the mediawiki.



I've done some tests.

I've installed the following extension:
http://www.mediawiki.org/wiki/Extension:Wiki2xml

I used it on a mediawiki with "hugin FAQ" in it.
(Special:Wiki2XML)

After entering the name of the page and the suitable options, I get a 
docbook document.

I saved it and converted it to .po with po4a-gettexize.

I've not (yet) tested further but there is a whole gramework to deploy.

Unfortunately some of the formating is lost.

This needs further investigations

Regards

Jean-Luc


pgpZtxPmjKRj4.pgp
Description: PGP signature

[hugin-ptx] Re: improving Hugin's responsiveness - patch attached

[Yuval Levy]

Thank you Kornel and Thomas for testing.

T. Modes wrote:
> It compiles in windows. At a first test no crash occurs and the
> preview windows shows up faster.
> But I did not more tests.

I tried with a project that is too big to fit in the ImageCache and I 
did not find it to be any slower than without the patch. The bottlenecks 
could / would be loading the image from disk, and since my dynobook has 
an old 5400RPM notebook drive I would say that it is likely that there 
is no significant penalty in applying the patch. But we need more tests, 
especially on low-end machines (to determine bottlenecks) and on 
high-end machines with big projects (to determine if the usefulness scales).

Yuv

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

[hugin-ptx] Re: Oups, I've added two strings!

[Yuval Levy]

Hi Thomas,
thanks for the feedback.

T. Modes wrote:
> does not compiles on Windows. Compiler complains about not finding
> libintl.h.

it's part of gettext. I see that CMake has defines if gettext is found. 
I'll boot into Windows later this weekend and have a look.


> Also in imagecache.cpp it complains about function "_" not found.

it is very well possible that MSVC does not understand

#define _t(String) gettext (String)

sounds the same like with the log2 thing. I'll try to solve it the same 
way we solved that.

Slowly but surely I'll learn the pitfalls of cross-plattform development ;-)

Yuv



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

[hugin-ptx] Re: improving Hugin's responsiveness - patch attached

[T. Modes]

Hi Yuv,

> So here is a patch implementing this, against trunk. Please test it,
> especially in Windows and MacOSX; and under difficult conditions (such
> as adding and removing images, and stressing the cache to its limits).
>

It compiles in windows. At a first test no crash occurs and the
preview windows shows up faster.
But I did not more tests.

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

[hugin-ptx] Re: Oups, I've added two strings!

[T. Modes]

Hi Yuv,

> build and install this version of Hugin, to check that it really works
> and that I have not broken anything. We need this to be done also in
> Windows and OSX, to be sure.
>

does not compiles on Windows. Compiler complains about not finding
libintl.h.
Also in imagecache.cpp it complains about function "_" not found.

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

[hugin-ptx] Re: improving Hugin's responsiveness - patch attached

[Kornel Benko]

Am Samstag 03 Oktober 2009 schrieb Yuval Levy:
...
> I tested this on my Dynobook (1.6GHz 2GB) and found it an improvement.
> But I have not tested it with projects that do not fit in the cache; I
> have not worked intensively with it; and I still understand too little
> of Hugin's inner working.
>
> So here is a patch implementing this, against trunk. Please test it,
> especially in Windows and MacOSX; and under difficult conditions (such
> as adding and removing images, and stressing the cache to its limits).
>
> If it passes the integration tests and there is no negative feedback, I
> would like to add this as-is to trunk. And maybe to 2009.4.0_RC1.
>
> If there are negative indications, e.g. on machines with little memory,
> or on very large projects that don't fit in the cache, I will add a
> preference settings to turn this mode on (and it will be off by default).

The patch applies cleanly.

I tested it with some projects on ubuntu. And it is an improvement.
The immidiate response is a relief.

Sorry, I don't have MacOSX or Windows.

Kornel
-- 
Kornel Benko
kornel.be...@berlin.de


signature.asc
Description: This is a digitally signed message part.