The way to 2009.2

[Yuval Levy]

Hi all,

I just merged the nona-gpu branch into trunk. This is a present for
Andrew on a very special day for him :)

Details of how I made the merge are documented at
<http://panospace.wordpress.com/2009/08/02/preparing-the-next-release/>

Now for releases/2009.2:

* The Windows SDK will need to be updated for a new dependecy: GLEW

* currently GPU stitching is available only from the command line (nona
with the switch -g).

* I did some initial investigation on adding support in the GUI. More
will follow.

* Even without GUI support, I think we have something worth releasing.

* I suggest we branch out a release codeline as soon as trunk is
confirmed to build without breaking existing functionalities on the
major platforms - Linux / Windows / OSX.

Yuv

[Gerry Patterson]

Hello,

I have kicked off a build on my Linux system and will report my findings.  As for the GUI, how about this:

Rename the Enblend tab in the Preferences dialog to "Stitching".  Add a section called "Nona" (similar to the existing Enblend and Enfuse sections) and here add entries for defaults to use in projects (interpolator, cropped tiff output...).  Here a checkbox could be added to enable GPU support by default. This would be then saved in the global preferences (registry on windows, ini files elsewhere)

Then, on the stitcher tab, add a GPU checkbox in the nona optoins dialog.  This would allow the user to disable it if required for that particular project.  When the project is saved, this state would be stored in .pto file.

Does this make sense?

- Gerry

[T. Modes]

> I just merged the nona-gpu branch into trunk. This is a present for
> Andrew on a very special day for him :)
>

The trunk does not compile on windows. (I asked for help some time
ago, but there was no reaction.)

Follow points I've done so far:

GLUT
I added GLUT (found binaries by Nate Robins, so no extra compiling),
CMake did not found the files, added the paths manually.

ImageTransformsGPU.cpp
* include <sys/time.h> not found, this file implements gettimeofday ->
this function is not available on windows, as a workaround I found a
implementation by Wu Yongwei (but without license), added this
function after!! vigra includes conditionally for windows only
* then error 2589 in lines 233, 235, 664 and 665: changed std::min to
std::min<int> and std::max to std::max<int>

Interpolator.h, line 461: c4716 emitGLSL must return a value
add "return true;" or change return type to void

Then I get linker errors in nona_gui, align_image_stack and hugin (can
not open file "glut32.lib")
Added ${GLUT_LIBRARIES} for hugin and ${GLEW_LIBRARIES} $
{GLUT_LIBRARIES} for nona_gui and align_images_stack to to
target_link_libraries in corresponding CMakeLists.txt

Finally copy glut32.dll to hugin/bin-folder.

Now the trunk is compiles and a first test run was successfull.

Could someone (Andrew?) look at the points in ImageTransformsGPU.cpp
and Interpolator.h? I don't know, if my fast fixes are correct and we
need a solution for gettimeofday on windows.

Thomas

[T. Modes]

T. Modes schrieb:

> > I just merged the nona-gpu branch into trunk. This is a present for
> > Andrew on a very special day for him :)
> >
>
> The trunk does not compile on windows. (I asked for help some time
> ago, but there was no reaction.)

> Now the trunk is compiles and a first test run was successfull.
>

It tested the new option of nona. With nona -g the output image
consists only of one line (only the top line of the output image).
When adding -v to get more information nona is crashing.
So there is somewhere in the new code a bug.

Output of nona is:
nona -g -z PACKBITS -r ldr -m TIFF_m -o test_gpu -i 0 test.pto
nona: using graphics card: ATI Technologies Inc. ATI MOBILITY RADEON
X1700
destStart=[227, 67]
destEnd=[627, 361]
destSize=[(400, 294)]
srcSize=[(3264, 2448)]
srcBuffer=06F20020
srcAlphaBuffer=00000000
destBuffer=029D34C8
destAlphaBuffer=02A296F0
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=4096
Source chunks:
[(0, 0) to (3264, 2448) = (3264x2448)]
Dest chunks:
[(0, 0) to (400, 294) = (400x294)]
Total GPU memory used: 61106304
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(400.00000000000000000, 312.00000000000000000);

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

// sphere_tp_erect(458.36623610465858000)
{
float phi = src.s / 458.36623610465858000;
float theta = -src.t / 458.36623610465858000 +
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 = 458.36623610465858000 * atan2_safe(r, s * cos(phi));
src = v * (theta / r);
}

// persp_sphere(458.36623610465858000)
{
mat3 m = mat3(0.99974686634761689000, 0.021773941203564677000,
0.0056655725733614892000,
-0.022498960600888154000,
0.96753045051519970000, 0.25175111538528405000,
0.00000000000000000000, -0.25181485820006455000,
0.96777542704373387000);
float r = length(src);
float theta = r / 458.36623610465858000;
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 = 458.36623610465858000 * atan2_safe(r,
u.p) / r;
src = theta * u.st;
}

// rect_sphere_tp(458.36623610465858000)
{
float r = length(src);
float theta = r / 458.36623610465858000;
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(6.0949143885484665000, 6.0949143885484665000)
src *= vec2(6.0949143885484665000, 6.0949143885484665000);

// radial(1.0181772560763589000, 0.00000000000000000000,
-0.018177256076358801000, 0.00000000000000000000,
1224.0000000000000000, 4.3210262605317249000)
{
float r = length(src) / 1224.0000000000000000;
float scale = 1000.0;
if (r < 4.3210262605317249000) {
scale = ((0.00000000000000000000 * r +
-0.018177256076358801000) * r + 0.00000000000000000000) * r +
1.0181772560763589000;
}
src *= scale;
}

src += vec2(1631.5000000000000000, 1223.5000000000000000);

src = src * discardA + vec2(-1000.0, -1000.0) * discardB;
gl_FragColor = vec4(src.s, 0.0, 0.0, src.t);
}
nona: GL info log:
Fragment shader was successfully compiled to run on hardware.

