I built a new bundle. It includes lensfun. It's an intel only 32bit/64bit bundle for Leopard and newer. It's without python, that's (again) the next challenge.
Changelog: = This OSX build - Only built for Intel (i386/x86_64). No longer support for PPC (G4/G5). - Runs on Leopard (10.5) and newer. No more Tiger (10.4.x) support. - enblend/enfuse are openMP enabled and should run on Lion. - multiblend 0.31beta added. Also Openmp enabled. - the 64bit part (as they are universal i386/x86_64) of the panotools binaries (PTBlender, PTOptimizer, etc.) are also openmp enabled. - Many library updates
= Hugin: - Addition of lensfun functionality by Thomas Modes - multiple bugfixes by Thomas - some updated translations.
> I built a new bundle. It includes lensfun. It's an intel only 32bit/64bit
> bundle for Leopard and newer.
> It's without python, that's (again) the next challenge.
> Changelog:
> = This OSX build
> - Only built for Intel (i386/x86_64). No longer support for PPC (G4/G5).
> - Runs on Leopard (10.5) and newer. No more Tiger (10.4.x) support.
> - enblend/enfuse are openMP enabled and should run on Lion.
> - multiblend 0.31beta added. Also Openmp enabled.
> - the 64bit part (as they are universal i386/x86_64) of the panotools
> binaries (PTBlender, PTOptimizer, etc.) are also openmp enabled.
> - Many library updates
> = Hugin:
> - Addition of lensfun functionality by Thomas Modes
> - multiple bugfixes by Thomas
> - some updated translations.
Yes the old PTBatcher runs the old versions of the tools. At least at
first I thought that I could tell it was the old versions because the
old MultiBlend ran with its RGB problem and produced some interesting
results with spookie colours.
To get the new PTBatcher active I launched it manually the first time
and then when Hugin started a stitch session it passed it to the new
PTBatcher. But it seems this new version of MultiBlend still has the
RGB/BGR problem when stitching 16-bit TIFF images. So the --bgr
option is still needed to avoid teh spookie colour transformation.
Having said that I do quite like the spookie colours.
all the best
George
On Apr 19, 9:25 pm, George R <george...@gmail.com> wrote:
> By way of a first test I have just launched a test stitch of a recent
> project.
> I noticed that it invoked the old version of the PTBatcher.
> Is that likely to be a problem? My intuitions tell me it will ... but
> what do they know?
> Any idea what I need to do to make the new version invoke the new
> PTBatcher?
> all the best
> George
> On Apr 19, 5:20 pm, Harry van der Wolf <hvdw...@gmail.com> wrote:
> > Hi mac users,
> > I built a new bundle. It includes lensfun. It's an intel only 32bit/64bit
> > bundle for Leopard and newer.
> > It's without python, that's (again) the next challenge.
> > Changelog:
> > = This OSX build
> > - Only built for Intel (i386/x86_64). No longer support for PPC (G4/G5).
> > - Runs on Leopard (10.5) and newer. No more Tiger (10.4.x) support.
> > - enblend/enfuse are openMP enabled and should run on Lion.
> > - multiblend 0.31beta added. Also Openmp enabled.
> > - the 64bit part (as they are universal i386/x86_64) of the panotools
> > binaries (PTBlender, PTOptimizer, etc.) are also openmp enabled.
> > - Many library updates
> > = Hugin:
> > - Addition of lensfun functionality by Thomas Modes
> > - multiple bugfixes by Thomas
> > - some updated translations.
Op 20 april 2012 02:05 schreef George R <george...@gmail.com> het volgende:
> To answer my own questions...
> Yes the old PTBatcher runs the old versions of the tools. At least at > first I thought that I could tell it was the old versions because the > old MultiBlend ran with its RGB problem and produced some interesting > results with spookie colours.
You are right. That's also why I started using the installer some time ago, which I have abandoned now again for the development builds after multiple requests.
On OS X apps are "registered" after the first moment they have run. When having multiple Hugins and PTBatcherGuis, the one that is registered is the one that has last run. On an installation though the installed applications are "official" registered, all 3 at once, which makes that installed one the officially registered one.
I started building the installer as we had quite some changes in the PTBatcher at that time, which also changed the "interface" (so to say), resulting in crashes if a new Hugin called the old automatically registered ptbatchergui.
All "helper" apps (enblend/enfuse, multiblend, cpfind, align_image_stack) are since a year (or so) inside Hugin.app. That's also the reason why the Hugin.app, PTBatcherGui.app and Calibrate_Lens_Gui.app have to stick together in one folder. However, when an old PTBatcherGui is started from another folder, it will take the helper binaries from the old Hugin in that same folder, which means that it will take the old binaries.
I tried to explain this when I got comments on the installer, but maybe I wasn't clear enough.
Harry,
Thanks for that. My first test was just a single equirectangular-->
Stereographic.
Today I tried a full stitch of an old project with 11x3(bracketed)x16-
bit Tiff files, stitching to a Blended-and-Fused equirectangular ... I
noticed that I get an error message saying "Tiff Library Missing" when
Hugin invokes PTBatcher ... it seems to go ahead and run (at least it
is running at the moment as I am typing this).
Is that error message about something I should have installed but
haven't,
or something you left out,
or a warning that we can ignore?
all the best
George
On Apr 20, 6:44 am, Harry van der Wolf <hvdw...@gmail.com> wrote:
> Op 20 april 2012 02:05 schreef George R <george...@gmail.com> het volgende:
> > To answer my own questions...
> > Yes the old PTBatcher runs the old versions of the tools. At least at
> > first I thought that I could tell it was the old versions because the
> > old MultiBlend ran with its RGB problem and produced some interesting
> > results with spookie colours.
> You are right. That's also why I started using the installer some time ago,
> which I have abandoned now again for the development builds after multiple
> requests.
> On OS X apps are "registered" after the first moment they have run. When
> having multiple Hugins and PTBatcherGuis, the one that is registered is the
> one that has last run.
> On an installation though the installed applications are "official"
> registered, all 3 at once, which makes that installed one the officially
> registered one.
> I started building the installer as we had quite some changes in the
> PTBatcher at that time, which also changed the "interface" (so to say),
> resulting in crashes if a new Hugin called the old automatically registered
> ptbatchergui.
> All "helper" apps (enblend/enfuse, multiblend, cpfind, align_image_stack)
> are since a year (or so) inside Hugin.app. That's also the reason why the
> Hugin.app, PTBatcherGui.app and Calibrate_Lens_Gui.app have to stick
> together in one folder.
> However, when an old PTBatcherGui is started from another folder, it will
> take the helper binaries from the old Hugin in that same folder, which
> means that it will take the old binaries.
> I tried to explain this when I got comments on the installer, but maybe I
> wasn't clear enough.
Harry,
The project I mentioned ran OK on the previous version ... it stitches
a set of bracketed exposures both as a fused and as a blended-and-
fused equirectangular panorama.
I got the error about the missing TIFF library lots of times.
The odd thing is that the fused version worked fine but the blended-
and-fused version crashed and produced the status reports below.
all the best
George
____________________________________
/Applications/hugin-mac-2011.5.0.5758/PTBatcherGUI.app/Contents/
Resources/ExifTool/exiftool -E -overwrite_original_in_place -
TagsFromFile /Volumes/T_A/Photography/VR/International/Amsterdam/
PrinsenGracht//_MG_8055.tiff -ImageDescription -Make -Model -Artist -
WhitePoint -Copyright -GPS:all -DateTimeOriginal -CreateDate -
UserComment -ColorSpace -OwnerName -SerialNumber '-Software=Hugin
2011.5.0.5758:63173b3a4a4b built by Harry van der Wolf' '-UserComment<$
{UserComment}
Projection: Equirectangular (2)
FOV: 360 x
180
Ev: 9.58' -f PrinsenGracht_fused.tif
1 image files updated
/Applications/hugin-mac-2011.5.0.5758/PTBatcherGUI.app/Contents/MacOS/
enfuse --compression=LZW -w -o PrinsenGracht_blended_fused.tif --
PrinsenGracht_exposure_0000.tif PrinsenGracht_exposure_0001.tif
PrinsenGracht_exposure_0002.tif
enfuse: warning: no usable resolution found in first image
"PrinsenGracht_exposure_0000.tif";
enfuse: warning: will use 300 dpi
enfuse: info: loading next image: PrinsenGracht_exposure_0000.tif 1/1
enfuse: info: loading next image: PrinsenGracht_exposure_0001.tif 1/1
enfuse: info: loading next image: PrinsenGracht_exposure_0002.tif 1/1
enfuse: error: OJPEG encoding not supported; use new-style JPEG
compression instead
terminate called after throwing an instance of
'vigra::Encoder::TIFFCompressionException'
gnumake: *** [PrinsenGracht_blended_fused.tif] Abort trap
gnumake: *** Deleting file `PrinsenGracht_blended_fused.tif'
____________________________________
On Apr 20, 2:30 pm, George R <george...@gmail.com> wrote:
> Harry,
> Thanks for that. My first test was just a single equirectangular-->
> Stereographic.
> Today I tried a full stitch of an old project with 11x3(bracketed)x16-
> bit Tiff files, stitching to a Blended-and-Fused equirectangular ... I
> noticed that I get an error message saying "Tiff Library Missing" when
> Hugin invokes PTBatcher ... it seems to go ahead and run (at least it
> is running at the moment as I am typing this).
> Is that error message about something I should have installed but
> haven't,
> or something you left out,
> or a warning that we can ignore?
> all the best
> George
> On Apr 20, 6:44 am, Harry van der Wolf <hvdw...@gmail.com> wrote:
> > Hi George,
> > Op 20 april 2012 02:05 schreef George R <george...@gmail.com> het volgende:
> > > To answer my own questions...
> > > Yes the old PTBatcher runs the old versions of the tools. At least at
> > > first I thought that I could tell it was the old versions because the
> > > old MultiBlend ran with its RGB problem and produced some interesting
> > > results with spookie colours.
> > You are right. That's also why I started using the installer some time ago,
> > which I have abandoned now again for the development builds after multiple
> > requests.
> > On OS X apps are "registered" after the first moment they have run. When
> > having multiple Hugins and PTBatcherGuis, the one that is registered is the
> > one that has last run.
> > On an installation though the installed applications are "official"
> > registered, all 3 at once, which makes that installed one the officially
> > registered one.
> > I started building the installer as we had quite some changes in the
> > PTBatcher at that time, which also changed the "interface" (so to say),
> > resulting in crashes if a new Hugin called the old automatically registered
> > ptbatchergui.
> > All "helper" apps (enblend/enfuse, multiblend, cpfind, align_image_stack)
> > are since a year (or so) inside Hugin.app. That's also the reason why the
> > Hugin.app, PTBatcherGui.app and Calibrate_Lens_Gui.app have to stick
> > together in one folder.
> > However, when an old PTBatcherGui is started from another folder, it will
> > take the helper binaries from the old Hugin in that same folder, which
> > means that it will take the old binaries.
> > I tried to explain this when I got comments on the installer, but maybe I
> > wasn't clear enough.
> Harry, > The project I mentioned ran OK on the previous version ... it stitches > a set of bracketed exposures both as a fused and as a blended-and- > fused equirectangular panorama.
> I got the error about the missing TIFF library lots of times.
> The odd thing is that the fused version worked fine but the blended- > and-fused version crashed and produced the status reports below. > all the best
> George
> ____________________________________ > /Applications/hugin-mac-2011.5.0.5758/PTBatcherGUI.app/Contents/ > Resources/ExifTool/exiftool -E -overwrite_original_in_place - > TagsFromFile /Volumes/T_A/Photography/VR/International/Amsterdam/ > PrinsenGracht//_MG_8055.tiff -ImageDescription -Make -Model -Artist - > WhitePoint -Copyright -GPS:all -DateTimeOriginal -CreateDate - > UserComment -ColorSpace -OwnerName -SerialNumber '-Software=Hugin > 2011.5.0.5758:63173b3a4a4b built by Harry van der Wolf' '-UserComment<$ > {UserComment}
Projection: Equirectangular (2)
FOV: 360 x > 180
Ev: 9.58' -f PrinsenGracht_fused.tif > 1 image files updated > /Applications/hugin-mac-2011.5.0.5758/PTBatcherGUI.app/Contents/MacOS/ > enfuse --compression=LZW -w -o PrinsenGracht_blended_fused.tif -- > PrinsenGracht_exposure_0000.tif PrinsenGracht_exposure_0001.tif > PrinsenGracht_exposure_0002.tif > enfuse: warning: no usable resolution found in first image > "PrinsenGracht_exposure_0000.tif"; > enfuse: warning: will use 300 dpi > enfuse: info: loading next image: PrinsenGracht_exposure_0000.tif 1/1 > enfuse: info: loading next image: PrinsenGracht_exposure_0001.tif 1/1 > enfuse: info: loading next image: PrinsenGracht_exposure_0002.tif 1/1 > enfuse: error: OJPEG encoding not supported; use new-style JPEG > compression instead > terminate called after throwing an instance of > 'vigra::Encoder::TIFFCompressionException' > gnumake: *** [PrinsenGracht_blended_fused.tif] Abort trap > gnumake: *** Deleting file `PrinsenGracht_blended_fused.tif'
> _
I really don't know. The tiff library is included in the package and enfuse is nicely compiled against this tiff library 3.94 (where 3.95 is the latest just released version). The jpeg library is 8d, which is the latest. I still compile against the builtin vigra for both enfuse/enblend and Hugin. Hugin can now also be compiled against and external vigra library.
Another option could be that the intermediate tiffs "PrinsenGracht_exposure_00xy.tif", created by nona, are different than before. The weird thing is that it mentions that it encounters a wrong jpeg compression in a tiff file. - Tiffs don't use jpeg compression (wrong enfuse error?) - The intermediate tiffs created by nona are uncompressed, which makes it even weirder.
I hope someone else like Bruno or Thomas drops in. Maybe they have a clue.
On Sat, Apr 21, 2012 at 09:00:16AM +0200, Harry van der Wolf wrote:
> > enfuse: error: OJPEG encoding not supported; use new-style JPEG > The weird thing is that it mentions that it encounters a wrong jpeg > compression in a tiff file. > - Tiffs don't use jpeg compression (wrong enfuse error?)
Tiff don't use JPG compression? Where did you get that idea???
Tiff is a file format that allows a sequence of tagged blobs (blob= bunch of binary data). Usually one is an Image blob, and the compression mode can be specified. Several compression methods are available, like none, lzw, rle and jpeg.
Anyway.... it isn't complaining about jpeg compression in the tiff file.
You get this message when you're running the wrong headers in combination with the wrong library.
The program tries to specify COMPRESSION_LZW which was defined as #define COMPRESSION_LZW 4 in one version of the library, but the new version has: #define COMPRESSION_OJPEG 4 in the header. So the library interprets the passed value wrong.
(I made up the symbols and values in the above example, but it's something like that.)
Anyway, the program is /using/ a different TIFF library from the headers it was compiled against.
Roger.
-- ** R.E.Wo...@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** ** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 ** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work.
I am not sure whether the data I'm about to give you adds any more
information - so I'll just say it and let you experts judge.
The project that provoked the error was stitching a panorama with:
"Format TIFF Compression LZW"
... so I re-ran the stitch with:
"Format TIFF Compression None"
This time there was no error and the project ran to successful
completion.
For me that is a solution ... I'll just make sure I have plenty of
disc space available and run with no compression! :-)
all the best
George
On Apr 21, 9:00 am, Rogier Wolff <rew-googlegro...@BitWizard.nl>
wrote:
> On Sat, Apr 21, 2012 at 09:00:16AM +0200, Harry van der Wolf wrote:
> > > enfuse: error: OJPEG encoding not supported; use new-style JPEG
> > The weird thing is that it mentions that it encounters a wrong jpeg
> > compression in a tiff file.
> > - Tiffs don't use jpeg compression (wrong enfuse error?)
> Tiff don't use JPG compression? Where did you get that idea???
> Tiff is a file format that allows a sequence of tagged blobs (blob=
> bunch of binary data). Usually one is an Image blob, and the
> compression mode can be specified. Several compression methods are
> available, like none, lzw, rle and jpeg.
> Anyway.... it isn't complaining about jpeg compression in the tiff
> file.
> You get this message when you're running the wrong headers in
> combination with the wrong library.
> The program tries to specify
> COMPRESSION_LZW
> which was defined as
> #define COMPRESSION_LZW 4
> in one version of the library, but the new version has:
> #define COMPRESSION_OJPEG 4
> in the header. So the library interprets the passed value wrong.
> (I made up the symbols and values in the above example, but it's
> something like that.)
> Anyway, the program is /using/ a different TIFF library from the
> headers it was compiled against.
> Roger.
> --
> ** R.E.Wo...@BitWizard.nl **http://www.BitWizard.nl/** +31-15-2600998 **
> ** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
> *-- BitWizard writes Linux device drivers for any device you may have! --*
> The plan was simple, like my brother-in-law Phil. But unlike
> Phil, this plan just might work.
Op 21 april 2012 10:00 schreef Rogier Wolff <rew-googlegro...@bitwizard.nl>het volgende:
> On Sat, Apr 21, 2012 at 09:00:16AM +0200, Harry van der Wolf wrote: > > > enfuse: error: OJPEG encoding not supported; use new-style JPEG
> > The weird thing is that it mentions that it encounters a wrong jpeg > > compression in a tiff file. > > - Tiffs don't use jpeg compression (wrong enfuse error?)
> Tiff don't use JPG compression? Where did you get that idea???
You're right. I was too short in my answer as I wanted to keep it simple. What I meant to say is that the tiffs in Hugin don't use jpeg(=lossy) compression. They use lzw, deflate or none.
> Tiff is a file format that allows a sequence of tagged blobs (blob= > bunch of binary data). Usually one is an Image blob, and the > compression mode can be specified. Several compression methods are > available, like none, lzw, rle and jpeg.
> Anyway.... it isn't complaining about jpeg compression in the tiff > file.
> You get this message when you're running the wrong headers in > combination with the wrong library.
> The program tries to specify > COMPRESSION_LZW > which was defined as > #define COMPRESSION_LZW 4 > in one version of the library, but the new version has: > #define COMPRESSION_OJPEG 4 > in the header. So the library interprets the passed value wrong.
> (I made up the symbols and values in the above example, but it's > something like that.)
> Anyway, the program is /using/ a different TIFF library from the > headers it was compiled against.
To be honest: I didn't know about the jpeg (IJG) and old-jpeg, but reading that error it was the first thing I checked. When I started with Hugin on OSX we were at jpeg6b from the IJG group and I'm still using that library, now at version 8d. All binaries and libraries are compiled against the same libtiff (and jpeg and png for that matter), thereby using the same header files from the same include path. I checked that with a.o. "otool -L ..." and especially checked for files being "slipped in" from my macports: none at all. My libtiff is compiled with both old-jpeg and jpeg support.
If you have more suggestions on what went wrong, please let me know.
On Sat, Apr 21, 2012 at 02:46:32PM +0200, Harry van der Wolf wrote:
> To be honest: I didn't know about the jpeg (IJG) and old-jpeg, but reading > that error it was the first thing I checked. When I started with Hugin on > OSX we were at jpeg6b from the IJG group and I'm still using that library, > now at version 8d. > All binaries and libraries are compiled against the same libtiff (and jpeg > and png for that matter), thereby using the same header files from the same > include path. I checked that with a.o. "otool -L ..." and especially > checked for files being "slipped in" from my macports: none at all. > My libtiff is compiled with both old-jpeg and jpeg support.
> If you have more suggestions on what went wrong, please let me know.
The big test is, can YOU run with LZW compression? (I expect: yes) If so, that is a strong hint that george is not using the same library binary as you are.
This could mean that on your system you are not using the tiff library you just built and include in the package, or the other way around, on george's system the hugin tools are not using the packaged libraries but the system ones.
Roger.
-- ** R.E.Wo...@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** ** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 ** *-- BitWizard writes Linux device drivers for any device you may have! --* The plan was simple, like my brother-in-law Phil. But unlike Phil, this plan just might work.
Can you rename all Hugin.app and PTBatcherGui.app versions that you're not using to something like .app.org. Then start PTBatcherGui, leave it open, then start Hugin.app and do a workflow?
I have the vague idea that too many versions exist on your system and that incompatible combinations are called.
Harry
Op 22 april 2012 14:43 schreef Rogier Wolff <rew-googlegro...@bitwizard.nl>het volgende:
> On Sat, Apr 21, 2012 at 02:46:32PM +0200, Harry van der Wolf wrote: > > To be honest: I didn't know about the jpeg (IJG) and old-jpeg, but > reading > > that error it was the first thing I checked. When I started with Hugin > on > > OSX we were at jpeg6b from the IJG group and I'm still using that > library, > > now at version 8d. > > All binaries and libraries are compiled against the same libtiff (and > jpeg > > and png for that matter), thereby using the same header files from the > same > > include path. I checked that with a.o. "otool -L ..." and especially > > checked for files being "slipped in" from my macports: none at all. > > My libtiff is compiled with both old-jpeg and jpeg support.
> > If you have more suggestions on what went wrong, please let me know.
> The big test is, can YOU run with LZW compression? (I expect: yes) If > so, that is a strong hint that george is not using the same library > binary as you are.
> This could mean that on your system you are not using the tiff library > you just built and include in the package, or the other way around, on > george's system the hugin tools are not using the packaged libraries > but the system ones.
> Roger.
> -- > ** R.E.Wo...@BitWizard.nl ** http://www.BitWizard.nl/ ** +31-15-2600998 ** > ** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 ** > *-- BitWizard writes Linux device drivers for any device you may have! --* > The plan was simple, like my brother-in-law Phil. But unlike > Phil, this plan just might work.
> -- > 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-ptx@googlegroups.com > To unsubscribe from this group, send email to > hugin-ptx+unsubscribe@googlegroups.com > For more options, visit this group at > http://groups.google.com/group/hugin-ptx
Harry,
I have just checked ... I have more than 40 versions of Hugin on this
machine! I tend to be cautious and keep the old version when I
install a new one ... :-) By the look of it my last big clear out was
March 2010!
So what I will do is install a fresh copy of your latest version on
another Mac that I don't usually use for Hugin and then give that a
try accessing the data and project files over the network.
But it will be this evening or possible tomorrow before I will be able
to do that.
all the best
George
On Apr 22, 2:36 pm, Harry van der Wolf <hvdw...@gmail.com> wrote:
> Can you rename all Hugin.app and PTBatcherGui.app versions that you're not
> using to something like .app.org.
> Then start PTBatcherGui, leave it open, then start Hugin.app and do a
> workflow?
> I have the vague idea that too many versions exist on your system and that
> incompatible combinations are called.
> Harry
> Op 22 april 2012 14:43 schreef Rogier Wolff
> <rew-googlegro...@bitwizard.nl>het volgende:
> > On Sat, Apr 21, 2012 at 02:46:32PM +0200, Harry van der Wolf wrote:
> > > To be honest: I didn't know about the jpeg (IJG) and old-jpeg, but
> > reading
> > > that error it was the first thing I checked. When I started with Hugin
> > on
> > > OSX we were at jpeg6b from the IJG group and I'm still using that
> > library,
> > > now at version 8d.
> > > All binaries and libraries are compiled against the same libtiff (and
> > jpeg
> > > and png for that matter), thereby using the same header files from the
> > same
> > > include path. I checked that with a.o. "otool -L ..." and especially
> > > checked for files being "slipped in" from my macports: none at all.
> > > My libtiff is compiled with both old-jpeg and jpeg support.
> > > If you have more suggestions on what went wrong, please let me know.
> > The big test is, can YOU run with LZW compression? (I expect: yes) If
> > so, that is a strong hint that george is not using the same library
> > binary as you are.
> > This could mean that on your system you are not using the tiff library
> > you just built and include in the package, or the other way around, on
> > george's system the hugin tools are not using the packaged libraries
> > but the system ones.
> > Roger.
> > --
> > ** R.E.Wo...@BitWizard.nl **http://www.BitWizard.nl/** +31-15-2600998 **
> > ** Delftechpark 26 2628 XH Delft, The Netherlands. KVK: 27239233 **
> > *-- BitWizard writes Linux device drivers for any device you may have! --*
> > The plan was simple, like my brother-in-law Phil. But unlike
> > Phil, this plan just might work.
> > --
> > 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-ptx@googlegroups.com
> > To unsubscribe from this group, send email to
> > hugin-ptx+unsubscribe@googlegroups.com
> > For more options, visit this group at
> >http://groups.google.com/group/hugin-ptx
