[hugin-ptx] Re: svn/bc/4179/hugin not found !!!

2009-08-06 Thread Kornel Benko 
Am Friday 07 August 2009 schrieb Gerald:
> 
> On Aug 6, 3:55 pm, cri  wrote:
> > I run in the same error by following the wiki 
> > here:http://wiki.panotools.org/Hugin_Compiling_Ubuntu. By browsing the svn
> > tree in a web browser you could see that this branch doesn't exist.
> 
> I know, but the command line is :
> 
> svn co -r 4061 
> https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/branches/release-2009.07
> hugin
> 
> I it return :
> 
> svn: Chemin '/svnroot/hugin/!svn/bc/4181/hugin/branches/
> release-2009.07' non trouvé
> 
> Strange ???
> 
> 
> 
> > You could instead use this for 
> > trunk:https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk/.
> 
> 
> Same thing with the trunk 

It is really not there.
calling
#svn ls https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/branches
before_gsoc2007/
dangelo/
gsoc2008_batch_processing/
gsoc2008_feature_matching/
gsoc2008_integration/
gsoc2008_masking/
gsoc2008_opengl_preview/
gsoc2008_sky_identification/
gsoc2009_deghosting/
gsoc2009_layout/
gsoc2009_lenscalibration/
gsoc2009_mosaic/
nona-gpu/
vigra140-branch/
...

but maybe this?
https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/tags/hugin-2009.07.1/

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


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

RE: Test Cases (was Re: [hugin-ptx] Re: nona-gpu - has anybody got it working?)

2009-08-06 Thread Ryan Sleevi 

> 
> mhh... is yours 64bit? or 32bit?
> 

64-bit through and through. Using a DLL version of Glut, rather than a
static library, simply because it was convenient at the time. However, the
error seemed to suggest to me it was a GPU allocation error and not a system
allocation error. The memory usage of nona only peaked at ~100 megs when
generating that error.




--~--~-~--~~~---~--~~
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: coding style

2009-08-06 Thread Ryan Sleevi 

Granted, I'm not committing (yet?), but that doesn't keep me from voicing an
opinion, right? :)

> 1.2. VARIABLE NAMES
> 
> some variables are named with the CamelCase convention - capitalizing
> the beginning of the word. Other use the word_separated_by_underscore
> convention. Are there other conventions? Which one do you favor?
> 
> variable names should be clear and descriptive. no contractions, maybe
> with a few listed exception, e.g. Pano instead of Panorama. Any more
> exceptions?

Support James' comments re: LeadingCaps for classes/structures/typedefs, and
favoring mixedCase for variables. For functions, I always like the visual
distinction between public and private methods, if only to save a
consultation to intellisense or the header file. Using LeadingCaps for
public functions, mixedCase for private/protected/internal seems to offer
some visual distinction, but that's more a personal preference thing :)

I'm a fan of mixedCase over underscore_insertions_for_words myself, if only
to save the keyboard extension to the underscore. Readability wise I think
they're fairly equal. The only question comes when using acronyms (eg:
sqlVar vs SQLVar vs sQLVar), but I don't know how much of a problem that is.
I haven't seen many variables that have that problem in the codebase, and it
doesn't seem like it'd need to be hammered out now...

> 
> 1.3. FUNCTION NAMES
> 
> should functions follow the same conventions as variables? or a
> different one?
> 
> function names should be descriptive. no contractions, maybe with a few
> listed exception, e.g. Pano instead of Panorama. Any more exceptions?

Agree with James' comment that whatever contractions are acceptable, they be
used exclusively. 

> 3. SPACING AND INDENTATION
> 
> 3.1. BRACES
> 
> there are many different indent styles [3]. I am personally used to
> 1TBS
> [4] (like the Linux Kernel), but I recently heard good arguments to
> adopt Allman style [5], which puts the brace associated with a control
> statement or a function on the next line, indented to the same level as
> the control statement. I am ready to go Allman. Or maybe you want to
> suggest other alternatives? Which one do you prefer?

I always find 1TBS to be readable. The most helpful thing is the requirement
that single-line conditionals always include braces. Had too many bugs
working in teams where one dev would use a short construct, and either
between merging or sloppy devs, a second statement would be added that
screws up the code.

eg:

if (condition)
doSomething();

becoming

if (condition)
doSomething();
doSomeOtherThing();

instead of

if (condition) {
doSomething();
doSomeOtherThing();
}

The problem I have with Allman is that I've seen too many bugs where the
code ends up like

if (condition);
{
doSomething();
}

See the error? The extra ; accepted by all the compilers I've ever used,
ends up causing the { } to always be executed. It can be a real pain to
trace through those in complex systems to find out who added the extra ;
when typing

> 3.2. TABULATORS
> 
> use spaces instead of tabulators (to maintain consistency across
> editors). use four spaces for one indentation. or are there other
> preferences?

Spaces, tabs, it's all the same to me. Visual Studio can be a pain when
adjusting between the two, but it's doable. My own preference is "Tabs are
used for logical columns, spaces are used for alignment", but that's not
exactly easy to enforce :) (Of course, a diff usually reveals right away if
things are off). It's only really an issue if column width is also being
fixed - since artificial wrapping is often necessary in those cases.

void foo() 
{
if (someLongCondition
&& otherLongCondition
|| someOptionalCondition) {
doSomething();
if (didSomething) {
doSomethingElse();
}
}
}

> 
> 3.3. SPACES
> 
> I would not go into that much detail. or maybe we should adopt/adapt a
> strict coding guide like [2]?

Personally find it readable to use spaces before the parenthesis after
control statements, but not to use spaces before the parenthesis after
functions.

eg:

fn(foo, bar) / x(y) / y(z)
if (condition) / while (condition) / else (something else)

and use spaces after commas

fn(foo, bar, baz)

I find it less readable when the extreme is taken

fn( foo, bar, baz ) or worse fn( foo , bar , baz ), which I've seen both in
projects.

> 
> 3.4. LINE ENDS
> 
> Unix/Linux line ending (Windows and OSX users have to adapt)

Um, is there any reason we're not just using 

svn propset svn:eol-style native?

Seems like it solves the problem right there and everybody wins :) I've used
it on all my projects in the past, multiple platforms, and it always works
out. Also handles cygwin in Windows fine (uses LF, like you'd expect from a
posix layer, not CRLF, like Windows)

http://svnbook.red-bean.com/en/1.1/ch07s02.html

> 4. COMMITTS
> 
> It is tempting to clean up old code while fixing bugs or adding new
> code. Please don't - it makes

Test Cases (was Re: [hugin-ptx] Re: nona-gpu - has anybody got it working?)

2009-08-06 Thread Yuval Levy 

Hi Ryan, and everybody else