nona: GL info log:
Fragment shader(s) linked, no vertex shader(s) defined.d

#version 110
#extension GL_ARB_texture_rectangle : enable
uniform sampler2DRect CoordTexture;
uniform sampler2DRect SrcTexture;
uniform sampler2DRect AccumTexture;
uniform vec2 SrcUL;
uniform vec2 SrcLR;
uniform vec2 KernelUL;
uniform vec2 KernelWH;
float w(const in float i, const in float f) {
float A = -0.75000000000000000000;
float c = abs(i - 1.0);
float m = (i > 1.0) ? -1.0 : 1.0;
float p = c + m * f;
if (i == 1.0 || i == 2.0) {
return (( A + 2.0 )*p - ( A + 3.0 ))*p*p + 1.0;
} else {
return (( A * p - 5.0 * A ) * p + 8.0 * A ) * p - 4.0 * A;
}
}
void main(void)
{
vec2 src = texture2DRect(CoordTexture, gl_TexCoord[0].st).sq;
vec4 accum = texture2DRect(AccumTexture, gl_TexCoord[0].st);

src -= SrcUL;
vec2 t = floor(src) + -0.50000000000000000000;
vec2 f = fract(src);
vec2 k = vec2(0.0, 0.0);

for (float ky = 0.0; ky < 4.0000000000000000000; ky += 1.0) {
k.t = ky + KernelUL.t;
float wy = w(k.t, f.t);
for (float kx = 0.0; kx < 4.0000000000000000000; kx += 1.0) {
k.s = kx + KernelUL.s;
float wx = w(k.s, f.s);
vec2 ix = t + k;
vec4 sp = texture2DRect(SrcTexture, ix);
float weight = wx * wy * sp.a;
accum += sp * weight;
}
}

gl_FragColor = accum;
}

nona: GL info log:
Fragment shader was successfully compiled to run on hardware.

nona: GL info log:
Fragment shader(s) linked, no vertex shader(s) defined.d

#version 110
#extension GL_ARB_texture_rectangle : enable
uniform sampler2DRect NormTexture;
uniform sampler2DRect CoordTexture;
uniform sampler2DRect InvLutTexture;
uniform sampler2DRect DestLutTexture;
void main(void)
{
// Normalization
vec4 n = texture2DRect(NormTexture, gl_TexCoord[0].st);
vec4 p = vec4(0.0, 0.0, 0.0, 0.0);
if (n.a >= 0.2) p = n / n.a;

// Photometric
// invLutSize = 256.00000000000000000
// pixelMax = 255.00000000000000000
// destLutSize = 1024.0000000000000000
// destExposure = 9.4685300747959908000e-005
// srcExposure = 3.9062499126884348000e-005
// whiteBalanceRed = 1.0000000000000000000
// whiteBalanceBlue = 1.0000000000000000000
p.rgb = p.rgb * 255.00000000000000000;
vec2 invR = texture2DRect(InvLutTexture, vec2(p.r, 0.0)).sq;
vec2 invG = texture2DRect(InvLutTexture, vec2(p.g, 0.0)).sq;
vec2 invB = texture2DRect(InvLutTexture, vec2(p.b, 0.0)).sq;
vec3 invX = vec3(invR.x, invG.x, invB.x);
vec3 invY = vec3(invR.y, invG.y, invB.y);
vec3 invA = fract(p.rgb);
p.rgb = mix(invX, invY, invA);
// VigCorrMode=VIGCORR_RADIAL
float vig = 1.0;
{
vec2 vigCorrCenter = vec2(1631.5000000000000000,
1223.5000000000000000);
float radiusScale=0.00049019607843137254000;
float radialVigCorrCoeff[4] = float[4](1.0000000000000000000,
-0.50230497890537296000, 0.64532807681882198000,
-0.34169389929015498000);
vec2 src = texture2DRect(CoordTexture, gl_TexCoord[0].st).sq;
vec2 d = src - vigCorrCenter;
d *= radiusScale;
vig = radialVigCorrCoeff[0];
float r2 = dot(d, d);
float r = r2;
vig += radialVigCorrCoeff[1] * r;
r *= r2;
vig += radialVigCorrCoeff[2] * r;
r *= r2;
vig += radialVigCorrCoeff[3] * r;
}
vec3 exposure_whitebalance = vec3(2.4239437533271841000,
2.4239437533271841000, 2.4239437533271841000);
p.rgb = (p.rgb * exposure_whitebalance) / vig;
p.rgb = p.rgb * 1023.0000000000000000;
vec2 destR = texture2DRect(DestLutTexture, vec2(p.r, 0.0)).sq;
vec2 destG = texture2DRect(DestLutTexture, vec2(p.g, 0.0)).sq;
vec2 destB = texture2DRect(DestLutTexture, vec2(p.b, 0.0)).sq;
vec3 destX = vec3(destR.x, destG.x, destB.x);
vec3 destY = vec3(destR.y, destG.y, destB.y);
vec3 destA = fract(p.rgb);
p.rgb = mix(destX, destY, destA);

gl_FragColor = p;
}

nona: GL info log:
Fragment shader was successfully compiled to run on hardware.

nona: GL info log:
Fragment shader(s) linked, no vertex shader(s) defined.d

gpu shader program compile time = 0.078
gpu shader texture/framebuffer setup time = 0.1716
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] coord image render
time = 0.0468
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] source chunk=[(0, 0)
to (3264, 2448) = (3264x2448)] src upload = 0.1404
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] source chunk=[(0, 0)
to (3264, 2448) = (3264x2448)] src render = 0.1092
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] source chunk=[(0, 0)
to (3264, 2448) = (3264x2448)] interpolation chunk=[(0, 0) to (4, 4) =
(4x4)] setup = 0
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] source chunk=[(0, 0)
to (3264, 2448) = (3264x2448)] interpolation chunk=[(0, 0) to (4, 4) =
(4x4)] render = 0.0156
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] normalization setup
= 0
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] normalization render
= 0.0156
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] dest rgb disassembly
setup = 0
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] dest rgb disassembly
render = 0
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] rgb readback =
0.0468
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] dest alpha
disassembly setup = 0
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] dest alpha
disassembly render = 0
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] alpha readback =
0.0156
gpu destruct time = 0
gpu total time = 0.6396

