From: dmg <dmg...@uv...> - 2006-07-29 06:53:55
|
I started renaming the library to pano13. It is amazing in how many places it is hardcoded :) At least in the Unixes it should be building pano13 and installing under pano13/ In the process I also updated the version to 2.8.5pre1. I am going to start using -preN suffixes to make sure that we don't have binaries with the same library number, but different functionality. For instance, the idea is that we release binaries, and in the next functional change we update the version to the next number. I have tested the library under OS X and Linux and it seems to be working (in this delta I also killed one bug I recently introduced). -- Daniel M. German "I'm crazy, but I'm not stupid" Jackie Chan http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Max L. <max...@ve...> - 2006-07-29 20:21:56
|
I managed to compile the SVN version of the code today for the first time, and found that PTMender doesn't work, and all of the tests fail. All attempts to run PTMender result in a dialog box saying "Could not open _PTStitcher_tmp_0000xx for writing" and then the program exits. I've spent a few hours on it this afternoon and think I've tracked down the problem to the new metadata shuffling code. Specifically, the problem is that in "panoTiffSetImageProperties" (line 1019 in tiff.c), the calls that set the samplesPerPixel and bitsPerSample are trying to use a value of zero, which is what the metadata struct contains. Here's what I see in GDB at this point: Breakpoint 4, panoTiffSetImageProperties (file=0x3f7c90) at tiff.c:1019 1019 returnValue = 1: returnValue = 1 (gdb) p *metadata $26 = {imageWidth = 1168, imageHeight = 411, isCropped = 1, xPixelsPerResolution = 150, yPixelsPerResolution = 150, resolutionUnits = 2, samplesPerPixel = 0, bitsPerSample = 0, bytesPerLine = 0, rowsPerStrip = 1, compression = {type = 32773, predictor = 0}, iccProfile = {size = 0, data = 0x0}, cropInfo = {fullWidth = 1190, fullHeight = 418, croppedWidth = 1168, croppedHeight = 411, xOffset = 0, yOffset = 0}, copyright = 0x0, datetime = 0x0, imageDescription = 0x0, artist = 0x0, bytesPerPixel = 0, bitsPerPixel = 0} (gdb) n 1040 if (returnValue && metadata->bitsPerSample == 32) 1: returnValue = 0 It looks to me like these fields probably ought to have been populated at this point in the code, but they are still zero. This causes PTMender to give up with the error message. Because I'm not familiar with the thinking behind how all of this metadata code should work, I thought I'd post here and see if someone has more familiarity with this and knows how to fix the problem without creating more problems! I've tried this with both JPEG and TIFF files as input, because I thought that the "source" metadata might be different depending on the input image format. The error appears with both image types. Max > > I started renaming the library to pano13. It is amazing in how many > places it is hardcoded :) At least in the Unixes it should be building > pano13 and installing under pano13/ > > In the process I also updated the version to 2.8.5pre1. I am going to > start using -preN suffixes to make sure that we don't have binaries > with the same library number, but different functionality. For > instance, the idea is that we release binaries, and in the next > functional change we update the version to the next number. > > I have tested the library under OS X and Linux and it seems to be > working (in this delta I also killed one bug I recently introduced). > > > > > > -- > Daniel M. German "I'm crazy, but I'm not stupid" > Jackie Chan > http://turingmachine.org/ > http://silvernegative.com/ > dmg (at) uvic (dot) ca > replace (at) with @ and (dot) with . > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel |
From: Daniel M. G. <dmg...@uv...> - 2006-07-29 20:44:21
|
Hi Max, Max> I managed to compile the SVN version of the code today for the first time, and Max> found that PTMender doesn't work, and all of the tests fail. All attempts to Max> run PTMender result in a dialog box saying "Could not open Max> _PTStitcher_tmp_0000xx for writing" and then the program exits. Max> I've spent a few hours on it this afternoon and think I've tracked down the Max> problem to the new metadata shuffling code. Specifically, the problem is that Max> in "panoTiffSetImageProperties" (line 1019 in tiff.c), the calls that set the Max> samplesPerPixel and bitsPerSample are trying to use a value of zero, which is Max> what the metadata struct contains. Here's what I see in GDB at this point: I spent some time making sure that PTmender worked under Linux and OS X. It passes all the tests there. I can only think of one thing: I might have an dangling pointer or initialized memory that is messing things up (yesterday I detected a similar problem in CreateStitchingMasks). Max, could you please tell me the backtrace of this problem? Max> Breakpoint 4, panoTiffSetImageProperties (file=0x3f7c90) at tiff.c:1019 Max> 1019 returnValue = Max> 1: returnValue = 1 Max> (gdb) p *metadata Max> $26 = {imageWidth = 1168, imageHeight = 411, isCropped = 1, xPixelsPerResolution = 150, yPixelsPerResolution = 150, resolutionUnits = 2, samplesPerPixel = 0, bitsPerSample = 0, bytesPerLine = 0, rowsPerStrip = 1, compression = {type = 32773, predictor = 0}, iccProfile = {size = 0, data = 0x0}, cropInfo = {fullWidth = 1190, fullHeight = 418, croppedWidth = 1168, croppedHeight = 411, xOffset = 0, yOffset = 0}, copyright = 0x0, datetime = 0x0, imageDescription = 0x0, artist = 0x0, bytesPerPixel = 0, bitsPerPixel = 0} Max> (gdb) n Max> 1040 if (returnValue && metadata->bitsPerSample == 32) Max> 1: returnValue = 0 Max> It looks to me like these fields probably ought to have been populated at this Max> point in the code, but they are still zero. This causes PTMender to give up Max> with the error message. Max> Because I'm not familiar with the thinking behind how all of this metadata code Max> should work, I thought I'd post here and see if someone has more familiarity Max> with this and knows how to fix the problem without creating more problems! I guess that is me. Essentially the way the metadata works is the following: * The metadata is part of the image struct * When image is read, the metadata is set accordingly. * To create an image (TIFF), copy and/or set the metadata accordingly. Then create the file. * Most functions that access the metadata are (or at least should be) well encapsulated. Max> I've tried this with both JPEG and TIFF files as input, because I thought that Max> the "source" metadata might be different depending on the input image format. Max> The error appears with both image types. Max> Max - Daniel M. German "The WWW might get the glory, but e-mail is the quiet Beppi Crosanol -> workhorse of the digital age." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Max L. <max...@ve...> - 2006-07-29 22:27:35
|
That was the problem. I updated the read image function in bmp.c to make it look like the one in ppm.c, and now PTMender can read JPEG and TIFF files as input. However, the code to read BMP, PNG and HDR files is broken. Because of the new metadata stuff, all of these formats need to have corresponding panoReadBMP, panoReadPNG and panoReadHDR routines like we now have for TIFF and JPEG. These functions don't exist (and may not even make much sense for some of these formats...I'm not sure). However, without them, the code will run into the same problems I encountered today...the program will exist when trying to set TIFF bitsPerSample and samplesPerPixel values to zero. This could lead to some disgruntled users because Pano Tools used to be able to read these formats (at least for the Windows folks), but now it can't. Max > I think I found the problem. It looks like the functions in ppm.c (readImage, > writeImage, etc.) have all been updated to deal with the new metadata stuff, > but not the functions in bmp.c (which is what us Windows folks use). > > I think the solution is to figure out if we really need two versions of these > functions, and if not then combine them into one file. > > I guess it also outlines the importance of testing on different operating > systems. (Speaking of which, I also had to #define the new "bzero" calls to > "memset"...this function isn't present on my system). > > Max > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel |
From: Daniel M. G. <dmg...@uv...> - 2006-07-30 06:13:47
|
Hi Max, I think it would be great to be able to do more testing, but I am not sure how each of us can guarantee that every change works in every system. For instance, my tests passed under OS X and Linux. Do you have any suggestions? Perhaps at some point we can determine a new-features freeze and then do extensive testing. We would also benefit from more test cases (like the alternate inputs). With regard to users, I fully agree that they can be disgrunted. But I think they have to understand we are in a development cycle. Perhaps we could add a warning, so users know that they are not meant to be fully reliable. After all we need users to remove obscure bugs. We could also set some targets for the next release, and work towards them, then release. What do others think? -- daniel Max Lyons twisted the bytes to say: Max> That was the problem. I updated the read image function in bmp.c to make it Max> look like the one in ppm.c, and now PTMender can read JPEG and TIFF files as Max> input. Max> However, the code to read BMP, PNG and HDR files is broken. Because of the new Max> metadata stuff, all of these formats need to have corresponding panoReadBMP, Max> panoReadPNG and panoReadHDR routines like we now have for TIFF and JPEG. These Max> functions don't exist (and may not even make much sense for some of these Max> formats...I'm not sure). However, without them, the code will run into the Max> same problems I encountered today...the program will exist when trying to set Max> TIFF bitsPerSample and samplesPerPixel values to zero. Max> This could lead to some disgruntled users because Pano Tools used to be able to Max> read these formats (at least for the Windows folks), but now it can't. Max> Max >> I think I found the problem. It looks like the functions in ppm.c (readImage, >> writeImage, etc.) have all been updated to deal with the new metadata stuff, >> but not the functions in bmp.c (which is what us Windows folks use). >> >> I think the solution is to figure out if we really need two versions of these >> functions, and if not then combine them into one file. >> >> I guess it also outlines the importance of testing on different operating >> systems. (Speaking of which, I also had to #define the new "bzero" calls to >> "memset"...this function isn't present on my system). >> >> Max >> >> >> >> ------------------------------------------------------------------------- >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to share your >> opinions on IT & business topics through brief surveys -- and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> _______________________________________________ >> PanoTools-devel mailing list >> Pan...@li... >> https://lists.sourceforge.net/lists/listinfo/panotools-devel Max> ------------------------------------------------------------------------- Max> Take Surveys. Earn Cash. Influence the Future of IT Max> Join SourceForge.net's Techsay panel and you'll get the chance to share your Max> opinions on IT & business topics through brief surveys -- and earn cash Max> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV Max> _______________________________________________ Max> PanoTools-devel mailing list Max> Pan...@li... Max> https://lists.sourceforge.net/lists/listinfo/panotools-devel -- Daniel M. German "One has to be grown up enough to realize that life is not fair. You just have to do the best Stephen W. Hawking -> you can in the situation you are in." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Max L. <max...@ve...> - 2006-07-30 15:13:57
|
> > I think it would be great to be able to do more testing, but I am not > sure how each of us can guarantee that every change works in every > system. For instance, my tests passed under OS X and Linux. > > Do you have any suggestions? It is tricky, and I don't have a solution. When Dersch was running the show I think he had access to, and tested on all major platforms (Windows, Mac and Linux). My unscientific guess is that many (most?) of the developers are now using something other than Windows, but many (most?) of the users are using Windows. That puts us in the somewhat odd position that I found yesterday...as far as the developers know everything is going just fine, but the code is broken for the majority of end users! Perhaps one thing we could do to ameliorate the situation is to implement a "you break it, you buy it" type of policy. If I am responsible for breaking something, then I ought to be responsible for trying to fix it. Or, I am reponsible for rolling back my changes until such time as I can figure out how to fix it. In any case, I will try and fix up the Windows code as much as possible. After reworking the readImage function, TIFF and JPEG input seem to work OK. However, BMP, PNG and HDR input are still completely broken. I can probably reuse the code in jpeg.c (the stuff commented with "should be considered a hack") for BMP and PNG input. I have no idea about the HDR stuff, but maybe someone else knows more about this. I also noticed that if I run a script for which the images don't exist I get a message saying "We only support 3 or 4 samples per pixel". This is misleading...we might want a message saying something like "Cannot open input image". The program also crashes at this point (I think it is trying to do a TIFFClose with a null reference). Lastly...are there any other Windows developers who can compile this stuff "out of the box"? Or does everyone else have to fool around with editing/creating their own makefiles? I've never been able to get the autoconf/configure stuff to work. I've always had to roll my own makefiles. I now get an endless stream of multiple definition errors when trying to compile PTMender. It seems to be related to the tiff functions that are defined in pano12.dll, the tiff functions that are in libtiff and trying to compile ptmender with tiff.c and link to libtiff and pano12.dll at the same time. My plan is to build ptmender without pano12 (or pano13 or whatever it is called now), and statically link with the sources from the main pano12 library. This seems to work OK, and will probably go a long way towards eliminating the endless stream of questions that I get from folks with mismatched executables and DLL files. Max |
From: Daniel M. G. <dmg...@uv...> - 2006-07-30 18:28:13
|
>> I think it would be great to be able to do more testing, but I am not >> sure how each of us can guarantee that every change works in every >> system. For instance, my tests passed under OS X and Linux. >> >> Do you have any suggestions? Max> It is tricky, and I don't have a solution. When Dersch was running the show I Max> think he had access to, and tested on all major platforms (Windows, Mac and Max> Linux). My unscientific guess is that many (most?) of the developers are now Max> using something other than Windows, but many (most?) of the users are using Max> Windows. That puts us in the somewhat odd position that I found yesterday...as Max> far as the developers know everything is going just fine, but the code is Max> broken for the majority of end users! I think we can alleviate some of these problems by having more tests in the system. I have been adding some but there is clearly need for far more. Max, if you add the tests for BMP and HDR input, I'll add the one for PNG. And perhaps we can set the full support for these formats as the goal for the next release. Max> Perhaps one thing we could do to ameliorate the situation is to implement a Max> "you break it, you buy it" type of policy. If I am responsible for breaking Max> something, then I ought to be responsible for trying to fix it. Or, I am We could do this, but there are situations where it is not practical. For instance, you mentioned that JPEG support did not work under Windows. But it worked under my systems. But there are certainly situations in which it is practical. Max> reponsible for rolling back my changes until such time as I can figure out how Max> to fix it. Perhaps a compromise is between both is to have a very strict commit-to-the-trunk policy. Any changes made by a developer will have to be done to a branch. Merges to the trunk happen only when there is confidence (testing in all platforms) that the code works. Max> without pano12 (or pano13 or whatever it is called now), and statically link Max> with the sources from the main pano12 library. This seems to work OK, and will Max> probably go a long way towards eliminating the endless stream of questions that Max> I get from folks with mismatched executables and DLL files. -- Daniel M. German "The greatest dangers to liberty lurk in insidious encroachment by men of zeal, well-meaning Louis Brandeis -> but without understanding." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Jim W. <jwa...@ph...> - 2006-07-30 19:05:01
|
Max Lyons wrote: > are there any other Windows developers who can compile this stuff "out > of the box"? Or does everyone else have to fool around with editing/creating > their own makefiles? I've never been able to get the autoconf/configure stuff > to work. I've always had to roll my own makefiles. I now get an endless > stream of multiple definition errors when trying to compile PTMender. It seems > to be related to the tiff functions that are defined in pano12.dll, the tiff > functions that are in libtiff and trying to compile ptmender with tiff.c and > link to libtiff and pano12.dll at the same time. My plan is to build ptmender > without pano12 (or pano13 or whatever it is called now), and statically link > with the sources from the main pano12 library. This seems to work OK, and will > probably go a long way towards eliminating the endless stream of questions that > I get from folks with mismatched executables and DLL files. > > Max > I have never got autoconf/configure to work either. I work in Visual Studio and always create project files. I found creating the correct image (jpeg, tiff, ...) library files to work with PT was the hardest part. I have been finding very little time to work on the source code. I started shooting a time lapse pano project back in early April. The shooting and processing of these images have been taking way more of my time than expected. I should have made myself a precision pan head! But the last time I set up to compile everything it went smooth for pano12 but PTMender had a bunch of includes that I had to resolve. I started to make some changes then we switched to subversion and I have not had time since. -- Jim Watters Yahoo ID: j1vvy ymsgr:sendIM?j1vvy jwatters @ photocreations . ca http://photocreations.ca |
From: Daniel M. G. <dmg...@uv...> - 2006-07-30 22:19:12
|
DQoNCiBKaW0+IA0pDQogSmltPiBNYXggTHlvbnMgd3JvdGU6DQogPj4gYXJlIHRoZXJlIGFueSBv dGhlciBXaW5kb3dzIGRldmVsb3BlcnMgd2hvIGNhbiBjb21waWxlIHRoaXMgc3R1ZmYgIm91dA0K ID4+IG9mIHRoZSBib3giPyAgT3IgZG9lcyBldmVyeW9uZSBlbHNlIGhhdmUgdG8gZm9vbCBhcm91 bmQgd2l0aCBlZGl0aW5nL2NyZWF0aW5nIA0KID4+IHRoZWlyIG93biBtYWtlZmlsZXM/ICBJJ3Zl IG5ldmVyIGJlZW4gYWJsZSB0byBnZXQgdGhlIGF1dG9jb25mL2NvbmZpZ3VyZSBzdHVmZg0KID4+ IHRvIHdvcmsuICBJJ3ZlIGFsd2F5cyBoYWQgdG8gcm9sbCBteSBvd24gbWFrZWZpbGVzLiAgSSBu b3cgZ2V0IGFuIGVuZGxlc3MgDQogPj4gc3RyZWFtIG9mIG11bHRpcGxlIGRlZmluaXRpb24gZXJy b3JzIHdoZW4gdHJ5aW5nIHRvIGNvbXBpbGUgUFRNZW5kZXIuICBJdCBzZWVtcw0KID4+IHRvIGJl IHJlbGF0ZWQgdG8gdGhlIHRpZmYgZnVuY3Rpb25zIHRoYXQgYXJlIGRlZmluZWQgaW4gcGFubzEy LmRsbCwgdGhlIHRpZmYgDQogPj4gZnVuY3Rpb25zIHRoYXQgYXJlIGluIGxpYnRpZmYgYW5kIHRy eWluZyB0byBjb21waWxlIHB0bWVuZGVyIHdpdGggdGlmZi5jIGFuZCANCiA+PiBsaW5rIHRvIGxp YnRpZmYgYW5kIHBhbm8xMi5kbGwgYXQgdGhlIHNhbWUgdGltZS4gIE15IHBsYW4gaXMgdG8gYnVp bGQgcHRtZW5kZXINCiA+PiB3aXRob3V0IHBhbm8xMiAob3IgcGFubzEzIG9yIHdoYXRldmVyIGl0 IGlzIGNhbGxlZCBub3cpLCBhbmQgc3RhdGljYWxseSBsaW5rIA0KID4+IHdpdGggdGhlIHNvdXJj ZXMgZnJvbSB0aGUgbWFpbiBwYW5vMTIgbGlicmFyeS4gIFRoaXMgc2VlbXMgdG8gd29yayBPSywg YW5kIHdpbGwNCiA+PiBwcm9iYWJseSBnbyBhIGxvbmcgd2F5IHRvd2FyZHMgZWxpbWluYXRpbmcg dGhlIGVuZGxlc3Mgc3RyZWFtIG9mIHF1ZXN0aW9ucyB0aGF0DQogPj4gSSBnZXQgZnJvbSBmb2xr cyB3aXRoIG1pc21hdGNoZWQgZXhlY3V0YWJsZXMgYW5kIERMTCBmaWxlcy4NCiA+PiANCiA+PiBN YXgNCiA+PiANCiBKaW0+IEkgaGF2ZSBuZXZlciBnb3QgYXV0b2NvbmYvY29uZmlndXJlIHRvIHdv cmsgZWl0aGVyLiAgSSB3b3JrIGluIFZpc3VhbCANCiBKaW0+IFN0dWRpbyBhbmQgYWx3YXlzIGNy ZWF0ZSBwcm9qZWN0IGZpbGVzLiAgSSBmb3VuZCBjcmVhdGluZyB0aGUgY29ycmVjdCANCiBKaW0+ IGltYWdlIChqcGVnLCB0aWZmLCAuLi4pIGxpYnJhcnkgZmlsZXMgdG8gd29yayB3aXRoIFBUIHdh cyB0aGUgaGFyZGVzdCBwYXJ0Lg0KDQoNCkhhdmUgYW55IG9mIHlvdSB0cmllZCBjeWd3aW4/IA0K DQpUaGlzIHNvdW5kcyBleGFjdGx5IGFzIHRoZSBwcm9ibGVtIE9TIFggcGVvcGxlIGhhdmUgd2l0 aCBodWdpbiAob25lIGlzDQpyZXF1aXJlZCB0byB1c2UgWENvZGUgdG8gY3JlYXRlIHByb3BlciBi aW5hcmllcyBmb3IgR1VJIGFwcHMpLiBBbmQgSQ0KYWdyZWUsIGl0IHR1cm5zIGRldmVsb3BlcnMg YXdheS4NCg0KVW5mb3J0dW5hdGVseSBJIGRvbid0IHRoaW5rIHRoZXJlIGlzIGEgcG9ydGFibGUg c29sdXRpb24gZm9yIHlvdXINCnByb2JsZW0gaGVyZS4gUHJvamVjdCBmaWxlcyBzZWVtIHRvIGVt YmVkIGEgbG90IG9mIGhhcmQgY29kZWQNCmRpcmVjdG9yeSByZWZlcmVuY2VzIG1ha2UgdGhlbSBu b24tcG9ydGFibGUuIHRoYXQgaXMgdGhlIGJlYXV0eSBvZg0KYXV0b21ha2UvYXV0b2NvbmYuDQoN Cg0KUGVyaGFwcyBvbmUgd2F5IHRvIGZpeCB0aGlzIHByb2JsZW0gaXMgdG8gYWRkIHRoZSBwcm9q ZWN0IGZpbGUgdG8gdGhlDQpyZXBvc2l0b3J5IGFuZCB0byBtYWtlIGV4cGxpY2l0IGluc3RydWN0 aW9ucyBvbiBob3cgdG8gdXNlIGl0IHVuZGVyDQp3aW5kb3dzLg0KDQoNCi0tDQpEYW5pZWwgTS4g R2VybWFuICAgICAgICAgICAgICAgICAgIllvdSBjb3VsZCB3aW5kIHVwIGJlbGl2aW4nIA0KICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB0aGF0IHBhcmFkaXNlIGlzIG5vdGhpbicN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIG1vcmUgdGhhbiBhIGZlZWxpbicN CiAgIE1hcmlsbGlvbiAtPiAgICAgICAgICAgICAgICAgICAgdGhhdCBnb2VzIG9uIGluIHlvdXIg bWluZC4iDQpodHRwOi8vdHVyaW5nbWFjaGluZS5vcmcvDQpodHRwOi8vc2lsdmVybmVnYXRpdmUu Y29tLw0KZG1nIChhdCkgdXZpYyAoZG90KSBjYQ0KcmVwbGFjZSAoYXQpIHdpdGggQCBhbmQgKGRv dCkgd2l0aCAuDQoNCiA= |
From: Pablo d'A. <pab...@we...> - 2006-07-31 18:36:18
|
Daniel M. German wrote: > Jim> > ) > Jim> Max Lyons wrote: > >> are there any other Windows developers who can compile this stuff "out > >> of the box"? Or does everyone else have to fool around with editing/creating > >> their own makefiles? > >> Max > >> > Jim> I have never got autoconf/configure to work either. I work in Visual > Jim> Studio and always create project files. I found creating the correct > Jim> image (jpeg, tiff, ...) library files to work with PT was the hardest part. > I have updated the Visual Studio C++ files, since I used M$ Visual Studio to build hugin 0.6 . Ups, I just noticed that I commited the changes only to the old, binary compatible branch. Will add it to the main development when I'm back. I use the image libraries from wxWidgets (just as Jim did). > Have any of you tried cygwin? > Its probably possible to build it using cygwin, but I'm not sure how well the resulting dll would work for normal, non cygwin applications. > This sounds exactly as the problem OS X people have with hugin (one is > required to use XCode to create proper binaries for GUI apps). And I > agree, it turns developers away. > Actually it should be possible to do all the build from a makefile. I just need access to OSX box for a few hours. Then it would be possible to add hugin to darwinports, so everybody could compile it without having all the problems. Too bad that OSX is dongled to the apple hardware. ciao Pablo |
From: Carl v. E. <ei...@gm...> - 2006-07-31 20:31:07
|
Pablo, I will have my PowerBook (still a G4) with me in Bath. OSX 10.3.9. and Ubuntu are installed. Carl Pablo d'Angelo wrote: > > Actually it should be possible to do all the build from a makefile. I > just need access to OSX box for a few hours. Then it would be possible > to add hugin to darwinports, so everybody could compile it without > having all the problems. Too bad that OSX is dongled to the apple hardware. |
From: Max L. <max...@ve...> - 2006-07-30 19:34:36
|
> I have never got autoconf/configure to work either. I work in Visual > Studio and always create project files. I found creating the correct > image (jpeg, tiff, ...) library files to work with PT was the hardest part. That's good to hear I'm not the only one. I've spent hours wresting with autosys, autoconf, configure and bunch of other stuff on several occasions without any real success. My guess is that getting this to work in a Windows environment isn't quite as easy as in the Unix world. (The same is true for the new test stuff. The readme for the tests says "To run the tests type: make". That doesn't work for me either, but I was able to run the Perl script after a little reading through it.) I write my own makefiles from scratch. I also have versions of the all the libraries compiled for my other projects (some of which I've modified as well), and link against those. > But the last time I set up to compile everything it went smooth for > pano12 but PTMender had a bunch of includes that I had to resolve. I agree. Getting PTMender to compile was tricky...lots of duplicate definition errors. With the latest version, I've given up trying to get PTMender to compile while dynamically linked to the library. I guess that if we can't get it to work, there isn't much chance of attracting new Windows developers. I would wager that most folks who download the code with the idea of having a look spend a few hours getting frustrated and move on. In fact, at the moment, I don't think anyone can find the code. The instructions are still for the old CVS repository on the Panotools Sourceforge page (http://panotools.sourceforge.net/). It also makes me wonder about the helpfulness of the standard advice of "build your own" given to those who grumble about the 160 degree limit. I guess it would be possible to put this value into an optional "properties file" that could be modified by the user, and read by the code at run-time. On a slight tangent...I've also wondered about how close to 180 degrees does one have to be before getting into hot legal water? What if the limit was coded to be 179.9999999 degrees? Is this technically legal? Is it close enough to allow folks to do what they need with negligable errors? Max |
From: Daniel M. G. <dmg...@uv...> - 2006-07-30 22:27:50
|
>> I have never got autoconf/configure to work either. I work in Visual >> Studio and always create project files. I found creating the correct >> image (jpeg, tiff, ...) library files to work with PT was the hardest part. Max> That's good to hear I'm not the only one. I've spent hours wresting with Max> autosys, autoconf, configure and bunch of other stuff on several occasions Max> without any real success. My guess is that getting this to work in a Windows Max> environment isn't quite as easy as in the Unix world. (The same is true for Max> the new test stuff. The readme for the tests says "To run the tests type: Max> make". That doesn't work for me either, but I was able to run the Perl script Max> after a little reading through it.) Max> I write my own makefiles from scratch. I also have versions of the all the Max> libraries compiled for my other projects (some of which I've modified as well), Max> and link against those. >> But the last time I set up to compile everything it went smooth for >> pano12 but PTMender had a bunch of includes that I had to resolve. Max> I agree. Getting PTMender to compile was tricky...lots of duplicate definition Max> errors. With the latest version, I've given up trying to get PTMender to Max> compile while dynamically linked to the library. I think one problem you might be facing is that your linker is more sensitive to errors than the ones we use, and you get to see the warnings. I'll see if I can enable better warnings on my side. Perhaps the move to start renaming functions and to remove dead code will improve this. Max> I guess that if we can't get it to work, there isn't much chance of attracting Max> new Windows developers. I would wager that most folks who download the code Max> with the idea of having a look spend a few hours getting frustrated and move Max> on. In fact, at the moment, I don't think anyone can find the code. The Max> instructions are still for the old CVS repository on the Panotools Sourceforge Max> page (http://panotools.sourceforge.net/). Why don't one of you (the Windows developers) creates a document describing the process to compile libpano with Visual Studio (assuming that is the most commonly used compiler under Windows). If you are willing to do that I will commit to do the same for cygwin. Max> It also makes me wonder about the helpfulness of the standard advice of "build Max> your own" given to those who grumble about the 160 degree limit. I guess it Max> would be possible to put this value into an optional "properties file" that Max> could be modified by the user, and read by the code at run-time. No, I don't want to get into that. Let us leave the 160 degrees limit alone. I don't think either one of us wants to get involved into legal problems. Max> On a slight tangent...I've also wondered about how close to 180 degrees does Max> one have to be before getting into hot legal water? What if the limit was Max> coded to be 179.9999999 degrees? Is this technically legal? Is it close Max> enough to allow folks to do what they need with negligable errors? -- Daniel M. German "In questions of science the authority of a thousand is not worth the humble Galileo -> reasoning of a single individual." http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
From: Bruno P. <br...@po...> - 2006-08-03 18:28:16
|
On Sun 30-Jul-2006 at 15:34 -0400, Max Lyons wrote: >> I have never got autoconf/configure to work either. I work in Visual >> Studio and always create project files. I found creating the correct >> image (jpeg, tiff, ...) library files to work with PT was the hardest part. The problem I found is that the ./bootstrap script doesn't run under msys. Once the configure script exists (after running bootstrap), building is straightforward. My solution was to run bootstrap under cygwin, then everything else with msys/mingw. > In fact, at the moment, I don't think anyone can find the code. The > instructions are still for the old CVS repository on the Panotools Sourceforge > page (http://panotools.sourceforge.net/). Sorry, haven't found the time to fix this. Greetings from Bath, just leaving for drinks and dinner. -- Bruno |
From: Max L. <max...@ve...> - 2006-07-29 21:56:51
|
I think I found the problem. It looks like the functions in ppm.c (readImage, writeImage, etc.) have all been updated to deal with the new metadata stuff, but not the functions in bmp.c (which is what us Windows folks use). I think the solution is to figure out if we really need two versions of these functions, and if not then combine them into one file. I guess it also outlines the importance of testing on different operating systems. (Speaking of which, I also had to #define the new "bzero" calls to "memset"...this function isn't present on my system). Max |