Ryan Sleevi wrote:
>   So I did some testing with your exe
> (http://www.photopla.net/hugin/nona_4169.7z ). Several projects I was able
> to run without error with mine generated the following error:
> 
> nona: GL error in
> ..\..\..\hugin\src\hugin_base\vigra_ext\ImageTransformsGPU.cpp:743: out of
> memory

mhh... is yours 64bit? or 32bit?


>   Since there appears to be some degree of variance depending on the
> project and the settings, is there any desire to create a sample setup (or
> preferably few) that test different levels of complexity? 

Yes, your suggestion makes sense. We need a set of typical test projects 
(we anyway should have them and run them before we ship *any* version of 
Hugin).

This is a task that any user (i.e. non-developer) can contribute to. We 
need one volunteer to collect the test cases and organize them. And 
everybody can contribute test cases.

I'm away for one week starting tomorrow morning. You don't need me for 
this. There are a number of people around here who have access codes (I 
actually don't even remember where I put the access code to 
hugin.panotools.org).

I'd be happy to see the community put together the test cases.

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: nona-gpu - has anybody got it working?

2009-08-06 Thread Ryan Sleevi 

> Ryan is so far the only one who has reported success, with his
> self-built version. I wonder if one of the pre-compiled (from Guido or
> from me) yield the same result. This would exclude building errors.
> 
> His video card is a GeForce 8800 GTS (256 mb) - anybody else with that
> same video card who can run nona -g successfully? and other video
> cards?
> 
> Yuv


Yuv,

So I did some testing with your exe
(http://www.photopla.net/hugin/nona_4169.7z ). Several projects I was able
to run without error with mine generated the following error:

nona: GL error in
..\..\..\hugin\src\hugin_base\vigra_ext\ImageTransformsGPU.cpp:743: out of
memory

However, when I re-created the simple project I'd used when testing
my version (just a simple transform), that I previously posted, I was able
to run without errors.

Since there appears to be some degree of variance depending on the
project and the settings, is there any desire to create a sample setup (or
preferably few) that test different levels of complexity? 

For what it's worth, here's the results using your exe:

nona: using graphics card: NVIDIA Corporation GeForce 8800 GTS/PCI/SSE2
destStart=[0, 0]
destEnd=[3000, 2800]
destSize=[(3000, 2800)]
srcSize=[(4296, 2856)]
srcBuffer=062D0020
srcAlphaBuffer=0A610020
destBuffer=085F0020
destAlphaBuffer=09E00020
destGLInternalFormat=GL_RGBA8
destGLFormat=GL_RGB
destGLType=GL_UNSIGNED_BYTE
srcGLInternalFormat=GL_RGBA8
srcGLFormat=GL_RGB
srcGLType=GL_UNSIGNED_BYTE
srcAlphaGLType=GL_UNSIGNED_BYTE
destAlphaGLType=GL_UNSIGNED_BYTE
warparound=0
needsAtanWorkaround=0
maxTextureSize=8192
Source chunks:
[(0, 0) to (4296, 2856) = (4296x2856)]
Dest chunks:
[(0, 0) to (1500, 1400) = (1500x1400)]
[(1500, 0) to (3000, 1400) = (1500x1400)]
[(0, 1400) to (1500, 2800) = (1500x1400)]
[(1500, 1400) to (3000, 2800) = (1500x1400)]
Total GPU memory used: 190555008
Interpolator chunks:
[(0, 0) to (4, 4) = (4x4)]
#version 110
#extension GL_ARB_texture_rectangle : enable
uniform sampler2DRect SrcTexture;
float sinh(const in float x) { return (exp(x) - exp(-x)) / 2.0; }
float cosh(const in float x) { return (exp(x) + exp(-x)) / 2.0; }
float atan2_xge0(const in float y, const in float x) {
return atan(y, x);
}
float atan2_safe(const in float y, const in float x) {
return atan(y, x);
}
float atan_safe(const in float yx) {
return atan(yx);
}
void main(void)
{
float discardA = 1.0;
float discardB = 0.0;
vec2 src = gl_TexCoord[0].st;
src -= vec2(1500., 1400.);

// rotate_erect(18000.000, -0.)
{
//src.s += -0.;
float w = (abs(src.s) > 18000.000) ? 1.0 : 0.0;
float n = (src.s < 0.0) ? 0.5 : -0.5;
src.s += w * -36000.000 * ceil(src.s /
36000.000 + n);
}

// sphere_tp_erect(5729.5779513082325000)
{
float phi = src.s / 5729.5779513082325000;
float theta = -src.t / 5729.5779513082325000 +
1.5707963267948966000;
if (theta < 0.0) {
theta = -theta;
phi += 3.1415926535897931000;
}
if (theta > 3.1415926535897931000) {
theta = 3.1415926535897931000 - (theta - 3.1415926535897931000);
phi += 3.1415926535897931000;
}
float s = sin(theta);
vec2 v = vec2(s * sin(phi), cos(theta));
float r = length(v);
theta = 5729.5779513082325000 * atan2_safe(r, s * cos(phi));
src = v * (theta / r);
}

// persp_sphere(5729.5779513082325000)
{
mat3 m = mat3(0.8074283680792127, -0.58996561799899783000,
0.,
  0.58996561799899783000, 0.8074283680792127,
0.,
  0., 0.,
1.000);
float r = length(src);
float theta = r / 5729.5779513082325000;
float s = 0.0;
if (r != 0.0) s = sin(theta) / r;
vec3 v = vec3(s * src.s, s * src.t, cos(theta));
vec3 u = v * m;
r = length(u.st);
theta = 0.0;
if (r != 0.0) theta = 5729.5779513082325000 * atan2_safe(r, u.p) /
r;
src = theta * u.st;
}

// rect_sphere_tp(5729.5779513082325000)
{
float r = length(src);
float theta = r / 5729.5779513082325000;
float rho = 0.0;
if (theta >= 1.5707963267948966000) rho = 1.6e16;
else if (theta == 0.0) rho = 1.0;
else rho = tan(theta) / theta;
src *= rho;
}

// resize(1.6728386297652815000, 1.6728386297652815000)
src *= vec2(1.6728386297652815000, 1.6728386297652815000);

src += vec2(2144.5000, 1427.5000);

src = src * discardA + vec2(-1000.0, -1000.0) * discardB;
gl_FragColor = vec4(src.s, 0.0, 0.0, src.t);
}
#version 110
#extension GL_ARB_texture_rectangle : enable
uniform sampler2DRect C

[hugin-ptx] Re: nona-gpu - has anybody got it working?

2009-08-06 Thread Yuval Levy 

Gerry Patterson wrote:
> I messed around a bit last night and found that if I change the format  
> for the coordinate texture from luminance_alpha32f to say rgba32f, I  
> could get Nona to run a bit further.  Perhaps that format is not  
> supported by the driver I am using?
> 
> I know very little about gpu programming, let alone gpgpu approaches  
> used here.

same here. Today I found out why on the same hardware I had a different 
error: my windows nvidia driver was still 81.98 from January 2006. I 
just updated to 190.38 and now I get the same error message as in Ubuntu:

gpu shader program compile time = 0.844
nona: GL error: Framebuffer incomplete, incomplete attachment in: 
..\..\..\hugin
\src\hugin_base\vigra_ext\ImageTransformsGPU.cpp:700

Ryan is so far the only one who has reported success, with his 
self-built version. I wonder if one of the pre-compiled (from Guido or 
from me) yield the same result. This would exclude building errors.

His video card is a GeForce 8800 GTS (256 mb) - anybody else with that 
same video card who can run nona -g successfully? and other video cards?

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: nona-gpu - has anybody got it working?

2009-08-06 Thread Yuval Levy 

Dear Guido,

Guido Kohlmeyer wrote:
>> any update of  needed?
>>   
> Yes of course, I have to add the description how to generate the library 
> from source package with MSVC 2008 EE. An updated SDK package is 
> mandatory too.

thank you.

there are a few other things I'd suggest doing for the next edition of 
the SDK:

1. autopano-sift-C:
- replace autopano-sift-C with Tom newest build (that solved so many 
memory leaks)
- *but* keep the old "generatekeys" in the same folder (Tom has now 
deprecated but is still so useful to so many different workflows)

2. update to the latest Exiftool (this is a continuum - regressions are 
very seldom and the continuous evolution of camera models and related 
EXIF data must be tracked)

3. update exiv2 to 0.18.2

4. libpano:
- move pano13 up one folder to make more compatible with Tom's new CMake 
build for pano13. The Cmake build for libpano is very new and still not 
  fully complete, but it is already useable and makes life *much* easier 
- especially on Windows system. This will likely require a small change 
in Hugin's CMakeLists.txt.
- use the latest SVN (with the fix for the locale mangling and with 
Tom's latest CMake build

5. UnxUtils: for now leave them there but 
http://gnuwin32.sourceforge.net/ is better maintained and officially 
supports Vista too. At some point replacement should be tested and when 
the test are positive GnuWin32 shall replace UnxUtils. There also seems 
to be a 64bit relative https://sourceforge.net/projects/gnuwin64/ but I 
have not looked into it.

6. Add enblend-enfuse. It is required to make the INSTALL target (and 
later on the installer).

7. for each folder, it would be good to document if it is downloaded or 
self-built, and the exact revision used for the build. I had to 
investigate / guess some of these (e.g. autopano-sift-C does not print 
the revision number in the help text).

8. a readme.txt file at the top level of the SDK would be helpful - a 
simple URL to the wiki page is enough for a start.

9. nice to have: add LAPACK  libraries.


> I wanted to wait until some developers approve the 
> functionality of nona based on the static library. Due to the fact that 
> my graphic card is too old I cannot do such tests. Based on first 
> impressions in this thread it seams that the lib works or other way 
> around there are situations where it works thus it is no general broken 
> build of nona.

Everything is fine. Andrew has added GPU-stitching in a non-obtrusive 
way. The current trunk does not break existing functionality (exception: 
I have no reports yet if the new code breaks build or functionality on OSX).


> I will update the SDK in few days or hours ...

take your time (focus on robustness and quality), and thank you for the 
effort.

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: svn/bc/4179/hugin not found !!!

2009-08-06 Thread Gerald 



On Aug 6, 3:55 pm, cri  wrote:
> I run in the same error by following the wiki 
> here:http://wiki.panotools.org/Hugin_Compiling_Ubuntu. By browsing the svn
> tree in a web browser you could see that this branch doesn't exist.

I know, but the command line is :

svn co -r 4061 
https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/branches/release-2009.07
hugin

I it return :

svn: Chemin '/svnroot/hugin/!svn/bc/4181/hugin/branches/
release-2009.07' non trouvé

Strange ???



> You could instead use this for 
> trunk:https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk/.


Same thing with the trunk 

Now I'm stuck 
--~--~-~--~~~---~--~~
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: nona-gpu - has anybody got it working?

2009-08-06 Thread Gerry Patterson 





On Aug 5, 2009, at 9:27 PM, Yuval Levy  wrote:

>
> Gerry Patterson wrote:
>> gpu shader program compile time = 0.08
>> nona: GL error: Framebuffer incomplete, incomplete attachment in:
>> /home/gpatters/work_area/hugin-git/myrepo/src/hugin_base/vigra_ext/ 
>> ImageTransformsGPU.cpp:700
>>
>>
>> I haven't quite figured out what this means yet.  This seems to be a
>> different error than yours.  I am running kubuntu 9.04 i386 with  
>> Hugin SVN
>> Rev 4169
>
> actually this is exactly the same error as me after I thought I fixed
> the bug in Rev 4169.
>
> and with the same hardware, same Rev., though in Windows I get a
> different error - most likely because of the driver that does not
> support v1.20 of the shader language:
>
> nona: normalization/photometric shader program could not be compiled.
> nona: GL info log:
> (1) : error C0201: unsupported version 120
> (3) : warning C7508: extension GL_ARB_texture_rectangle not supported
> (3) : warning C7506: OpenGL does not define the global type  
> sampler2DRect
> (10) : warning C7506: OpenGL does not define the global function
> texture2DRect
> (35) : error C: syntax error, unexpected '[', expecting '(' at  
> token "["
> (35) : error C0501: type name expected at token "["
> (35) : error C1068: too much data in type constructor
> (35) : error C1033: cast not allowed
> (35) : error C1056: invalid initialization
>
> Yuv
>
> --~--~-~--~~~---

I messed around a bit last night and found that if I change the format  
for the coordinate texture from luminance_alpha32f to say rgba32f, I  
could get Nona to run a bit further.  Perhaps that format is not  
supported by the driver I am using?

I know very little about gpu programming, let alone gpgpu approaches  
used here.

- Gerry


--~--~-~--~~~---~--~~
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] KImageFuser: an Enfuse/align_image_stack gui for Linux - version 0.3.0

2009-08-06 Thread Harry van der Wolf 
Hi Linux users,

KImageFuser is a graphical interface for enfuse and align_image_stack for
Linux.
I just published KImageFuser 0.3.0. See for downloads, screenshots and
changelog my KImageFuser pages at <
http://panorama.dyndns.org/index.php?lang=en&subject=KImageFuser&texttag=KImagefuser
>.

As also mentioned in the previous 2 mails (last one
here
):
KImageFuser is a graphical interface for enfuse and align_image_stack. It
uses convert (ImageMagick) as a prerequisite tool and Exiftool as
supplementary tool.
You might or might not know that I'm the builder/creator of
ImageFuserfor
MacOSX. Roughly 3½ weeks ago, and one week before my holidays started,
my MacBook crashed as I reported
here.
I went on holidays with a (cheap) laptop running Kubuntu linux.
Now that I'm back on Linux and being myself a frequent user of ImageFuser, I
found that there's no enfuse gui for Linux.
So I started writing
KImageFuserusing
kommander  to be able to enfuse my holiday
images and preview what they were going to look like.

KImageFuser is GPLed Open Source and you can use it in any form. As it is a
script you can even modify and improve it yourself. If you do, please let me
know as I like to benefit from it too.


Hoi,
Harry


Changelog since 0.2:

0.3.0   06 August 2009
- Added thumbs of source images to source images table (column with thumb,
  column with path name.
  I had to increase the window size to 980x635 to have a good image table.
- Added "bracketed" tux as starting image.
- Set "path" column width to 800. This will always fit the image name and path.
- Added rotate clockwise/counterclockwise buttons below (image) table to rotate
  thumbs.


0.2.2   28 July 2009
- Bugfix: Batch enfuse was sometimes not correct when
align_image_stack was used.
- Added "Image Info" buttons below tables. These buttons will open an external
  text editor (which should be selected in the Settings tab) and it will show
  all available EXIF information for that image. (Kommander doesn't have a
  popup function that can hold enough text).
- Added "Exit" button also on batch tab (just for convenience)
- Found "set table colum width" function (not a table function !?)
- Increased width of table to better show long path/file names.
- Added rotate clockwise/counterclockwise buttons below preview.
convert does not
  take image orientation into account when converting.


0.2.1   26 July 2009
- Removed the "oh so mysterious" Test button (sorry)
- Added exiftool functionality. If you enable exiftool on the Settings tab
  (and you should have it installed off course), KImageFuser will now copy
  loads of EXIF info from one of the source images to the new image.
- Changed Tab title of first tab from "Standard" to "Main".

--~--~-~--~~~---~--~~
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: problem building hugin on ubuntu 9.04

2009-08-06 Thread Kornel Benko 
Am Donnerstag 06 August 2009 schrieb cri:
> Thanks to all for the answers!
> I installed the liblapack-dev package and the building process went
> fine.
> Now I have another problem: in the assistant tab, after loading some
> images and launching the auto-align process, hugin exits. Often I got
> the same error after running an optimization of any kind. By launching
> the program in a terminal I got this output:
>
> CacheEntry: 1last access: 8 8bit: 1 16bit: 1 float: 1 mask: 1
> Image: /media/GIOCHI/giochi-LINUX/flightgear/install/fgfs/bin/fgfs-
> screen-002.tiff:small
...
Same here. But things are rapidly changing, so one has to expect some errors in 
the svn-version.

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


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

[hugin-ptx] Re: svn/bc/4179/hugin not found !!!

2009-08-06 Thread cri 

I run in the same error by following the wiki here:
http://wiki.panotools.org/Hugin_Compiling_Ubuntu. By browsing the svn
tree in a web browser you could see that this branch doesn't exist.
You could instead use this for trunk: 
https://hugin.svn.sourceforge.net/svnroot/hugin/hugin/trunk/.
I'm in no way an expert so maybe it's better to wait for answers from
someone more experienced!

On 6 Ago, 21:17, Gerald  wrote:
> svn: Chemin '/svnroot/hugin/!svn/bc/4179/hugin/branches/
> release-2009.07' non trouvé
>
> Translation:
>
> svn: Path '/svnroot/hugin/!svn/bc/4179/hugin/branches/release-2009.07'
> Not Found
--~--~-~--~~~---~--~~
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: problem building hugin on ubuntu 9.04

2009-08-06 Thread cri 

Thanks to all for the answers!
I installed the liblapack-dev package and the building process went
fine.
Now I have another problem: in the assistant tab, after loading some
images and launching the auto-align process, hugin exits. Often I got
the same error after running an optimization of any kind. By launching
the program in a terminal I got this output:

CacheEntry: 1last access: 8 8bit: 1 16bit: 1 float: 1 mask: 1
Image: /media/GIOCHI/giochi-LINUX/flightgear/install/fgfs/bin/fgfs-
screen-002.tiff:small
CacheEntry: 1last access: 8 8bit: 1 16bit: 1 float: 1 mask: 1
*** glibc detected *** hugin: corrupted double-linked list:
0x03480e40 ***
=== Backtrace: =
/lib/libc.so.6[0x7f4494540a8e]
/lib/libc.so.6[0x7f44945428f1]
/lib/libc.so.6[0x7f4494543d14]
/lib/libc.so.6(realloc+0x12e)[0x7f4494544dae]
/usr/lib/libglib-2.0.so.0(g_realloc+0x2e)[0x7f4491a5e93e]
/usr/lib/libglib-2.0.so.0[0x7f4491a31d13]
/usr/lib/libglib-2.0.so.0(g_array_insert_vals+0x2a)[0x7f4491a3200a]
/usr/lib/libgtk-x11-2.0.so.0[0x7f44937361e4]
/usr/lib/libgtk-x11-2.0.so.0[0x7f449373644a]
/usr/lib/libgtk-x11-2.0.so.0[0x7f4493737441]
/usr/lib/libgtk-x11-2.0.so.0(gtk_rc_get_style+0x21d)[0x7f44937379ad]
/usr/lib/libgtk-x11-2.0.so.0[0x7f44938050a8]
/usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN8wxWindow16ApplyWidgetStyleEb
+0x32)[0x7f4497672f72]
/usr/lib/libwx_gtk2u_core-2.8.so.0
(_ZN8wxWindow19SetBackgroundColourERK8wxColour+0x76)[0x7f44976730a6]
/usr/lib/libwx_gtk2u_core-2.8.so.0
(_ZN10wxTextCtrl19SetBackgroundColourERK8wxColour+0x23)
[0x7f44976e4683]
/usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN10wxTextCtrl14OnParentEnableEb
+0x72)[0x7f44976e61d2]
/usr/lib/libwx_gtk2u_core-2.8.so.0[0x7f4497673a8d]
/usr/lib/libwx_gtk2u_core-2.8.so.0[0x7f4497673ada]
/usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN8wxWindow6EnableEb+0x6b)
[0x7f449767413b]
/usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN16wxWindowDisablerD1Ev+0x5a)
[0x7f44976431da]
/usr/lib/libwx_gtk2u_core-2.8.so.0
(_ZN16wxProgressDialog20ReenableOtherWindowsEv+0x32)[0x7f4497791342]
/usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN16wxProgressDialogD2Ev+0x24)
[0x7f4497791544]
hugin(_ZN22ProgressReporterDialogD1Ev+0x39)[0x5978d9]
hugin(_ZN14AssistantPanel7OnAlignER14wxCommandEvent+0x3e22)[0x579c22]
/usr/lib/libwx_baseu-2.8.so.0
(_ZN12wxEvtHandler21ProcessEventIfMatchesERK21wxEventTableEntryBasePS_R7wxEvent
+0x89)[0x7f4497b86ae9]
/usr/lib/libwx_baseu-2.8.so.0
(_ZN16wxEventHashTable11HandleEventER7wxEventP12wxEvtHandler+0xa4)
[0x7f4497b87cc4]
/usr/lib/libwx_baseu-2.8.so.0(_ZN12wxEvtHandler12ProcessEventER7wxEvent
+0xc7)[0x7f4497b87db7]
/usr/lib/libwx_gtk2u_core-2.8.so.0
(_ZN12wxWindowBase9TryParentER7wxEvent+0x39)[0x7f449776bed9]
/usr/lib/libwx_gtk2u_core-2.8.so.0
(_ZN12wxWindowBase9TryParentER7wxEvent+0x39)[0x7f449776bed9]
/usr/lib/libwx_gtk2u_core-2.8.so.0
(_ZN12wxWindowBase9TryParentER7wxEvent+0x39)[0x7f449776bed9]
/usr/lib/libwx_gtk2u_core-2.8.so.0[0x7f44976adda9]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x16d)[0x7f44920f727d]
/usr/lib/libgobject-2.0.so.0[0x7f449210d3bc]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x7e2)
[0x7f449210e432]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x83)[0x7f449210e953]
/usr/lib/libgtk-x11-2.0.so.0[0x7f449364b7dd]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x16d)[0x7f44920f727d]
/usr/lib/libgobject-2.0.so.0[0x7f449210c723]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x7e2)
[0x7f449210e432]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x83)[0x7f449210e953]
/usr/lib/libgtk-x11-2.0.so.0[0x7f449364a46d]
/usr/lib/libgtk-x11-2.0.so.0[0x7f44936f5df8]
/usr/lib/libgobject-2.0.so.0(g_closure_invoke+0x16d)[0x7f44920f727d]
/usr/lib/libgobject-2.0.so.0[0x7f449210cb1e]
/usr/lib/libgobject-2.0.so.0(g_signal_emit_valist+0x66d)
[0x7f449210e2bd]
/usr/lib/libgobject-2.0.so.0(g_signal_emit+0x83)[0x7f449210e953]
/usr/lib/libgtk-x11-2.0.so.0[0x7f44937fe09e]
/usr/lib/libgtk-x11-2.0.so.0(gtk_propagate_event+0xe3)[0x7f44936ee693]
/usr/lib/libgtk-x11-2.0.so.0(gtk_main_do_event+0x2e3)[0x7f44936ef7b3]
/usr/lib/libgdk-x11-2.0.so.0[0x7f4493368f3c]
/usr/lib/libglib-2.0.so.0(g_main_context_dispatch+0x24a)
[0x7f4491a5620a]
/usr/lib/libglib-2.0.so.0[0x7f4491a598e0]
/usr/lib/libglib-2.0.so.0(g_main_loop_run+0x1cd)[0x7f4491a59dad]
/usr/lib/libgtk-x11-2.0.so.0(gtk_main+0xa7)[0x7f44936efbc7]
/usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN11wxEventLoop3RunEv+0x48)
[0x7f4497664068]
/usr/lib/libwx_gtk2u_core-2.8.so.0(_ZN9wxAppBase8MainLoopEv+0x4b)
[0x7f44976ed57b]
/usr/lib/libwx_baseu-2.8.so.0(_Z7wxEntryRiPPw+0x4d)[0x7f4497b2ba8d]
hugin(main+0x12)[0x46e932]
/lib/libc.so.6(__libc_start_main+0xe6)[0x7f44944e65a6]
hugin[0x46e5d9]
=== Memory map: 
0040-00601000 r-xp  08:08
507549 /usr/local/bin/hugin
0080-00801000 r--p 0020 08:08
507549 /usr/local/bin/hugin
00801000-00804000 rw-p 00201000 08:08
507549 /usr/local/bin/hugin
00804000-00846000 rw-p 00804000 00:00 0
023a2000-05319000 rw-p 023a2000 00:00
0