Verbose Output
nona -g -v -z PACKBITS -r ldr -m TIFF_m -o test_gup -i 0 test.pto
nona: using graphics card: ATI Technologies Inc. ATI MOBILITY RADEON
X1700


:
0%
Remapping:
0%
Remapping (loading PICT0048.JPG):
0%
Remapping (remapping PICT0048.JPG):
0%
Remapping (remapping PICT0048.JPG), :
0%
Remapping (remapping PICT0048.JPG), Remapping:
0% destStart=[227, 67]
destEnd=[627, 361]
destSize=[(400, 294)]
srcSize=[(3264, 2448)]
srcBuffer=06720020
srcAlphaBuffer=00000000
destBuffer=02B43500
destAlphaBuffer=02B99728
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=4096
Source chunks:
[(0, 0) to (3264, 2448) = (3264x2448)]
Dest chunks:
[(0, 0) to (400, 294) = (400x294)]
Total GPU memory used: 61106304
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(400.00000000000000000, 312.00000000000000000);

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

// sphere_tp_erect(458.36623610465858000)
{
float phi = src.s / 458.36623610465858000;
float theta = -src.t / 458.36623610465858000 +
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 = 458.36623610465858000 * atan2_safe(r, s * cos(phi));
src = v * (theta / r);
}

// persp_sphere(458.36623610465858000)
{
mat3 m = mat3(0.99974686634761689000, 0.021773941203564677000,
0.0056655725733614892000,
-0.022498960600888154000,
0.96753045051519970000, 0.25175111538528405000,
0.00000000000000000000, -0.25181485820006455000,
0.96777542704373387000);
float r = length(src);
float theta = r / 458.36623610465858000;
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 = 458.36623610465858000 * atan2_safe(r,
u.p) / r;
src = theta * u.st;
}

// rect_sphere_tp(458.36623610465858000)
{
float r = length(src);
float theta = r / 458.36623610465858000;
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(6.0949143885484665000, 6.0949143885484665000)
src *= vec2(6.0949143885484665000, 6.0949143885484665000);

// radial(1.0181772560763589000, 0.00000000000000000000,
-0.018177256076358801000, 0.00000000000000000000,
1224.0000000000000000, 4.3210262605317249000)
{
float r = length(src) / 1224.0000000000000000;
float scale = 1000.0;
if (r < 4.3210262605317249000) {
scale = ((0.00000000000000000000 * r +
-0.018177256076358801000) * r + 0.00000000000000000000) * r +
1.0181772560763589000;
}
src *= scale;
}

src += vec2(1631.5000000000000000, 1223.5000000000000000);

src = src * discardA + vec2(-1000.0, -1000.0) * discardB;
gl_FragColor = vec4(src.s, 0.0, 0.0, src.t);
}
nona: GL info log:
Fragment shader was successfully compiled to run on hardware.

nona: GL info log:
Fragment shader(s) linked, no vertex shader(s) defined.d

#version 110
#extension GL_ARB_texture_rectangle : enable
uniform sampler2DRect CoordTexture;
uniform sampler2DRect SrcTexture;
uniform sampler2DRect AccumTexture;
uniform vec2 SrcUL;
uniform vec2 SrcLR;
uniform vec2 KernelUL;
uniform vec2 KernelWH;
float w(const in float i, const in float f) {
float A = -0.75000000000000000000;
float c = abs(i - 1.0);
float m = (i > 1.0) ? -1.0 : 1.0;
float p = c + m * f;
if (i == 1.0 || i == 2.0) {
return (( A + 2.0 )*p - ( A + 3.0 ))*p*p + 1.0;
} else {
return (( A * p - 5.0 * A ) * p + 8.0 * A ) * p - 4.0 * A;
}
}
void main(void)
{
vec2 src = texture2DRect(CoordTexture, gl_TexCoord[0].st).sq;
vec4 accum = texture2DRect(AccumTexture, gl_TexCoord[0].st);

src -= SrcUL;
vec2 t = floor(src) + -0.50000000000000000000;
vec2 f = fract(src);
vec2 k = vec2(0.0, 0.0);

for (float ky = 0.0; ky < 4.0000000000000000000; ky += 1.0) {
k.t = ky + KernelUL.t;
float wy = w(k.t, f.t);
for (float kx = 0.0; kx < 4.0000000000000000000; kx += 1.0) {
k.s = kx + KernelUL.s;
float wx = w(k.s, f.s);
vec2 ix = t + k;
vec4 sp = texture2DRect(SrcTexture, ix);
float weight = wx * wy * sp.a;
accum += sp * weight;
}
}

gl_FragColor = accum;
}

nona: GL info log:
Fragment shader was successfully compiled to run on hardware.

nona: GL info log:
Fragment shader(s) linked, no vertex shader(s) defined.d

