Discussion:
The way to 2009.2
(too old to reply)
Yuval Levy
2009-08-02 02:57:25 UTC
Permalink
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




--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
Gerry Patterson
2009-08-02 04:33:50 UTC
Permalink
Post by 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/>
* 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
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

--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
Gerry Patterson
2009-08-02 16:55:28 UTC
Permalink
Post by Gerry Patterson
Post by 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/>
* 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
Hello,
I have kicked off a build on my Linux system and will report my findings.
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?

Best Regards,

- 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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
Yuval Levy
2009-08-02 21:20:05 UTC
Permalink
Post by Gerry Patterson
Post by Gerry Patterson
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

--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
T. Modes
2009-08-02 08:16:12 UTC
Permalink
Post by Yuval Levy
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

--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
T. Modes
2009-08-02 13:21:05 UTC
Permalink
Post by T. Modes
Post by Yuval Levy
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%
--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
Yuval Levy
2009-08-02 14:09:08 UTC
Permalink
Hi Thomas,

thanks for looking into this.
Post by T. Modes
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.
Post by T. Modes
* include <sys/time.h> not found
would something like:

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

work?
Post by T. Modes
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.
Post by T. Modes
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.
Post by T. Modes
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

--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
T. Modes
2009-08-02 16:17:27 UTC
Permalink
Hi Yuv,
Post by Yuval Levy
Post by T. Modes
* include <sys/time.h> not found
#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).
Post by Yuval Levy
Post by T. Modes
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.
Post by Yuval Levy
Post by T. Modes
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
--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
Yuval Levy
2009-08-03 13:00:30 UTC
Permalink
Hi Thomas,
Post by T. Modes
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.
Post by T. Modes
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

--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
T. Modes
2009-08-03 14:06:02 UTC
Permalink
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.
Post by Yuval Levy
Post by T. Modes
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


--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
Yuval Levy
2009-08-03 16:24:02 UTC
Permalink
Hi Thomas,
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.
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

--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
T. Modes
2009-08-03 16:38:31 UTC
Permalink
Post by Yuval Levy
Hi Thomas,
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.
--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
Carl von Einem
2009-08-03 20:07:01 UTC
Permalink
Post by Yuval Levy
[...]
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

--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
T. Modes
2009-08-02 16:33:55 UTC
Permalink
Post by Yuval Levy
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
--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
T. Modes
2009-08-03 08:11:07 UTC
Permalink
Post by T. Modes
Post by Yuval Levy
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
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
--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
Tom Sharpless
2009-08-03 04:30:46 UTC
Permalink
Hey Yuv
Post by Yuval Levy
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.
--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
Yuval Levy
2009-08-03 12:55:44 UTC
Permalink
Hi Tom,
Post by Tom Sharpless
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?
Post by Tom Sharpless
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

--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
Guido Kohlmeyer
2009-08-03 21:34:41 UTC
Permalink
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

--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
Yuval Levy
2009-08-03 23:57:47 UTC
Permalink
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>



--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
Guido Kohlmeyer
2009-08-04 08:33:34 UTC
Permalink
Post by Yuval Levy
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
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. :-)
Post by Yuval Levy
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
nona -g -o output.tif project.pto
Thanks.
Post by Yuval Levy
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.
Post by Yuval Levy
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.
Post by Yuval Levy
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.


--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
Yuval Levy
2009-08-04 15:21:05 UTC
Permalink
Post by Guido Kohlmeyer
ok, I'll try to generate a static lib configuration.
thanks
Post by Guido Kohlmeyer
Post by Yuval Levy
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.
Post by Guido Kohlmeyer
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.
Post by Guido Kohlmeyer
Post by Yuval Levy
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

--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
Guido Kohlmeyer
2009-08-04 11:11:30 UTC
Permalink
Post by Yuval Levy
the build is fixed now. to test the build, just cd to the binaries
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

--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
T. Modes
2009-08-04 12:53:50 UTC
Permalink
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
Post by Guido Kohlmeyer
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.
--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
Yuval Levy
2009-08-04 15:24:16 UTC
Permalink
Post by T. Modes
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

--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
Yuval Levy
2009-08-04 15:21:15 UTC
Permalink
Hi Guido,
Post by Guido Kohlmeyer
Post by Yuval Levy
the build is fixed now. to test the build, just cd to the binaries
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)
Post by Guido Kohlmeyer
Please find attached a small SDK extension.
thanks
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
Guido Kohlmeyer
2009-08-05 00:22:45 UTC
Permalink
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.
Post by Yuval Levy
nona -o output.tif project.pto
vs.
nona -g -o output.tif project.pt
--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
Yuval Levy
2009-08-05 03:56:40 UTC
Permalink
Hallo Guido,
Post by Guido Kohlmeyer
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.
Post by Guido Kohlmeyer
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

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

David Haberthür
2009-08-03 08:16:28 UTC
Permalink
Hello all.
Post by T. Modes
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

--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
Harry van der Wolf
2009-08-04 08:51:30 UTC
Permalink
Post by David Haberthür
Hello all.
Post by T. Modes
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...
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
Post by David Haberthür
Habi
--~--~---------~--~----~------------~-------~--~----~
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-***@googlegroups.com
To unsubscribe from this group, send email to hugin-ptx-***@googlegroups.com
For more options, visit this group at http://groups.google.com/group/hugin-ptx
-~----------~----~----~----~------~----~------~--~---
Continue reading on narkive:
Loading...