[hugin-ptx] svn/bc/4179/hugin not found !!!

2009-08-06 Thread Gerald 

svn: Chemin '/svnroot/hugin/!svn/bc/4179/hugin/branches/
release-2009.07' non trouvé

Translation:

svn: Path '/svnroot/hugin/!svn/bc/4179/hugin/branches/release-2009.07'
Not Found





--~--~-~--~~~---~--~~
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: problem building hugin on ubuntu 9.04

2009-08-06 Thread Kornel Benko 
Am Donnerstag 06 August 2009 schrieb cri:
...
> -- Program msgfmt found (/usr/bin/msgfmt)
> -- LAPACK not found, using LU-based solver
> -- Using shared internal libraries
> CMake Error: The following variables are used in this project, but
> they are set to NOTFOUND.
...
I had the same. The work-around was to install the lapack package 
"liblapack-dev".

Correct would have been to actually use "LU-based solver" as the message 
suggests,
and set somehow the variable LAPACK_LIBRARIES.

Kornel

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


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

[hugin-ptx] Re: problem building hugin on ubuntu 9.04

2009-08-06 Thread Harry van der Wolf 
Hi Christian,

I suppose you do a "out of tree" build as you specify the "cmake ../hugin"
option.
Your entire line
"cmake ../hugin -DENABLE_LAPACK=YES -DCPACK_BINARY_DEB:BOOL=ON -
DCPACK_BINARY_NSIS:BOOL=OFF \
-DCPACK_BINARY_RPM:BOOL=OFF -DCPACK_BINARY_STGZ:BOOL=OFF -
DCPACK_BINARY_TBZ2:BOOL=OFF \
-DCPACK_BINARY_TGZ:BOOL=OFF -DCPACK_BINARY_TZ:BOOL=OFF"