#version 110
#extension GL_ARB_texture_rectangle : enable
uniform sampler2DRect NormTexture;
uniform sampler2DRect CoordTexture;
uniform sampler2DRect InvLutTexture;
uniform sampler2DRect DestLutTexture;
void main(void)
{
// Normalization
vec4 n = texture2DRect(NormTexture, gl_TexCoord[0].st);
vec4 p = vec4(0.0, 0.0, 0.0, 0.0);
if (n.a >= 0.2) p = n / n.a;

// Photometric
// invLutSize = 256.00000000000000000
// pixelMax = 255.00000000000000000
// destLutSize = 1024.0000000000000000
// destExposure = 9.4685300747959908000e-005
// srcExposure = 3.9062499126884348000e-005
// whiteBalanceRed = 1.0000000000000000000
// whiteBalanceBlue = 1.0000000000000000000
p.rgb = p.rgb * 255.00000000000000000;
vec2 invR = texture2DRect(InvLutTexture, vec2(p.r, 0.0)).sq;
vec2 invG = texture2DRect(InvLutTexture, vec2(p.g, 0.0)).sq;
vec2 invB = texture2DRect(InvLutTexture, vec2(p.b, 0.0)).sq;
vec3 invX = vec3(invR.x, invG.x, invB.x);
vec3 invY = vec3(invR.y, invG.y, invB.y);
vec3 invA = fract(p.rgb);
p.rgb = mix(invX, invY, invA);
// VigCorrMode=VIGCORR_RADIAL
float vig = 1.0;
{
vec2 vigCorrCenter = vec2(1631.5000000000000000,
1223.5000000000000000);
float radiusScale=0.00049019607843137254000;
float radialVigCorrCoeff[4] = float[4](1.0000000000000000000,
-0.50230497890537296000, 0.64532807681882198000,
-0.34169389929015498000);
vec2 src = texture2DRect(CoordTexture, gl_TexCoord[0].st).sq;
vec2 d = src - vigCorrCenter;
d *= radiusScale;
vig = radialVigCorrCoeff[0];
float r2 = dot(d, d);
float r = r2;
vig += radialVigCorrCoeff[1] * r;
r *= r2;
vig += radialVigCorrCoeff[2] * r;
r *= r2;
vig += radialVigCorrCoeff[3] * r;
}
vec3 exposure_whitebalance = vec3(2.4239437533271841000,
2.4239437533271841000, 2.4239437533271841000);
p.rgb = (p.rgb * exposure_whitebalance) / vig;
p.rgb = p.rgb * 1023.0000000000000000;
vec2 destR = texture2DRect(DestLutTexture, vec2(p.r, 0.0)).sq;
vec2 destG = texture2DRect(DestLutTexture, vec2(p.g, 0.0)).sq;
vec2 destB = texture2DRect(DestLutTexture, vec2(p.b, 0.0)).sq;
vec3 destX = vec3(destR.x, destG.x, destB.x);
vec3 destY = vec3(destR.y, destG.y, destB.y);
vec3 destA = fract(p.rgb);
p.rgb = mix(destX, destY, destA);

gl_FragColor = p;
}

nona: GL info log:
Fragment shader was successfully compiled to run on hardware.

nona: GL info log:
Fragment shader(s) linked, no vertex shader(s) defined.d

gpu shader program compile time = 0.0624
gpu shader texture/framebuffer setup time = 0.156
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] coord image render
time = 0.0468
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] source chunk=[(0, 0)
to (3264, 2448) = (3264x2448)] src upload = 0.1248
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] source chunk=[(0, 0)
to (3264, 2448) = (3264x2448)] src render = 0.1248
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] source chunk=[(0, 0)
to (3264, 2448) = (3264x2448)] interpolation chunk=[(0, 0) to (4, 4) =
(4x4)] setup = 0
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] source chunk=[(0, 0)
to (3264, 2448) = (3264x2448)] interpolation chunk=[(0, 0) to (4, 4) =
(4x4)] render = 0.0156
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] normalization setup
= 0
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] normalization render
= 0
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] dest rgb disassembly
setup = 0
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] dest rgb disassembly
render = 0
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] rgb readback =
0.0468
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] dest alpha
disassembly setup = 0
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] dest alpha
disassembly render = 0
gpu dest chunk=[(0, 0) to (400, 294) = (400x294)] alpha readback =
0.0156
gpu destruct time = 0
gpu total time = 0.5928

Remapping (remapping PICT0048.JPG):
0%
Remapping (remapping PICT0048.JPG):
0%
Remapping (saving test_gup0000.tif):
0%

[Yuval Levy]

Hi Thomas,

thanks for looking into this.

T. Modes wrote:
> The trunk does not compile on windows. (I asked for help some time
> ago, but there was no reaction.)

yes, this is critical for release and I guess there will be some
reaction now. I also estimate that this is relatively easy to fix with
the combined brain power on this list.

> * include <sys/time.h> not found

would something like:

#ifdef _WIN32
#include <winsock.h>
#else
#include <sys/time.h>
#endif

work?

> Finally copy glut32.dll to hugin/bin-folder.

the current policy for the windows binary is to avoid DLHell and link
statically. This should not be too difficult to fix. I recall doing this
for GLEW while helping James integrate the fast preview a year ago. I
hope to find the time to fix my Windows build chain next week and have a
look into this if it has not been already solved by somebody else.

> Now the trunk is compiles and a first test run was successfull.

that's already a significant step forward. Can you provide a patch file
of what you did?

It would also be helpful to have some feedback about the status on OS X
from the many people working on that platform.

> Could someone (Andrew?) look at the points in ImageTransformsGPU.cpp
> and Interpolator.h? I don't know, if my fast fixes are correct

the whole point of putting things in trunk is for people to have a look.
One test is to run nona with the -g switch and without it on the same
images and compare outputs.

thanks again for moving forward so fast on this!
Yuv

[T. Modes]

Hi Yuv,

> > * include <sys/time.h> not found
>
> would something like:
>
> #ifdef _WIN32
> #include <winsock.h>
> #else
> #include <sys/time.h>
> #endif
>
> work?

It works only partially. The compiler complains about missing
gettimeofday. This function is not available on windows. Here we need
a replacement. (I found a file, but without clear licence, see my
previous post).

>
> > Finally copy glut32.dll to hugin/bin-folder.
>
> the current policy for the windows binary is to avoid DLHell and link
> statically. This should not be too difficult to fix. I recall doing this
> for GLEW while helping James integrate the fast preview a year ago. I
> hope to find the time to fix my Windows build chain next week and have a
> look into this if it has not been already solved by somebody else.
>
>

Then we have to look into glew to get a static version.

