[hugin-ptx] Re: Celeste not compilable

Am Monday 03 August 2009 schrieb Yuval Levy: > > Markku Kolkka wrote: > > Like Bruno already explained, the above is the reason why you > > should never publish packages that install anything > > _in_ /usr/local. Use /opt if you are really opposed to > > installing in /usr. > > I think I start

[hugin-ptx] Re: Celeste not compilable

Am Monday 03 August 2009 schrieb Yuval Levy: > > Danke Kornel! > > Kornel Benko wrote: > > Here is, how I use it. > > it all worked and I updated the documentation > > > So now I have to look into the chrooting as suggested by Roger and then >

[hugin-ptx] Re: The way to 2009.2

Hey Yuv On Aug 2, 10:09 am, Yuval Levy wrote: > the current policy for the windows binary is to avoid DLHell and link > statically. > That is a good policy with respect to many of the open source libraries included in the Hugin code base, that tend to be in a constant state of flux. Building

[hugin-ptx] Re: Lens information from Exif

Hey Nick, If you just want to know what your camera is saying about istelf, there are plenty of very capable exif info display programs. I used to use one called Opanda. What I use now is the exif display add-on for FireFox, that you can install from that browser's tools menu. I would be very

[hugin-ptx] Re: Lens information from Exif

On Sun, Aug 2, 2009 at 8:16 PM, Nicolas Pelletier < nicolas.pellet...@gmail.com> wrote: > >> Nicolas Pelletier wrote: >> > Upgrade exiftool not working. >> > Had 774, changed for 782. >> >> do I understand right that exiftool 774 could read info out of a Canon >> 50D and exiftool 782 could not? >

[hugin-ptx] Re: Lens information from Exif

> > > Nicolas Pelletier wrote: > > Upgrade exiftool not working. > > Had 774, changed for 782. > > do I understand right that exiftool 774 could read info out of a Canon > 50D and exiftool 782 could not? Sorry, was not clear; skipped part of the ino. I meant, hugin was installed with v774. Any im

[hugin-ptx] Re: Lens information from Exif

Nicolas Pelletier wrote: > Upgrade exiftool not working. > Had 774, changed for 782. do I understand right that exiftool 774 could read info out of a Canon 50D and exiftool 782 could not? > I'll check the other tool you mentioned. you can't really check exiv2 - it's a library not a tool. To

[hugin-ptx] Re: Speed reference...

Sorry, was not clear enough on last point What the system did: Take the 36 images (12 per exposure). Enblend the first exposure Enblend the second exposure Enblend the third exposure Enfuse the first 3 images Enfuse the next 3 images ... [12 times total] Enfuse the last 3 images Enblend the 12 enf

[hugin-ptx] Re: Lens information from Exif

Upgrade exiftool not working. Had 774, changed for 782. I'll check the other tool you mentioned. nick On Sun, Aug 2, 2009 at 6:42 PM, Nicolas Pelletier < nicolas.pellet...@gmail.com> wrote: > I'll try the upgrade. > It is a Canon 50D. Came out last October, so fairly new. > > I can run exiftool

[hugin-ptx] Re: Lens information from Exif

I'll try the upgrade. It is a Canon 50D. Came out last October, so fairly new. I can run exiftool, but what do you want me to export? (tried the tool to copy the exif from original images to processed images that have lost all data... quite powerfull... command line quite complete\complex) :P In

[hugin-ptx] Re: SVN 4147 doesnt build

Bruno Postle wrote: > I've reverted the commit that broke this, but what remains is that > hugin now only builds with the latest cmake, this needs to be fixed. I update the root CmakeLists.txt to state the requirement for cmake-2.6. I think the effort of fixing this is better directed at gettin

[hugin-ptx] Re: Celeste not compilable

Danke Kornel! Kornel Benko wrote: > Here is, how I use it. it all worked and I updated the documentation So now I have to look into the chrooting as suggested by Roger and then I shall be able to build both 32 and 64 bit versions for whatever

[hugin-ptx] Re: SVN 4147 doesnt build

On Sun 02-Aug-2009 at 22:09 +0200, Kornel Benko wrote: >> /usr/bin/ld: cannot find -lboost_thread > >Hmmm, should it not be "-lboost_thread-mt"? It depends on the system, sometimes it is boost_thread and sometimes boost_thread-mt. I've reverted the commit that broke this, but what remains is th

[hugin-ptx] Re: Lens information from Exif

Nicolas Pelletier wrote: > I read somewhere that hugin should recognize what focal length was used by > the exif. > It seems to work when I take pictures from my old camera, but not my new > one. Both go through the same process, and both have proper exif info in the > tiff. what is your new came

[hugin-ptx] Re: Celeste not compilable

Markku Kolkka wrote: > Like Bruno already explained, the above is the reason why you > should never publish packages that install anything > _in_ /usr/local. Use /opt if you are really opposed to > installing in /usr. I think I start to understand? => Packages for distribution: /usr => Package

[hugin-ptx] Re: setting hugin tmp directory in 0.8.0 release

On Sun 02-Aug-2009 at 22:34 +0100, Doug wrote: > >> Another possibility is that when you click Stitch Now, hugin creates >> a temporary folder and places all the working files there. Maybe >> this folder location isn't effected by the Preferences setting? >> >I think that's the case; the first li

[hugin-ptx] Re: setting hugin tmp directory in 0.8.0 release

Bruno Postle wrote: > On Sun 02-Aug-2009 at 11:14 +0200, LukᨠJirkovský wrote: > >> Interesting, when I've tried that it worked. Can you please check if >> the .pto.mk file contains TMPDIR=/media/disk-2/tmp somewhere at the >> beginning? The problem may also be that the tempdir is used only fo