isn't necesary

What you should do before (re)building is remove the cmake cache from your
build directory. Do a "rm CMackeCache.txt". Then do a "clean" "cmake
../hugin".

Harry

2009/8/6 cri 

>
> Today I decided to update my running version of hugin compiled from
> trunk when the revision was equal to 4008. I updated from svn to
> revision 4178 and applied the procedure described in the wiki before 3
> Aug. I got an error message saying that configuring was incomplete.
> Later I checked again the wiki page and found out that the instruction
> for building hugin where changed. So I tried to follow the new
> instructions but I got again the same message: after launching the
> command"cmake ../hugin -DENABLE_LAPACK=YES -DCPACK_BINARY_DEB:BOOL=ON -
> DCPACK_BINARY_NSIS:BOOL=OFF \
> -DCPACK_BINARY_RPM:BOOL=OFF -DCPACK_BINARY_STGZ:BOOL=OFF -
> DCPACK_BINARY_TBZ2:BOOL=OFF \
> -DCPACK_BINARY_TGZ:BOOL=OFF -DCPACK_BINARY_TZ:BOOL=OFF"
>
> I got:
>
> -- Current SVN revision is 4178
> -- 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
> -- Found Glew:
> -- Program msgfmt found (/usr/bin/msgfmt)
> -- LAPACK not found, using LU-based solver
> -- 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 files:
> LAPACK_LIBRARIES
>linked by target "celeste" in directory /home/cristian/hugin/hugin/
> src/celeste
>linked by target "celeste_standalone" in directory /home/cristian/
> hugin/hugin/src/celeste
>linked by target "celeste_train" in directory /home/cristian/hugin/
> hugin/src/celeste/training
>linked by target "huginbase" in directory /home/cristian/hugin/
> hugin/src/hugin_base
>linked by target "open_file" in directory /home/cristian/hugin/
> hugin/src/hugin_base/test
>linked by target "align_image_stack" in directory /home/cristian/
> hugin/hugin/src/tools
>linked by target "autooptimiser" in directory /home/cristian/hugin/
> hugin/src/tools
>linked by target "fulla" in directory /home/cristian/hugin/hugin/
> src/tools
>linked by target "nona" in directory /home/cristian/hugin/hugin/
> src/tools
>linked by target "pto2mk" in directory /home/cristian/hugin/hugin/
> src/tools
>linked by target "tca_correct" in directory /home/cristian/hugin/
> hugin/src/tools
>linked by target "vig_optimize" in directory /home/cristian/hugin/
> hugin/src/tools
>linked by target "hugin_hdrmerge" in directory /home/cristian/
> hugin/hugin/src/deghosting
>linked by target "hugin_stitch_project" in directory /home/
> cristian/hugin/hugin/src/hugin1/stitch_project
>linked by target "hugin" in directory /home/cristian/hugin/hugin/
> src/hugin1/hugin
>linked by target "nona_gui" in directory /home/cristian/hugin/
> hugin/src/hugin1/nona_gui
>linked by target "PTBatcher" in directory /home/cristian/hugin/
> hugin/src/hugin1/ptbatcher
>linked by target "PTBatcherGUI" in directory /home/cristian/hugin/
> hugin/src/hugin1/ptbatcher
>
> -- Configuring incomplete, errors occurred!
>
> What's the problem here??
> Thanks for any help
> Cristian
>
>
> >
>