> > Now the trunk is compiles and a first test run was successfull.
>

> One test is to run nona with the -g switch and without it on the same
> images and compare outputs.
>

I tried both, but with -g switch I get an output image with only one
line of pixels (all other pixels are "empty"). So a comparision is
really difficult ;-)

Thomas

[T. Modes]

> that's already a significant step forward. Can you provide a patch file
> of what you did?
>

I uploaded the patch to sourceforge (https://sourceforge.net/tracker/?
func=detail&aid=2831177&group_id=77506&atid=550443)

Thomas

[Gerry Patterson]

Hi All,

I have attached a screen shot of what I was talking about in the previous e-mail.  Does this seem appropriate?

Best Regards,

- Gerry
 

[Yuval Levy]

Gerry Patterson wrote:
>> Rename the Enblend tab in the Preferences dialog to "Stitching". Add a
>> section called "Nona" (similar to the existing Enblend and Enfuse sections)
>> and here add entries for defaults to use in projects (interpolator, cropped
>> tiff output...). Here a checkbox could be added to enable GPU support by
>> default. This would be then saved in the global preferences (registry on
>> windows, ini files elsewhere)
>>
>> Then, on the stitcher tab, add a GPU checkbox in the nona optoins dialog.
>> This would allow the user to disable it if required for that particular
>> project. When the project is saved, this state would be stored in .pto
>> file.
>>
>> Does this make sense?
>>
>> - Gerry
>>
>>
> Hi All,
>
> I have attached a screen shot of what I was talking about in the previous
> e-mail. Does this seem appropriate?

yes. this is very much along the lines of what I was thinking. however
my thinking is still incomplete and instead of continuing to fiddle with
the code I stopped and took a broader look.

I see two ways to approach the problem:

1. forward-thinking: start with a GUI mockup and dig into the code to
implement the functionalities until it trickles down to the actual
project execution. your mockup is the start. this is what I did until I
came across an inconsistency that should not be: the -g option is passed
to the Makefile generated when saving the project, but not to the
Makefile generated when hitting "stitch now".

2. backward-thinking: start with the end, i.e. with the project
execution, and work upstream to the user defined parameters in the GUI.

I was actually able to *partially* pass the -g parameters to a Makefile:
The saved .pto.mk file was correct, so CLI stitching would work, and
probably also PTbatcher (I admit have not used/studied that part of
Hugin). But when I hit the "stitch now" button, the temporary Makefile
created differs from the saved one and it does not work.

Then I thought backward, digging into the code to the points where the
Makefiles are executed and where they are generated. To my shock, it is
different.

And I think I found at least one significant issue: Hugin relies on
wxWidgets to get/set preferences. This dependency handicaps CLI tools
which simply do not read these preferences and "forget" about settings
such as the tmp location or celeste's treshhold. Not
understandable/acceptable for the user who expects his preferences to be
honored.

wxWidgets has the advantage of abstracting the details of different
operating systems in dealing with the preferences: they are stored in
~/.hugin on Linux (and OSX) systems; and in the registry on Windows.
Fully transparent to Hugin. Very convenient, but with limitations:
unless we find a way to parse and implement these preferences in the CLI
tools, the current way of setting, reading and storing preferences is
unacceptable.

It is a major design bug that hitting "stitch now" or "save" in the
Hugin GUI on the same system and with the same project yields two
different Makefiles.

We need a consistent way to set/store/get preferences that is
independent of wxWidgets and that can be used by *all* tools - whether
GUI or CLI.

generating and reading .pto and .pto.mk files should always yield the
same results.

I see two solutions to the problem.

The comprehensive solution would be a new (as in: consider if there are
solutions already used by other Open Source projects before writing from
scratch) library to deal with the setting/storing/reading preferences
that can be linked from both the GUI and the CLI tools; or a workaround
parser that parses the existing preferences settings wherever they are
(~/.hugin file or hugin registry key) to make them available to the CLI
tools.

I personally tend more toward the "new" solution. A good one would also
free us of the Windows registry and save the preferences in a .ini file,
and maybe even move to an XML file format (for both preferences and
project files) making it easier to maintain and expand.

In the meantime trying to pass arguments as the -g will necessarily be a
dirty job.

Yuv

[Tom Sharpless]

Hey Yuv

On Aug 2, 10:09 am, Yuval Levy <goo...@levy.ch> wrote:

> the current policy for the windows binary is to avoid DLHell and link
> statically.
>

That is a good policy with respect to many of the open source
libraries included in the Hugin code base, that tend to be in a
constant state of flux. Building them along with Hugin is a sensible
defense against "version Hell".

It is not a good policy with respect to stable, standardized system
components such as GLUT. Using DLLs for such things is absolutely
correct, and on Windows is actually more reliable as well as far
easier than trying to create equivalent static libraries. Would you
suggest that we replace mingw10.dll with a static link library? I
might point out that all "professional" versions of Unix (and even
Linux) make extensive use of dynamically linked shared libraries; so
does your web browser; so does Java....

I can remember when Windows really was "DLL Hell". But that was a
very long time ago; now it would be more accurate to say Windows is
"static library Hell", as all the checks, balances, revlocks and
manifests Microsoft has set up since then (many to get DLL Hell under
control) now place a terrible burden on the static builder. Building
DLLs is easy by comparison.

Deploying a specific DLL to support a specific program is just as
reliable as deploying any other executable: simply put it in your
product's executables directory. Then your product will always link
to it, and no other product will ever see it. MS had to rewrite a lot
of the Windows (NT 4.0) kernel to implement that sensible policy; but
now that it is in place, there is no more DLL Hell.

Cheers, Tom




I would suggest the following policy. If you can get a prebuilt
standard DLL you need to run Hugin, from a reputable developer, use
that. Build from source only when you wrote or modified the source.

[T. Modes]

T. Modes schrieb:

I uploaded a modified patch to sourceforge. This one compiles without
problems on windows.
Could someone please test if this breaks something on linux or osx?