[hugin-ptx] Re: manually creating fake control points with already aligned images.

On Sun 02-Aug-2009 at 22:08 +0200, tennevin.yves wrote: > >Assuming the hugin model awaits images linked together via control >points, could it be modified to allow hints to be passed to the >control point maker, so only the matching images have to be >compared? Yes, the way to do it is to ext

[hugin-ptx] Lens information from Exif

I read somewhere that hugin should recognize what focal length was used by the exif. It seems to work when I take pictures from my old camera, but not my new one. Both go through the same process, and both have proper exif info in the tiff. Is there a step I missed somewhere to have this working?

[hugin-ptx] Re: The way to 2009.2

Gerry Patterson wrote: >> Rename the Enblend tab in the Preferences dialog to "Stitching". Add a >> section called "Nona" (similar to the existing Enblend and Enfuse sections) >> and here add entries for defaults to use in projects (interpolator, cropped >> tiff output...). Here a checkbox could

[hugin-ptx] Re: SVN 4147 doesnt build

Am Sonntag 02 August 2009 schrieb Jean-Luc Coulon (f5ibh): > Hi, > > I get, from a fresh copy: > > > [ 7%] Built target huginlevmar > make[3]: Entering directory `/usr/local/src/hugin/hugin-0.8.0' > make[3]: Leaving directory `/usr/local/src/hugin/hugin-0.8.0' > [ 15%] Built target huginvigraimpex

[hugin-ptx] Re: manually creating fake control points with already aligned images.

Bruno Postle wrote: > On Fri 31-Jul-2009 at 11:05 +0200, tennevin yves wrote: > >> Could there be a way to: >> - mass align image manually? ( + or -36 72 108 or any other multiple of >> a given angle) >> > > You can use an existing project as a template. > > >> - create fake control poi

[hugin-ptx] SVN 4147 doesnt build

Hi, I get, from a fresh copy: [ 7%] Built target huginlevmar make[3]: Entering directory `/usr/local/src/hugin/hugin-0.8.0' make[3]: Leaving directory `/usr/local/src/hugin/hugin-0.8.0' [ 15%] Built target huginvigraimpex make[3]: Entering directory `/usr/local/src/hugin/hugin-0.8.0' make[3]: L

[hugin-ptx] Re: Problem compiling hugin (Ubuntu 8.04)

On Tue 28-Jul-2009 at 15:13 -0700, alexG wrote: > >In each of them add -lboost_thread-mt at the end of the c++ command >(remark: I've noticed that the option -lz always appears twice while - >lboost_threads-mt is missing, so you may search-and-replace "-lz -lz" >with "-lz -boost_thread-mt"): This

[hugin-ptx] Re: The way to 2009.2

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

[hugin-ptx] Re: The way to 2009.2

Hi Yuv, > > * include not found > > would something like: > > #ifdef _WIN32 > #include > #else > #include > #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

[hugin-ptx] Re: Canvas size in Stitcher Tab

At the moment I just calculate the resizing factor for the height, and use that factor for calculating the width. Then that problem is solved too. Most of the time I fit the height with the vertical angle of view slider in the fast preview.So it fits vertical exactly in the canvas. When using the

[hugin-ptx] nona-gpu and multicore?

Hi all, just read that nona-gpu was integrated in the trunk, and already a question about it: Will the gpu-feature work with multiple threads? Or, what is the tradeoff between using multiple threads (in my case, 4) of nona vs. nona-gpu? Just thinking, it'd be stupid if nona-gpu is like 100%

[hugin-ptx] Re: The way to 2009.2

Hi Thomas, thanks for looking into this. T. Modes wrote: > The trunk does not compile on windows. (I asked for help some time > ago, but there was no reaction.) yes, this is critical for release and I guess there will be some reaction now. I also estimate that this is relatively easy to fix wi

[hugin-ptx] Re: The way to 2009.2

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

[hugin-ptx] Re: Canvas size in Stitcher Tab

Hi Henk, thanks for the bug reports. indeed, the numeric input fields on the stitcher tab have a behavior that may seem quirky until you adapt, and since most panoramas are horizontal this is not very optimal for your case of vertical mosaic. the workaround is that in the fast preview window

[hugin-ptx] Re: Canvas size in Stitcher Tab

I've made a bug report about it in the tracker on sourceforge.net. Kind regards, Henk Tijdink On 1 aug, 22:36, Henk Tijdink wrote: > Using Hugin 08.0.4008Allard on Windows XP, but possible in other > releases for other systems too. > When changing the width of the canvas size the height is auto

[hugin-ptx] Re: setting hugin tmp directory in 0.8.0 release

On Sun 02-Aug-2009 at 11:14 +0200, Lukáš Jirkovský wrote: > >Interesting, when I've tried that it worked. Can you please check if >the .pto.mk file contains TMPDIR=/media/disk-2/tmp somewhere at the >beginning? The problem may also be that the tempdir is used only for >some files (I've tested it w

[hugin-ptx] Re: setting hugin tmp directory in 0.8.0 release

2009/7/29 Doug : > > How do I get the tmp directory in hugin so that it is not chosen by the > OS  (linux MDV 2008.1)? > > In File=>Preferences I set Tempdir to "/media/disk-2/tmp". > .hugin shows "tempDir=/media/disk-2/tmp" > > but all the working files are still going into /home/dougb/tmp where

[hugin-ptx] Re: Celeste not compilable

Yuval Levy kirjoitti viestissään (lähetysaika sunnuntai, 2. elokuuta 2009): > I think we're almost on the same page for this. In FreeBSD > /usr is the base system and /usr/local is everything that the > user added on top of it, and I like it exactly because "you > can always `rm -rf /usr/local`".

[hugin-ptx] Re: The way to 2009.2

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