--~--~-~--~~~---~--~~
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] problem building hugin on ubuntu 9.04

2009-08-06 Thread cri 

Today I decided to update my running version of hugin compiled from
trunk when the revision was equal to 4008. I updated from svn to
revision 4178 and applied the procedure described in the wiki before 3
Aug. I got an error message saying that configuring was incomplete.
Later I checked again the wiki page and found out that the instruction
for building hugin where changed. So I tried to follow the new
instructions but I got again the same message: after launching the
command"cmake ../hugin -DENABLE_LAPACK=YES -DCPACK_BINARY_DEB:BOOL=ON -
DCPACK_BINARY_NSIS:BOOL=OFF \
-DCPACK_BINARY_RPM:BOOL=OFF -DCPACK_BINARY_STGZ:BOOL=OFF -
DCPACK_BINARY_TBZ2:BOOL=OFF \
-DCPACK_BINARY_TGZ:BOOL=OFF -DCPACK_BINARY_TZ:BOOL=OFF"

I got:

-- Current SVN revision is 4178
-- 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
-- Found Glew:
-- Program msgfmt found (/usr/bin/msgfmt)
-- LAPACK not found, using LU-based solver
-- 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 files:
LAPACK_LIBRARIES
linked by target "celeste" in directory /home/cristian/hugin/hugin/
src/celeste
linked by target "celeste_standalone" in directory /home/cristian/
hugin/hugin/src/celeste
linked by target "celeste_train" in directory /home/cristian/hugin/
hugin/src/celeste/training
linked by target "huginbase" in directory /home/cristian/hugin/
hugin/src/hugin_base
linked by target "open_file" in directory /home/cristian/hugin/
hugin/src/hugin_base/test
linked by target "align_image_stack" in directory /home/cristian/
hugin/hugin/src/tools
linked by target "autooptimiser" in directory /home/cristian/hugin/
hugin/src/tools
linked by target "fulla" in directory /home/cristian/hugin/hugin/
src/tools
linked by target "nona" in directory /home/cristian/hugin/hugin/
src/tools
linked by target "pto2mk" in directory /home/cristian/hugin/hugin/
src/tools
linked by target "tca_correct" in directory /home/cristian/hugin/
hugin/src/tools
linked by target "vig_optimize" in directory /home/cristian/hugin/
hugin/src/tools
linked by target "hugin_hdrmerge" in directory /home/cristian/
hugin/hugin/src/deghosting
linked by target "hugin_stitch_project" in directory /home/
cristian/hugin/hugin/src/hugin1/stitch_project
linked by target "hugin" in directory /home/cristian/hugin/hugin/
src/hugin1/hugin
linked by target "nona_gui" in directory /home/cristian/hugin/
hugin/src/hugin1/nona_gui
linked by target "PTBatcher" in directory /home/cristian/hugin/
hugin/src/hugin1/ptbatcher
linked by target "PTBatcherGUI" in directory /home/cristian/hugin/
hugin/src/hugin1/ptbatcher