But the output of nona -g is still wrong (only one line is remapped).

Running nona with -v switch results in a crash.

Thomas

[David Haberthür]

Hello all.

> Now the trunk is compiles and a first test run was successfull.

that's already a significant step forward. Can you provide a patch file
of what you did?

It would also be helpful to have some feedback about the status on OS X
from the many people working on that platform.

I'm still unable to compile even a basic checkout of hugin, as de3scribed here: http://groups.google.com/group/hugin-ptx/msg/d532f667e6e56da4 , so I'm unable to test a patch...

Habi 

[Yuval Levy]

Hi Tom,

Tom Sharpless wrote:
> That is a good policy with respect to many of the open source
> libraries included in the Hugin code base, that tend to be in a
> constant state of flux. Building them along with Hugin is a sensible
> defense against "version Hell".
>
> It is not a good policy with respect to stable, standardized system
> components such as GLUT.

a mixed dealing of static and dynamic is confusing.

moreover, can you guarantee that the user won't go into the installation
folder and fiddle with those DLLs? or some anti-virus software go ballistic?

> I would suggest the following policy. If you can get a prebuilt
> standard DLL you need to run Hugin, from a reputable developer, use
> that. Build from source only when you wrote or modified the source.

this would require changes in the CMake build (which is already far from
robust) and of the related SDK.

if somebody feels like cleaning up, a robust CMake build should let the
builder switch between static and dynamic linking with a parameter. Then
we can have static and dynamic builds next to each other, compare pros
and cons, make some experiences and make an informed decision.

Yuv

[Yuval Levy]

Hi Thomas,

T. Modes wrote:
> It works only partially. The compiler complains about missing
> gettimeofday. This function is not available on windows. Here we need
> a replacement. (I found a file, but without clear licence, see my
> previous post).

http://www.winehq.org/pipermail/wine-devel/2003-June/018082.html

says GPL. I'm still on Linux, have not tried it.

> I tried both, but with -g switch I get an output image with only one
> line of pixels (all other pixels are "empty"). So a comparision is
> really difficult ;-)

I would say comparison is really easy. Unfortunately it tells us that
whatever happened is not right yet.

Yuv

[T. Modes]

Hi Yuv,

I have uploaded a modifed patch to sourceforge. This compiles fine on
windows and does not need any external files. But I had to change some
lines in ImageTransformsGPU.cpp. It should now use GetTickCount on
windows (which is faster) and gettimeofday on linux. So could you test
if the patch works under linux or if it breaks.

> > I tried both, but with -g switch I get an output image with only one
> > line of pixels (all other pixels are "empty"). So a comparision is
> > really difficult ;-)
>
> I would say comparison is really easy. Unfortunately it tells us that
> whatever happened is not right yet.
>

I can't locate the one line output of nona -g in the normal remapped
images.

With nona -g the remapped images has sometimes slightly other width:

