Menu
▾
▴
panotools-devel — Panorama Tools software developers
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(2) |
Feb
(3) |
Mar
|
Apr
|
May
(4) |
Jun
(8) |
Jul
|
Aug
(2) |
Sep
|
Oct
(2) |
Nov
(9) |
Dec
|
| 2005 |
Jan
(13) |
Feb
(3) |
Mar
(5) |
Apr
(12) |
May
(22) |
Jun
|
Jul
(10) |
Aug
(7) |
Sep
(3) |
Oct
(7) |
Nov
(10) |
Dec
(13) |
| 2006 |
Jan
(22) |
Feb
(20) |
Mar
(5) |
Apr
(50) |
May
(103) |
Jun
(98) |
Jul
(63) |
Aug
(35) |
Sep
(32) |
Oct
(149) |
Nov
(77) |
Dec
(113) |
| 2007 |
Jan
(145) |
Feb
(97) |
Mar
(109) |
Apr
(5) |
May
|
Jun
(3) |
Jul
(2) |
Aug
(19) |
Sep
|
Oct
(1) |
Nov
(3) |
Dec
|
| 2008 |
Jan
(5) |
Feb
(10) |
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
(16) |
Sep
(2) |
Oct
|
Nov
|
Dec
(3) |
| 2009 |
Jan
(2) |
Feb
(2) |
Mar
(6) |
Apr
(5) |
May
(19) |
Jun
|
Jul
(5) |
Aug
(27) |
Sep
(188) |
Oct
(31) |
Nov
(23) |
Dec
(17) |
| 2010 |
Jan
(48) |
Feb
(14) |
Mar
(11) |
Apr
(3) |
May
(12) |
Jun
(2) |
Jul
(3) |
Aug
|
Sep
(10) |
Oct
(6) |
Nov
|
Dec
|
| 2011 |
Jan
(51) |
Feb
(77) |
Mar
(39) |
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2012 |
Jan
(1) |
Feb
(3) |
Mar
(1) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(7) |
Dec
|
| 2013 |
Jan
(3) |
Feb
|
Mar
|
Apr
(4) |
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
(2) |
Dec
(11) |
| 2014 |
Jan
(14) |
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2016 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2017 |
Jan
|
Feb
|
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
| 2023 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bruno P. <br...@po...> - 2011-03-06 00:08:26
|
I haven't been keeping track of these things, am I right that the IPIX US patent(s) finally expire soon or already expired? -- Bruno On Sat 05-Mar-2011 at 23:58 +0000, Bruno Postle wrote: >A libpano13-2.9.18_rc1 (first release candidate) tarball has been >uploaded to sourceforge: |
|
From: Bruno P. <br...@po...> - 2011-03-05 23:58:39
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 A libpano13-2.9.18_rc1 (first release candidate) tarball has been uploaded to sourceforge: https://sourceforge.net/projects/panotools/files/libpano13/ There have been some changes since 2.9.17: * Added Thoby projection which models the Nikkor 10.5 lens. * Minor fixes for GNU Hurd, libtool 2.4, libpng-1.5 and powerpc command-line. SHA1SUM: 373f75d881cb2a9a1b6b8a4a2c47638a4f95e32f libpano13-2.9.18_rc1.tar.gz This release is equivalent to HG 746:8d3a1ad9d2fa Here is the ChangeLog since 2.9.18_beta1 for more details: 2011-03-05 23:04 +0000 Bruno Postle <br...@po...> (1dbe4f806f26 [tip] <libpano13-2.9.18>) * ChangeLog.hg: new file. * ChangeLog.svn: deleted file. * ChangeLog.hg, ChangeLog.svn, Makefile.am: Switch ChangeLog generator from svn to hg 2011-03-05 22:34 +0000 Bruno Postle <br...@po...> (3209bc93c5ae <libpano13-2.9.18>) * png.c: Fix build with libpng-1.5 Bug #719076 (Thomas Klausner) 2011-03-04 01:09 -0800 dmg <dm...@uv...> (2ed25471680c <libpano13-2.9.18>) * created a new branch 2011-03-02 19:45 -0800 dmg <dm...@uv...> (a70ba2fe3c7f) * Renamed libpano to default 2011-02-20 13:25 -0800 dmg <dm...@uv...> (774168101e71 <libpano>) * ChangeLog, sys_ansi.c, tools/panoinfo_unix.c: removed compiler warnings. Patch submited by Guillaume Rousse. 2011-02-14 20:01 -0400 Jim Watters <jwa...@ph...> (364327cfaf40 <libpano>) * .hgignore: new file. * .hgignore: Add a list of files to ignor when doing commit 2011-02-14 20:00 -0400 Jim Watters <jwa...@ph...> (9fa455003f7d <libpano>) * .hgeol: new file. * .hgeol: Windows users should use the EOL extension Windows users need EOL to control how End of Line characters are translated to and from repository. - -- Bruno -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.6 (GNU/Linux) iD8DBQFNcs4lFqOhwCjyCLoRAq1SAJ935Zo7V/m7hgzzSQakPfkEzjfX4QCdGxvx WnWqjSXe/zc1xmXkH9pofBU= =xjfe -----END PGP SIGNATURE----- |
|
From: Yuval L. <sf...@sf...> - 2011-03-05 03:31:07
|
On March 3, 2011 06:30:01 pm Bruno Postle wrote: > Yes, I think it is worth doing another beta/rc for the libpng-1.5 > patch. Looking at the commits, I'd want to branch at > 722:a70ba2fe3c7f, not quite sure how to do this at the moment. hg up -C -r 722 hg branch <BRANCH_NAME> hg push -f it seems that Daniel did this. some applicable info is at http://wiki.panotools.org/Development_of_Open_Source_tools#Branching_Out_For_Release Yuv |
|
From: Rich <ri...@na...> - 2011-03-04 08:24:15
|
On 03/04/11 09:38, dmg wrote: > Rich, > > I think we have fixed your compilation problem. You should try again. huge thanks - and i see that the bugtracker links has been fixed as well, so thanks again ;) > On Tue, Mar 1, 2011 at 11:38 PM, Rich<ri...@na...> wrote: >> hi - if this email gets through :) >> >> first, i wanted to report libpano13 compilation being broken, at least >> on linux. it's been like that for several "revisions" in the mercurial >> repository. some quick searches seem to suggest that it's >> windows-specific stuff that breaks compilation on linux... >> >> second, it is increasingly difficult to communicate with projects of the >> panotools group. the yahoo hosted users mailing list - i could not >> subscribe to it. yeah, i probably should complain to yahoo... but that's >> a bit too much to bother. >> >> page at http://panotools.sourceforge.net/ proudly has "Bugs" link at the >> top - which only returns error 500. sourceforge says that's because the >> bug tracker, linked from there, has been disabled - so i was unable to >> report the bug at all. >> >> i like hugin&friends alot, but from an outside perspective, something's >> not really perfect with some aspects of communication ;) >> -- >> Rich -- Rich |
|
From: dmg <dm...@uv...> - 2011-03-04 07:38:59
|
Rich, I think we have fixed your compilation problem. You should try again. On Tue, Mar 1, 2011 at 11:38 PM, Rich <ri...@na...> wrote: > hi - if this email gets through :) > > first, i wanted to report libpano13 compilation being broken, at least > on linux. it's been like that for several "revisions" in the mercurial > repository. some quick searches seem to suggest that it's > windows-specific stuff that breaks compilation on linux... > > second, it is increasingly difficult to communicate with projects of the > panotools group. the yahoo hosted users mailing list - i could not > subscribe to it. yeah, i probably should complain to yahoo... but that's > a bit too much to bother. > > page at http://panotools.sourceforge.net/ proudly has "Bugs" link at the > top - which only returns error 500. sourceforge says that's because the > bug tracker, linked from there, has been disabled - so i was unable to > report the bug at all. > > i like hugin&friends alot, but from an outside perspective, something's > not really perfect with some aspects of communication ;) > -- > Rich > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT data > generated by your applications, servers and devices whether physical, virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > > -- --dmg --- Daniel M. German http://turingmachine.org |
|
From: Carl v. E. <ei...@gm...> - 2011-03-04 07:36:36
|
Hi Rich, Rich schrieb am 02.03.11 08:38: > [...] > second, it is increasingly difficult to communicate with projects of the > panotools group. the yahoo hosted users mailing list - i could not > subscribe to it. yeah, i probably should complain to yahoo... but that's > a bit too much to bother. I don't see traces of your mail address in the logs of the PanoToolsNG yahoo group (which is independent of this mailing list btw). So no idea what's been causing trouble for you. I'll send you an invitation to join so please look for a message from "PanoToolsNG moderator" with the subject "Invitation to join the PanoToolsNG group". > [...] > i like hugin&friends alot, but from an outside perspective, something's > not really perfect with some aspects of communication ;) What's perfect after all? If I was in a software paradise I'd probably take my Apple and leave... ;-) Carl |
|
From: D M G. <dm...@uv...> - 2011-03-04 05:44:32
|
Hi Jim, There are several tests now under hg. I temporarily disabled inserting the current time into the PSD, so we can simply do a diff of the files (until we have a tool to compare the PSD files). By the way, malloc no longer requires typecasting when assigning it to a pointer (it is defined as void* which is assignable to any pointer). --dmg -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
|
From: dmg <dm...@uv...> - 2011-03-04 00:35:27
|
Done. I have created a file called sys_compat.h where prototypes of functions that have very different implementations will be located. Their implementations will go to sys_win and sys_ansi. This way we avoid cluttered #ifdefs in the source code. Jim, I placed new code in sys_win.c. Please check it, as I cannot compile it. --dmg On Thu, Mar 3, 2011 at 3:21 PM, D M German <dm...@uv...> wrote: > > Hi Jim, > > Under glibc, the "%z" (lowecase z) does not include timezone > abbreviation (the %Z does). > > I am going to ifdef the difference with windows, if you don't mind. The > current code does not compile in linux. > > %z The +hhmm or -hhmm numeric timezone (that is, the hour and minute offset from UTC). (SU) > > > -- > -- > Daniel M. German > http://turingmachine.org/ > http://silvernegative.com/ > dmg (at) uvic (dot) ca > replace (at) with @ and (dot) with . > > -- --dmg --- Daniel M. German http://turingmachine.org |
|
From: dmg <dm...@uv...> - 2011-03-04 00:25:37
|
Merging the test suite is also in my list of todos. Currently I am trying to help Jim with the upgrades to PTtiff2psd. What do you suggest we do? Do you want me to branch it? -dmg On Thu, Mar 3, 2011 at 3:30 PM, Bruno Postle <br...@po...> wrote: > On Thu 03-Mar-2011 at 12:10 -0800, Daniel M. German wrote: >>Bruno, do you want to branch libpano for this release just before my >>commits to default from yesterday? > > Yes, I think it is worth doing another beta/rc for the libpng-1.5 > patch. Looking at the commits, I'd want to branch at > 722:a70ba2fe3c7f, not quite sure how to do this at the moment. > > I originally wanted to merge the summer of code test suite, but I > can't get this to run at all so this will have to wait. > >>On Thu, Mar 3, 2011 at 11:11 AM, Bart van Andel <bav...@gm...> wrote: >>> I've seen reports on libpng issues with libpng version > 1.5. A patch has >>> already been submitted by Thomas Klausner [0]. Is this critical enough to >>> include in this release cycle? >>> [0] https://bugs.launchpad.net/panotools/+bug/719076 > > -- > Bruno > > ------------------------------------------------------------------------------ > What You Don't Know About Data Connectivity CAN Hurt You > This paper provides an overview of data connectivity, details > its effect on application quality, and explores various alternative > solutions. http://p.sf.net/sfu/progress-d2d > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > > -- --dmg --- Daniel M. German http://turingmachine.org |
|
From: Bruno P. <br...@po...> - 2011-03-03 23:30:11
|
On Thu 03-Mar-2011 at 12:10 -0800, Daniel M. German wrote: >Bruno, do you want to branch libpano for this release just before my >commits to default from yesterday? Yes, I think it is worth doing another beta/rc for the libpng-1.5 patch. Looking at the commits, I'd want to branch at 722:a70ba2fe3c7f, not quite sure how to do this at the moment. I originally wanted to merge the summer of code test suite, but I can't get this to run at all so this will have to wait. >On Thu, Mar 3, 2011 at 11:11 AM, Bart van Andel <bav...@gm...> wrote: >> I've seen reports on libpng issues with libpng version > 1.5. A patch has >> already been submitted by Thomas Klausner [0]. Is this critical enough to >> include in this release cycle? >> [0] https://bugs.launchpad.net/panotools/+bug/719076 -- Bruno |
|
From: D M G. <dm...@uv...> - 2011-03-03 23:21:30
|
Hi Jim,
Under glibc, the "%z" (lowecase z) does not include timezone
abbreviation (the %Z does).
I am going to ifdef the difference with windows, if you don't mind. The
current code does not compile in linux.
%z The +hhmm or -hhmm numeric timezone (that is, the hour and minute offset from UTC). (SU)
--
--
Daniel M. German
http://turingmachine.org/
http://silvernegative.com/
dmg (at) uvic (dot) ca
replace (at) with @ and (dot) with .
|
|
From: D M G. <dm...@uv...> - 2011-03-03 20:48:10
|
dmg twisted the bytes to say: dmg> fseeko and ftell are C99 standard. Is there something similar in dmg> Windows? What si the default data type for off_t? Sorry, I meant ftello. In my experience, fseek and ftell switch to 64 by just using the define. But it does not hurt to replace them with fseeko/ftello to make it explicit that we have 64bit aware code. -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
|
From: dmg <dm...@uv...> - 2011-03-03 20:44:55
|
#define _LARGEFILE64_SOURCE. Then all off_t operations are 64 bit aware.
Then use fseeko and ftello, that force parameters and return values to
be off_t data types instead of longs.
fseeko and ftell are C99 standard. Is there something similar in
Windows? What si the default data type for off_t?
#ifdef __windows__
#else
#define _LARGEFILE64_SOURCE
#include <sys/types.h>
#include <unistd.h>
#endif
It is recommended to add the define _LARGEFILE64_SOURCE to the build process.
--dmg
On Thu, Mar 3, 2011 at 12:10 PM, Jim Watters <jwa...@ph...> wrote:
> On 2011-03-03 4:25 AM, D M German wrote:
>> Jim,
>>
>> to save you the trouble of merging my changes to default, I have merged
>> them into your branch.
> Thank you.
>
>> Also, there is some windows-centric code that I ported to Linux. You
>> will see an ifdef for it (way to extract local time). can you please
>> first check if the linux code works under windows too (it is standard
>> code, so it _should_ work). If it does, remove the ifdef and the windows
>> code, if not leave it as it with the proper ifdef condition.
> There was a problem with the timezone. We need numeric string ±HHMM, and it was
> producing a a long string of the time zone instead. I updated it to use a
> separate functin to get the time zone info needed.
>
> Currently we are using fseek and ftell to get and set the file pointer position. These functions use long on windows there is _fseeki64 and _ftelli64 that use 64bit values on Windows. What is available on Linux?
>
>
>
> --
> Jim Watters
> http://photocreations.ca
>
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT data
> generated by your applications, servers and devices whether physical, virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> PanoTools-devel mailing list
> Pan...@li...
> https://lists.sourceforge.net/lists/listinfo/panotools-devel
>
>
--
--dmg
---
Daniel M. German
http://turingmachine.org
|
|
From: dmg <dm...@uv...> - 2011-03-03 20:13:33
|
Bruno, do you want to branch libpano for this release just before my commits to default from yesterday? On Thu, Mar 3, 2011 at 11:11 AM, Bart van Andel <bav...@gm...> wrote: > I've seen reports on libpng issues with libpng version > 1.5. A patch has > already been submitted by Thomas Klausner [0]. Is this critical enough to > include in this release cycle? > [0] https://bugs.launchpad.net/panotools/+bug/719076 > -- > Bart > > -- > 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 hug...@go... > To unsubscribe from this group, send email to > hug...@go... > For more options, visit this group at > http://groups.google.com/group/hugin-ptx > -- --dmg --- Daniel M. German http://turingmachine.org |
|
From: Jim W. <jwa...@ph...> - 2011-03-03 20:11:59
|
On 2011-03-03 4:25 AM, D M German wrote: > Jim, > > to save you the trouble of merging my changes to default, I have merged > them into your branch. Thank you. > Also, there is some windows-centric code that I ported to Linux. You > will see an ifdef for it (way to extract local time). can you please > first check if the linux code works under windows too (it is standard > code, so it _should_ work). If it does, remove the ifdef and the windows > code, if not leave it as it with the proper ifdef condition. There was a problem with the timezone. We need numeric string ±HHMM, and it was producing a a long string of the time zone instead. I updated it to use a separate functin to get the time zone info needed. Currently we are using fseek and ftell to get and set the file pointer position. These functions use long on windows there is _fseeki64 and _ftelli64 that use 64bit values on Windows. What is available on Linux? -- Jim Watters http://photocreations.ca |
|
From: D M G. <dm...@uv...> - 2011-03-03 09:37:10
|
Hi Jim, One of the problems of adding test cases for the PSD code is that we don't have tools to compare PSD files. We can either build one, or remove any field that changes over time (for example date/time when the file is created). the easiest would be to start by making sure we can compare the files byte-by-byte, and then write a tool to compare them as PSDs. What do you think? -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
|
From: dmg <dm...@uv...> - 2011-03-03 09:21:41
|
Ok, I see what you mean (I am no expert in cmake). I'll put it back. --dmg 2011/3/3 Kornel Benko <Kor...@be...>: > Am Donnerstag, 3. März 2011 schrieb dmg: > >> Hi Kornel, > >> > >> can you be more explicit on what it does > > For the calls like > > FIND_PACKAGE(TIFF REQUIRED) > > it provides an extra search path to find the appropriate "FindTIFF.cmake". > It has no effect, if no such path exists. > > Sometimes one has to provide a module which is missing on some platforms, or > has to be changed to > > better suit one's needs. > >> and why it needs to be in > >> libpano rather than hugin? > > There is no preference in this direction from my side. I even would accept a > completelly new project for this. > > Hugin was the first one using own modules, that was the only reason. > >> -dmg > >> > > Kornel > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT > data > generated by your applications, servers and devices whether physical, > virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > > -- --dmg --- Daniel M. German http://turingmachine.org |
|
From: Kornel B. <Kor...@be...> - 2011-03-03 09:08:51
|
Am Donnerstag, 3. März 2011 schrieb dmg: > Hi Kornel, > > can you be more explicit on what it does For the calls like FIND_PACKAGE(TIFF REQUIRED) it provides an extra search path to find the appropriate "FindTIFF.cmake". It has no effect, if no such path exists. Sometimes one has to provide a module which is missing on some platforms, or has to be changed to better suit one's needs. > and why it needs to be in > libpano rather than hugin? There is no preference in this direction from my side. I even would accept a completelly new project for this. Hugin was the first one using own modules, that was the only reason. > -dmg > Kornel |
|
From: dmg <dm...@uv...> - 2011-03-03 08:49:27
|
Hi Kornel,
can you be more explicit on what it does and why it needs to be in
libpano rather than hugin?
-dmg
2011/3/3 Kornel Benko <Kor...@be...>:
> Am Donnerstag, 3. März 2011 schrieb dm...@uv...
>
>> -## Locate the hugin source root and its parent directory
>
>> -IF(HUGIN_BASE_DIR)
>
>> - GET_FILENAME_COMPONENT(SOURCE_BASE_DIR ${HUGIN_BASE_DIR} PATH CACHE)
>
>> - set(CMAKE_MODULE_PATH ${HUGIN_BASE_DIR}/CMakeModules)
>
>> -ELSE(HUGIN_BASE_DIR)
>
>> - GET_FILENAME_COMPONENT(SOURCE_BASE_DIR ${CMAKE_SOURCE_DIR} PATH CACHE)
>
>> - set(CMAKE_MODULE_PATH ${SOURCE_BASE_DIR}/hugin/CMakeModules)
>
>> -ENDIF(HUGIN_BASE_DIR)
>
> We had some fights in the past, as how to reuse modules between our projects
> (enblend hugin, libpano).
>
> So removing this makes me uneasy.
>
> Kornel
>
> ------------------------------------------------------------------------------
> Free Software Download: Index, Search & Analyze Logs and other IT data in
> Real-Time with Splunk. Collect, index and harness all the fast moving IT
> data
> generated by your applications, servers and devices whether physical,
> virtual
> or in the cloud. Deliver compliance at lower cost and gain new business
> insights. http://p.sf.net/sfu/splunk-dev2dev
> _______________________________________________
> PanoTools-devel mailing list
> Pan...@li...
> https://lists.sourceforge.net/lists/listinfo/panotools-devel
>
>
--
--dmg
---
Daniel M. German
http://turingmachine.org
|
|
From: Kornel B. <Kor...@be...> - 2011-03-03 08:46:07
|
Am Donnerstag, 3. März 2011 schrieb dm...@uv...
> -## Locate the hugin source root and its parent directory
> -IF(HUGIN_BASE_DIR)
> - GET_FILENAME_COMPONENT(SOURCE_BASE_DIR ${HUGIN_BASE_DIR} PATH CACHE)
> - set(CMAKE_MODULE_PATH ${HUGIN_BASE_DIR}/CMakeModules)
> -ELSE(HUGIN_BASE_DIR)
> - GET_FILENAME_COMPONENT(SOURCE_BASE_DIR ${CMAKE_SOURCE_DIR} PATH CACHE)
> - set(CMAKE_MODULE_PATH ${SOURCE_BASE_DIR}/hugin/CMakeModules)
> -ENDIF(HUGIN_BASE_DIR)
We had some fights in the past, as how to reuse modules between our projects (enblend hugin, libpano).
So removing this makes me uneasy.
Kornel
|
|
From: D M G. <dm...@uv...> - 2011-03-03 08:25:46
|
Jim, to save you the trouble of merging my changes to default, I have merged them into your branch. perhaps the most important change is that we no longer have USHORT, or pt_uint16, rather, we only use uint16_t, which is the standard way to do it. I have tested my changes and they seem to work. Also, there is some windows-centric code that I ported to Linux. You will see an ifdef for it (way to extract local time). can you please first check if the linux code works under windows too (it is standard code, so it _should_ work). If it does, remove the ifdef and the windows code, if not leave it as it with the proper ifdef condition. --dmg -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
|
From: D M G. <dm...@uv...> - 2011-03-03 06:55:18
|
Please, windows people, test to see if you can build and run the tests in libpano. I have fixed the compilation warnings and simplified the windows #ifdefs. If some data types are not available under windows, then please add them to panotypes.h (or pt_stdint.h--I guess it would make more sense to merge them). I have also fixed a problem with the cmake file in the tests directory that created some problems (such as disappearing files in the test directories under linux). Jim, you might have to merge to your branch, because I made a lot of changes in many different files. -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
|
From: D M G. <dm...@uv...> - 2011-03-03 03:49:36
|
I have been reading how to have a default branch in hg, and it appears as if I made a mistake when I converted the repository. I "think" I found the solution: rename the libpano branch to default. The older "libpano" branch is now marked as inactive. default 721:a70ba2fe3c7f PhotoshopPSB 720:daf735d8ec66 optimizeroptions 684:3af83f39190f libpano 708:774168101e71 (inactive) Hopefully this fixes that problem. -- -- Daniel M. German http://turingmachine.org/ http://silvernegative.com/ dmg (at) uvic (dot) ca replace (at) with @ and (dot) with . |
|
From: Thomas S. <tks...@gm...> - 2011-03-03 01:39:33
|
Hi Dan On Wed, Mar 2, 2011 at 5:46 PM, D M German <dm...@uv...> wrote: > > Hi everybody, > > I was looking at the CMakeList.txt and it seems to depend on hugin. Do > we really need that dependency? Ideally libpano should be completely > independent of hugin, otherwise cmake will generate errors if hugin is > not available. > > I originally wrote that CMake script as an easy way to build libpano13 in the Windows Hugin build environment. It was not designed as a universal build script (though I think it worked on Ubuntu also). As far as I can recall there is no real dependence on Hugin, it just uses WxWidgets as a possible source for the image file format libraries, and assumes a Hugin SDK-like directory configuration when searching for them on Windows. But I no longer remember everything. I would definitely favor having a universal CMake script as the primary build spec. But I see no reason to rule out the Hugin SDK, as long as other "standard" installations of the file format libraries are also supported. Cheers, Tom --dmg > > > -- > -- > Daniel M. German > http://turingmachine.org/ > http://silvernegative.com/ > dmg (at) uvic (dot) ca > replace (at) with @ and (dot) with . > > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT > data > generated by your applications, servers and devices whether physical, > virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > |
|
From: dmg <dm...@uv...> - 2011-03-02 22:53:49
|
I agree, the way that mercurial does not default to a HEAD branch is probably one of the problems. Having said that, I have been trying to fix Jim changes to make sure they compile under LInux. I suspect that the problem with libpano is its dependnecy on hugin build system, but that is just a hypothesis. Without a proper report we can't know for sure (we need the output of make). On Wed, Mar 2, 2011 at 2:48 PM, Jim Watters <jwa...@ph...> wrote: > On 2011-03-02 3:38 AM, Rich wrote: >> first, i wanted to report libpano13 compilation being broken, at least >> on linux. it's been like that for several "revisions" in the mercurial >> repository. some quick searches seem to suggest that it's >> windows-specific stuff that breaks compilation on linux... > That might be so for the PhotoshopPSB branch which I have been adding to from > Windows environment. > If you have specific errors I can try to solve them, but patches would be more > welcome. I have an idea of some of them from an earlier message. I'll try and > tackle some of them shortly. But it will take a Linux person to verify. > > But you probably are better off working on the libpano branch (but would still > like an error report). Do the following. > > hg branch > > and if you are not in libpano then: > > hg update -C libpano > > and try again > > >> i like hugin&friends alot, but from an outside perspective, something's >> not really perfect with some aspects of communication ;) > > > -- > Jim Watters > http://photocreations.ca > > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT data > generated by your applications, servers and devices whether physical, virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > _______________________________________________ > PanoTools-devel mailing list > Pan...@li... > https://lists.sourceforge.net/lists/listinfo/panotools-devel > > -- --dmg --- Daniel M. German http://turingmachine.org |
9 messages has been excluded from this view by a project administrator.