-- Configuring incomplete, errors occurred!

What's the problem here??
Thanks for any help
Cristian


--~--~-~--~~~---~--~~
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: coding style

2009-08-06 Thread James Legg 

On Wed, 2009-08-05 at 00:48 -0400, Yuval Levy wrote:
> * if you're not interested in Hugin's development, you can stop reading now*
> 
> Hello Hugin developers,
> 
> I've been looking at our source code and I find that it can use some 
> consistency / clean up. The current status is historically grown - I am 
> not sure every contributor has seen Pablo's notes [0] and I think our 
> coding style belongs on the web, maybe on a wiki page?
> 

> 
> 1.2. VARIABLE NAMES
> 
> some variables are named with the CamelCase convention - capitalizing 
> the beginning of the word. Other use the word_separated_by_underscore 
> convention. Are there other conventions? Which one do you favor?

I think the first letter of a name should be capitalised only for
classes, structs, and typedefs. Variables and functions should not have
an initial capital.
This is especially useful when you want to declare a variable with the
same name as its class, as you don't need to name your variable
ThePanorama or MyPanorama or similar.
I favour the_underscore_convention but since most of the names in Hugin
use camelCase it is probably best we stick with that.

> variable names should be clear and descriptive. no contractions, maybe 
> with a few listed exception, e.g. Pano instead of Panorama. Any more 
> exceptions?

If we allow exceptions, the contracted form of the exceptions should
always be used, otherwise the rule doesn't help very much.

> 2.2. WORK IN PROGRESS
> 
> if something needs work, put a // FIXME or // TODO comment so that a 
> grep will reveal places that needs attention. Gedit automatically 
> highlights TODO and FIXME.

gedit does highlight them, which is useful. It also highlights doxygen
commands. The @todo and @bug sections in doxygen comments are listed
here:
http://hugin.sourceforge.net/docs/html/todo.shtml
http://hugin.sourceforge.net/docs/html/bug.shtml
as well as inside the relevant documentation. This is arguably more
useful, especially when using a different editor.

> 3. SPACING AND INDENTATION
> 
> 3.1. BRACES
> 
> there are many different indent styles [3].

>  Which one do you prefer?

I prefer Allman style too.

> 3.2. TABULATORS
> 
> use spaces instead of tabulators (to maintain consistency across 
> editors). use four spaces for one indentation. or are there other 
> preferences?

This is fine.

I'll repeat Bruno's comment as it is important:

Don't start changing existing code until all the branches we are working
on have been merged with the trunk.

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

[hugin-ptx] Re: nona-gpu - has anybody got it working?

2009-08-06 Thread Zoran Zorkic 



On Aug 6, 2:08 pm, Yuval Levy  wrote:
> Hi Zoran,
>
> Zoran Zorkic wrote:
> >> I'm not sure what to make of this. Any image at the end of the process?
> >> and I guess this is still with the first nona-gpu binary by Guido?
>
> > Yup.
>
> yup = image at the end of the process? is it as expected.

Ah, me posting before 2 cups of coffee :)
First nona-gpu binary on ATI gpu. It crashed, no image produced :)