Image 1:
nona: 2472x1823
nona -g: 2472x1823
(here it's the same)

Image 2:
nona: 3060x1823
nona -g: 3064x1823

or a smaller test
nona: 398x294
nona -g: 400x294

So with nona -g the width is always a multiple of 8, but the height
not.

Thomas

[Yuval Levy]

Hi Thomas,

T. Modes wrote:
> could you test if the patch works under linux or if it breaks.

once the typo at line 47 in ImageTransformsGPU.cpp is fixed, it builds.

I think you can commit it.

> With nona -g the remapped images has sometimes slightly other width:

this is because a multiple of 8 yields faster GPU transferts. the
question is: can we identify the padding pixels and crop them away from
the result after it is out of the GPU?

we'll have to look at this while polishing up for release. There are use
cases where the padding pixels are a nuisance (e.g. if the result should
be an equirectangular of 398x199, 400x199 won't do). I filed a bug
report:
<https://sourceforge.net/tracker/?func=detail&aid=2831574&group_id=77506&atid=550441>

I'm currently on a laptop that does not have a useful GPU to test:

$ nona -g -o gputest.jpg _MG_8768-_MG_8873.pto
get fences failed: -1
param: 6, val: 0
nona: using graphics card: Tungsten Graphics, Inc Mesa DRI Intel(R)
915GM GEM 20090326 2009Q1 RC2 x86/MMX/SSE2
nona: extension GL_ARB_fragment_shader = false
nona: extension GL_ARB_vertex_shader = false
nona: extension GL_ARB_shader_objects = false
nona: extension GL_ARB_shading_language_100 = false
nona: extension GL_ARB_texture_rectangle = true
nona: extension GL_ARB_texture_border_clamp = true
nona: this graphics card lacks the necessary extensions for -g.
nona: sorry, the -g flag is not going to work on this machine.

Makes me think of the preference settings for Hugin: would it be useful
to run these tests on starting Hugin, and graying out the preference if
the GPU can't be used?

Yuv

[T. Modes]

Yuval Levy schrieb:

> Hi Thomas,
>
> T. Modes wrote:
> > could you test if the patch works under linux or if it breaks.
>
> once the typo at line 47 in ImageTransformsGPU.cpp is fixed, it builds.
>
> I think you can commit it.
>
>

Thanks Yuv, I commited the patch.

[Carl von Einem]

Yuval Levy wrote:
>
> I'm currently on a laptop that does not have a useful GPU to test:

> [...]

> Makes me think of the preference settings for Hugin: would it be useful
> to run these tests on starting Hugin, and graying out the preference if
> the GPU can't be used?

Panini shows some very useful information "About your OpenGL
Implementation" in the "about Panini" dialog.

Either a tab in the preferences dialog or the "about" dialog would be a
great place to list some technical information about the system / hardware.

Maybe there is also a way to suggest a max. amount of RAM for enblend or
other settings.

Carl

[Guido Kohlmeyer]

I run a small build test based on my SDK with an integrated fresh built
dynamic glut library.
The build works for a dynamic library, but the DLL is currently not
copied to INSTALL/FILES/bin.
Before I start to modify some cmake files I want to ask about a test
szenario to check to build result. I didn't followed the discussion
about the broken build in depth.
Therefore I have these questions:
1. How can I test whether glut integration is working well?
2. a. Where should the glut dynamic library be copied?
2.b. Or should we use a static lib instead?

Guido

[Yuval Levy]

Guido Kohlmeyer wrote:
> the DLL is currently not copied to INSTALL/FILES/bin.

you will need to tell Cmake to copy it from a folder in the SDK to
INSTALL/FILES/bin

something like:

INSTALL(glew.dll DESTINATION ${BINDIR})

> test szenario to check to build result. I didn't followed the discussion
> about the broken build in depth.

the build is fixed now. to test the build, just cd to the binaries
folder and start nona with GPU and with a test project:

nona -g -o output.tif project.pto

> 1. How can I test whether glut integration is working well?

see above.

> 2. a. Where should the glut dynamic library be copied?

if you really want to, into the same folder where nona is copied. but
make the dynamic linking optional, with default for static linking, please.

> 2.b. Or should we use a static lib instead?

I would prefer static libs first. Once 2009.2 is out, we can look into
moving the Windows version from full static build to either full dynamic
or mixed build.

There is already enough on the plate for 2009.2. And for Windows.

I committed today Ryan's Visual Studio 2008 x64 compile fixes. That's
half of the patches to produce a Windows 64bit version - a request that
has been in the air for quite some time and which has more significant
impact on the users than how libraries are linked.

If I am not mistaken the second half of his patches [0] are for the SDK,
that will need an update.

Speaking of the SDK, I don't like the current status. Unless my memory
betrays me, the original SDK had all the binaries to build Hugin *and*
Enfuse-Enblend. Even if it didn't, I think a proper SDK should because
Hugin requires Enfuse-Enblend.

So bottom line: there is a lot of pent-up work and I don't think that
we'll do ourselves or our Windows users a favor by venturing now into
changing how libraries are linked.

Yuv

[0] -
<https://sourceforge.net/tracker/?func=detail&aid=2789320&group_id=77506&atid=550443>

[Guido Kohlmeyer]

Yuval Levy schrieb:

> Guido Kohlmeyer wrote:
>
>> the DLL is currently not copied to INSTALL/FILES/bin.
>>
>
> you will need to tell Cmake to copy it from a folder in the SDK to
> INSTALL/FILES/bin
>
> something like:
>
> INSTALL(glew.dll DESTINATION ${BINDIR})
>
>
>

Thanks for the hint. My comment was not intended to ask for this hint
but rather only to note about the current status of build configuration
in current trunk. :-)

>> test szenario to check to build result. I didn't followed the discussion
>> about the broken build in depth.
>>
>
> the build is fixed now. to test the build, just cd to the binaries
> folder and start nona with GPU and with a test project:
>
> nona -g -o output.tif project.pto
>

Thanks.

>> 2.b. Or should we use a static lib instead?
>>
>
> I would prefer static libs first. Once 2009.2 is out, we can look into
> moving the Windows version from full static build to either full dynamic
> or mixed build.
>

ok, I'll try to generate a static lib configuration.

> There is already enough on the plate for 2009.2. And for Windows.
>
> I committed today Ryan's Visual Studio 2008 x64 compile fixes. That's
> half of the patches to produce a Windows 64bit version - a request that
> has been in the air for quite some time and which has more significant
> impact on the users than how libraries are linked.
>
> If I am not mistaken the second half of his patches [0] are for the SDK,
> that will need an update.
>
> Speaking of the SDK, I don't like the current status. Unless my memory
> betrays me, the original SDK had all the binaries to build Hugin *and*
> Enfuse-Enblend. Even if it didn't, I think a proper SDK should because
> Hugin requires Enfuse-Enblend.
>

I only maintan the 32-bit part of the SDK, cause I don't have a 64-bit
OS. I don't mind if Ryan will provide an extended/modified SDK for
64-bit. For instance in terms of an archive that will contain all
additional files which can easily be copied into my base SDK. The second
point (enblend/enfuse) is likely religious :-) I followed the approach
to use stable releases of all additional applications and libraries.
Thus I take the maybe meanwhile outdated stable version of
enblend/enfuse. If there is any other version which is likely stable I
can integrate it. Currently I cannot see such version on the
enblend/enfuse homepage. I know you prefer another build chain approach
in terms of a bleeding edge environment.

> So bottom line: there is a lot of pent-up work and I don't think that
> we'll do ourselves or our Windows users a favor by venturing now into
> changing how libraries are linked.
>
>

Well that's right, but I know about the library problems on windows (DLL
hell), and before I choose one of two ways I wanted to get some
impressions which way would be prefered.

[Harry van der Wolf]

2009/8/3 David Haberthür <david.ha...@gmail.com>

Hi Habi,

(Still on holiday, some occasional access to internet)