> > No problem. Glad I can help out.
> > 4169 gives me this on my system:
>
> I see no error message. was there a resulting image? does it look as
> expected?

Crashed, no image produced.

> > I'll try to get ATI results later today.

Got results from ATI 4850 xp 32bit, nona 4169:
still crashes, no image produced.
---
G:\nona-test>nona -g -o test test-gui.pto
nona: using graphics card: ATI Technologies Inc. ATI Radeon HD 4800
Series
destStart=[3394, 0]
destEnd=[4706, 1857]
destSize=[(1312, 1857)]
srcSize=[(2144, 1424)]
srcBuffer=087B0020
srcAlphaBuffer=
destBuffer=09070020
destAlphaBuffer=09770020
destGLInternalFormat=GL_RGBA8
destGLFormat=GL_RGB
destGLType=GL_UNSIGNED_BYTE
srcGLInternalFormat=GL_RGBA8
srcGLFormat=GL_RGB
srcGLType=GL_UNSIGNED_BYTE
srcAlphaGLType=GL_BYTE
destAlphaGLType=GL_UNSIGNED_BYTE
warparound=0
needsAtanWorkaround=1
maxTextureSize=8192
Source chunks:
[(0, 0) to (2144, 1424) = (2144x1424)]
Dest chunks:
[(0, 0) to (1312, 1857) = (1312x1857)]
Total GPU memory used: 128572288
Interpolator chunks:
[(0, 0) to (4, 4) = (4x4)]
#version 110
#extension GL_ARB_texture_rectangle : enable
uniform sampler2DRect SrcTexture;
float sinh(const in float x) { return (exp(x) - exp(-x)) / 2.0; }
float cosh(const in float x) { return (exp(x) + exp(-x)) / 2.0; }
float atan2_xge0(const in float y, const in float x) {
if (abs(y) > x) {
return sign(y) * (1.5707963267948966000 - atan(x, abs(y)));
} else {
return atan(y, x);
}
}
float atan2_safe(const in float y, const in float x) {
if (x >= 0.0) return atan2_xge0(y, x);
else return (sign(y) * 3.1415926535897931000) - atan2_xge0(y, -x);
}
float atan_safe(const in float yx) {
if (abs(yx) > 1.0) {
return sign(yx) * (1.5707963267948966000 - atan(1.0/abs(yx)));
} else {
return atan(yx);
}
}
void main(void)
{
float discardA = 1.0;
float discardB = 0.0;
vec2 src = gl_TexCoord[0].st;
src -= vec2(2350., 928.5);

// rotate_erect(5222.22217000, -1767.9272076346463000)
{
src.s += -1767.9272076346463000;
float w = (abs(src.s) > 5222.22217000) ? 1.0 : 0.0;
float n = (src.s < 0.0) ? 0.5 : -0.5;
src.s += w * -10444.4443000 * ceil(src.s /
10444.4443000
 + n);
}

// sphere_tp_erect(1662.2849611820179000)
{
float phi = src.s / 1662.2849611820179000;
float theta = -src.t / 1662.2849611820179000 +
1.5707963267948966000;
if (theta < 0.0) {
theta = -theta;
phi += 3.1415926535897931000;
}
if (theta > 3.1415926535897931000) {
theta = 3.1415926535897931000 - (theta -
3.1415926535897931000);
phi += 3.1415926535897931000;
}
float s = sin(theta);
vec2 v = vec2(s * sin(phi), cos(theta));
float r = length(v);
theta = 1662.2849611820179000 * atan2_safe(r, s * cos(phi));
src = v * (theta / r);
}

// persp_sphere(1662.2849611820179000)
{
mat3 m = mat3(-0.0013991153339531414000,
-0.5332803644821000, 0.0095
595096691022414000,
  0.9902123766216000,
-0.0013990514038320933000,
1.33748
69653932957000e-005,
  0.,
0.0095595190255994313000,
0.54
30675406327000);
float r = length(src);
float theta = r / 1662.2849611820179000;
float s = 0.0;
if (r != 0.0) s = sin(theta) / r;
vec3 v = vec3(s * src.s, s * src.t, cos(theta));
vec3 u = v * m;
r = length(u.st);
theta = 0.0;
if (r != 0.0) theta = 1662.2849611820179000 * atan2_safe(r,
u.p)
/ r;
src = theta * u.st;
}

// rect_sphere_tp(1662.2849611820179000)
{
float r = length(src);
float theta = r / 1662.2849611820179000;
float rho = 0.0;
if (theta >= 1.5707963267948966000) rho = 1.6e16;
else if (theta == 0.0) rho = 1.0;
else rho = tan(theta) / theta;
src *= rho;
}

// resize(0.9801858945276285, 0.9801858945276285)
src *= vec2(0.9801858945276285, 0.9801858945276285);

// radial(1.0200684747885995000, 0.,
-0.0200684747885996
02000, 0., 712.0,
4.1162036363733581000)
{
float r = length(src) / 712.0;
float scale = 1000.0;
if (r < 4.1162036363733581000) {
scale = ((0. * r +
-0.020068474788599602000) *

[hugin-ptx] Re: nona-gpu - has anybody got it working?

2009-08-06 Thread Guido Kohlmeyer 

Yuval Levy schrieb:
> Guido Kohlmeyer wrote:
>   
>> I commited an updated CMakeLists.txt file to find GLUT in the SDK.
>> 
>
> Thank you, dear Guido and Ryan.
>
> any update of  needed?
>   
Yes of course, I have to add the description how to generate the library 
from source package with MSVC 2008 EE. An updated SDK package is 
mandatory too. I wanted to wait until some developers approve the 
functionality of nona based on the static library. Due to the fact that 
my graphic card is too old I cannot do such tests. Based on first 
impressions in this thread it seams that the lib works or other way 
around there are situations where it works thus it is no general broken 
build of nona.
I will update the SDK in few days or hours ...

Guido

--~--~-~--~~~---~--~~
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: nona-gpu - has anybody got it working?

2009-08-06 Thread Yuval Levy 

Guido Kohlmeyer wrote:
> I commited an updated CMakeLists.txt file to find GLUT in the SDK.

Thank you, dear Guido and Ryan.

any update of  needed?

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: nona-gpu - has anybody got it working?

2009-08-06 Thread Yuval Levy 

Hi Zoran,

Zoran Zorkic wrote:
>> I'm not sure what to make of this. Any image at the end of the process?
>> and I guess this is still with the first nona-gpu binary by Guido?
> 
> Yup.

yup = image at the end of the process? is it as expected.


> No problem. Glad I can help out.
> 4169 gives me this on my system:

I see no error message. was there a resulting image? does it look as 
expected?


> I'll try to get ATI results later today.

thanks for your effort, Zoran.

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: nona-gpu - has anybody got it working?

2009-08-06 Thread Yuval Levy 

Ryan Sleevi wrote:
> Test System: Vista x64 (SP2)
> Video Card: GeForce 8800 GTS (256 mb)
> Video BIOS: 60.80.0D.00.01
> Video Driver: 186.18
> RAM: 8GB
> Proc: C2D 6600 @ 2.40 GHz
> 
> SVN: 4169
> Summary: No problems - Image was adjusted as expected

THANKS FOR THE GOOD NEWS, Ryan!

keep them coming.

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: nona-gpu - has anybody got it working?

2009-08-06 Thread Guido Kohlmeyer 

Dear Ryan,

I commited an updated CMakeLists.txt file to find GLUT in the SDK. Here 
I set only the root search path of GLUT.
In my current working environment I created a base directory "glut" in 
the root of the SDK directory tree. The include file glut.h resides in 
.\glut\include\GL\glut.h which is the default from the sources. The 
library glut32.lib resides in .\glut\Release\glut32.lib which is the 
location where the default FindGLUT from CMake 2.6.4 searches for the 
library.  Thats all on win32 platfrom to work. I used the same sources 
from Nate Robins to build the static GLUT library (see also thread "Re: 
The way to 2009.2").

Guido

Ryan Sleevi schrieb:
> Compiled my own x64 version (using the Glut For Win32 sources -
> http://www.xmission.com/~nate/glut.html ), as I wanted to see if there was
> going to be any headache on Windows. Some wonky macros, but nothing fatal.
> In order to get CMake to find Glut, I had to touch my FindGLUT macro, but I
> imagine that's because of the use of Glut for Win32.
>
> I'll see what other video cards I can scrape up and see how they handle.
>
> Is there some particular set of test data to use? Just threw some simple
> stuff at it, nothing complex, but it all turned out fine.
>
> Test System: Vista x64 (SP2)
> Video Card: GeForce 8800 GTS (256 mb)
> Video BIOS: 60.80.0D.00.01
> Video Driver: 186.18
> RAM: 8GB
> Proc: C2D 6600 @ 2.40 GHz
>
> SVN: 4169
> Summary: No problems - Image was adjusted as expected
>
> Log:
>
> nona: using graphics card: NVIDIA Corporation GeForce 8800 GTS/PCI/SSE2
> destStart=[17, 50]
> destEnd=[3001, 2600]
> destSize=[(2984, 2550)]
> srcSize=[(4296, 2856)]
> srcBuffer=05DB0040
> srcAlphaBuffer=09DF0040
> destBuffer=080D0040
> destAlphaBuffer=096A0040
> destGLInternalFormat=GL_RGBA8
> destGLFormat=GL_RGB
> destGLType=GL_UNSIGNED_BYTE
> srcGLInternalFormat=GL_RGBA8
> srcGLFormat=GL_RGB
> srcGLType=GL_UNSIGNED_BYTE
> srcAlphaGLType=GL_UNSIGNED_BYTE
> destAlphaGLType=GL_UNSIGNED_BYTE
> warparound=0
> needsAtanWorkaround=0
> maxTextureSize=8192
> Source chunks:
> [(0, 0) to (4296, 2856) = (4296x2856)]
> Dest chunks:
> [(0, 0) to (1492, 1275) = (1492x1275)]
> [(1492, 0) to (2984, 1275) = (1492x1275)]
> [(0, 1275) to (1492, 2550) = (1492x1275)]
> [(1492, 1275) to (2984, 2550) = (1492x1275)]
> Total GPU memory used: 181856208
> Interpolator chunks:
> [(0, 0) to (4, 4) = (4x4)]
> #version 110
> #extension GL_ARB_texture_rectangle : enable
> uniform sampler2DRect SrcTexture;
> float sinh(const in float x) { return (exp(x) - exp(-x)) / 2.0; }
> float cosh(const in float x) { return (exp(x) + exp(-x)) / 2.0; }
> float atan2_xge0(const in float y, const in float x) {
> return atan(y, x);
> }
> float atan2_safe(const in float y, const in float x) {
> return atan(y, x);
> }
> float atan_safe(const in float yx) {
> return atan(yx);
> }
> void main(void)
> {
> float discardA = 1.0;
> float discardB = 0.0;
> vec2 src = gl_TexCoord[0].st;
> src -= vec2(1500., 1300.);
>
> // rotate_erect(18000.000, -13.34104824210840)
> {
> src.s += -13.34104824210840;
> float w = (abs(src.s) > 18000.000) ? 1.0 : 0.0;
> float n = (src.s < 0.0) ? 0.5 : -0.5;
> src.s += w * -36000.000 * ceil(src.s /
> 36000.000 + n);
> }
>
> // sphere_tp_erect(5729.5779513082325000)
> {
> float phi = src.s / 5729.5779513082325000;
> float theta = -src.t / 5729.5779513082325000 +
> 1.5707963267948966000;
> if (theta < 0.0) {
> theta = -theta;
> phi += 3.1415926535897931000;
> }
> if (theta > 3.1415926535897931000) {
> theta = 3.1415926535897931000 - (theta - 3.1415926535897931000);
> phi += 3.1415926535897931000;
> }
> float s = sin(theta);
> vec2 v = vec2(s * sin(phi), cos(theta));
> float r = length(v);
> theta = 5729.5779513082325000 * atan2_safe(r, s * cos(phi));
> src = v * (theta / r);
> }
>
> // persp_sphere(5729.5779513082325000)
> {
> mat3 m = mat3(0.86726875127917369000, 0.49776314112882103000,
> -0.0087617571429537341000,
>   -0.49784024852824299000, 0.86713442538204355000,
> -0.015263527203445419000,
>   0., 0.017599535531440003000,
> 0.99984511618003991000);
> float r = length(src);
> float theta = r / 5729.5779513082325000;
> float s = 0.0;
> if (r != 0.0) s = sin(theta) / r;
> vec3 v = vec3(s * src.s, s * src.t, cos(theta));
> vec3 u = v * m;
> r = length(u.st);
> theta = 0.0;
> if (r != 0.0) theta = 5729.5779513082325000 * atan2_safe(r, u.p) /
> r;
> src = theta * u.st;
> }
>
> // rect_sphere_tp(5729.5779513082325000)
> {
> float r = length(src

[hugin-ptx] Re: Hugin win32 build problem: Cmake wxwidgets problem

2009-08-06 Thread Elvis 

Thank you so much,

Now I am trying this way, building Hugin with updated SDK.

Elvis

On 8月5日, 下午5時58分, Guido Kohlmeyer  wrote:
> The SDK which I built and refering in my last post is not appropriate to
> build enblend/enfuse. It contains a pre-build version from enblend
> homepage. It was discussed to extend the SDK to even build
> enblend/enfuse, but so far there is no such SDK version available which
> fits all build use scenarios on Win platform.
>
> Guido
>
>
>
> > Dear Guido
>
> > Thank you so much,
>
> > I will run the process again with updated environment immediatelly.
>
> > I have a question,
>
> > Should I rebuild Enblend with updated SDK?
>
> > or it doesn't manner that Enblend is built with elder SDK, and Hugin
> > is builted with updated SDK ?
>
> > I really appreciate your help.
>
> > Best regards
>
> > Elvis- 隱藏被引用文字 -
>
> - 顯示被引用文字 -
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---