The problem with the "flat namespace" has to do with the fact that one or more libraries are compiled as "Universal", hence the "flat namespace", and some others expect architecture like headers like ppc or i386 (I don't know exactly, only that this is the issue).

Coming weekend I will be home again and check my backups (fortunately I had an rsync script running on my macbook that made backups to network every 2 and/or 4 hours of important parts of my disk) as I did not decide yet whether I will buy a mac again and which one.

The boost problem is no longer related to the specified issue in the (http://wiki.panotools.org/Hugin_Compiling_OSX#Fix_libboost) as far as I can remember.

Harry

 

Habi 

[Guido Kohlmeyer]

Yuval Levy schrieb:

> the build is fixed now. to test the build, just cd to the binaries
> folder and start nona with GPU and with a test project:
>
> nona -g -o output.tif project.pto
>

I've tested a static glut library an my machine but unfortunately my
graphic card does not support the mandatory OpenGL methods. Nevertheless
the glut initialization function glutCreateWindow works and delivers an
interger number. I tested this in the dubugger. Therefore I expect that
the library will work.

Please find attached a small SDK extension. Simply rename the file
glut.txt to glut.zip and extract it to the SDK directory. There should
be a directory glut afterwards.
Furthermore the CMakeLists.txt which resides in root directory of the
trunk has to be modified. I attached my current one.
Thomas maybe you can test whether it will fix your build problems. If so
I will update the SDK and the files in the repository.

Thanks,
Guido

[T. Modes]

Hi Guido,

with your updated SDK and CMakeLists.txt it compiles without problems.
You can update the SDK and the files in repository.

But nona -g does not work as expected. Now I'm getting an empty output
image.

Thomas

[Yuval Levy]

Guido Kohlmeyer wrote:
> ok, I'll try to generate a static lib configuration.

thanks

>> Speaking of the SDK, I don't like the current status. Unless my memory
>> betrays me, the original SDK had all the binaries to build Hugin *and*
>> Enfuse-Enblend. Even if it didn't, I think a proper SDK should because
>> Hugin requires Enfuse-Enblend.
>>
> I only maintan the 32-bit part of the SDK, cause I don't have a 64-bit
> OS. I don't mind if Ryan will provide an extended/modified SDK for
> 64-bit. For instance in terms of an archive that will contain all
> additional files which can easily be copied into my base SDK.

this is similar to how I see it: we need an official SDK that contains
your contributions, Ryan's contributions, and the contributions of
whoever else does it. If it makes sense to have two separate SDKs
(32bit/64bit) so be it. But the official SDK should be a complete and
stable one.

> The second
> point (enblend/enfuse) is likely religious :-) I followed the approach
> to use stable releases of all additional applications and libraries.
> Thus I take the maybe meanwhile outdated stable version of
> enblend/enfuse. If there is any other version which is likely stable I
> can integrate it. Currently I cannot see such version on the
> enblend/enfuse homepage. I know you prefer another build chain approach
> in terms of a bleeding edge environment.

I don't see it as religious choice of mutually exclusive preferences :-)

There are two distinct types of SDK with two distinct purposes:
- a stable SDK, for the purpose of building rock-solid stable releases
- a bleeding-edge SDK, for the purpose of developing the future, giving
feedback to upstream libraries and code providers, add new features to
Hugin.

You are focused on the stable SDK. We might differ on the details, but
in principle I agree with you. We need a stable, *complete* SDK for
this, to which you, Ryan, and others can contribute. I find what is
currently your SDK to be incomplete, even just for a pure 32bit build
(which is what I do, although I have an XP_64 license, it is currently
not installed).

At this moment my experience enblend-enfuse 3.2 is that it is not
stable, even if it is the official "stable" distribution. I would
replace it with a current build from Christoph Spiel's staging branch. I
don't know if you would prefer to leave it as-is or to step back to 3.0,
or anything in between.

>> So bottom line: there is a lot of pent-up work and I don't think that
>> we'll do ourselves or our Windows users a favor by venturing now into
>> changing how libraries are linked.
>>
>>
> Well that's right, but I know about the library problems on windows (DLL
> hell), and before I choose one of two ways I wanted to get some
> impressions which way would be prefered.

both ways: the static link for stable and the dynamic link for bleeding
edge ;-)

Yuv

[Yuval Levy]

Hi Guido,

Guido Kohlmeyer wrote:
> Yuval Levy schrieb:
>> the build is fixed now. to test the build, just cd to the binaries
>> folder and start nona with GPU and with a test project:
>>
>> nona -g -o output.tif project.pto
>>
> I've tested a static glut library an my machine but unfortunately my
> graphic card does not support the mandatory OpenGL methods.

can you post a binary of yout nona-gpu for download so that Windows
users with an appropriate video card can give it a try?

I am particularly keen to hear about speed improvements (or not), i.e.
have the user report their system's performance when doing:

nona -o output.tif project.pto
vs.

nona -g -o output.tif project.pto

we need to know about the system:
- CPU (model, frequency, RAM, etc.)
- GPU (model, frequency, RAM, etc.)

note that nona will automatically use all the cores in a system, but if
you want to be sure, just add -t N with N being the number of threads to
be used (2 on dual core machines, 4 on quad core, 8 on core i7 that have
4 cores + 2 threads/core)

> Please find attached a small SDK extension.

thanks
Yuv

[Yuval Levy]

T. Modes wrote:
> nona -g does not work as expected. Now I'm getting an empty output
> image.

does it take long until it returns from execution?

Yuv

[Guido Kohlmeyer]

Hi Yuval,

I uploaded an archived version of nona to the panotools webspace:
http://hugin.panotools.org/testing/hugin/nona.zip

It is based on my current build environment.

Due to the fact that a lot of progress is done using GPU power it is
time to get a new machine. My laptop is more and more unstable (maybe
broken motherbord) and my desktop is much older.

[Yuval Levy]

Hallo Guido,

Guido Kohlmeyer wrote:
> I uploaded an archived version of nona to the panotools webspace:
> http://hugin.panotools.org/testing/hugin/nona.zip

thank you. I'll boot into Windows tomorrow and try it. On Ubuntu I did
not have much chance.

> Due to the fact that a lot of progress is done using GPU power it is
> time to get a new machine. My laptop is more and more unstable (maybe
> broken motherbord) and my desktop is much older.

seems that we are in the same boat. laptop (HP Compaq nc6120) has a dry
contact on the ICH7. Useless in Windows, in Ubuntu I can still use it
reasonably well but have to do some pressure / massage from time to time
to get the contacts going again. desktop: AMD X2 6000+ with 8GB RAM.
Probably buying a video card to complement the on board nVidia 6150
should do, but which video card? I have no clue of today's video cards
market (the last one I bought was in 2002, still AGP). I'm no gamer, but
a nice video card that can be used for nona-gpu and maybe Photoshop
would be nice.

who recommends what and why?

Yuv