Congratulations to everyone responsible for this release!
Changes since 0.6.1
Hugin has changed enormously in the two years since the 0.6.1 release, hardly any part of the code has remained untouched. There have been many many bug-fixes, improvements to the interface and lots of new features - Here are just some of them:
Online help
Hugin now has comprehensive help documentation for the entire user interface, the manual now includes glossary items explaining many panorama stitching and related photography concepts.
Languages
New translations include Slovak, Korean, Bulgarian and Spanish. This means that hugin is now usable with a total of twenty languages.
New Assistant panel
Creating simple panoramas is much easier, hugin now starts showing an Assistant with a simple 1-2-3 approach for loading images, aligning and creating the final output.
The Assistant will estimate lens and camera parameters, then pick a suitable output projection and size, advanced options are still available for manual adjustment.
Photometric model
Previous versions of hugin and panotools had basic support for correcting vignetting and exposure differences between photos.
This has been completely overhauled, hugin now internally uses the EMoR model for representing exposure photometrically. This means that the camera response curve, vignetting, colour balance and exposure can now be optimised in much the same way as geometrical properties such as position and lens distortion.
The result is that blending between photos is better than ever before.
HDR
Previously hugin supported High Dynamic Range imaging solely by allowing stitching of HDR floating-point TIFF photos - These images themselves had to be created in another tool.
Now, thanks to the internal photometric model, hugin can now create HDR output from normal exposure bracketed photos. The photos don't have to be perfectly-aligned, they don't even need to be nearly-aligned or have consistent exposure differences - The hugin optimiser will sort all this stuff out, and the stitcher will create OpenEXR or TIFF HDR output files for later tonemapping or use as lightprobes.
Exposure blending
HDR and tonemapping isn't for everybody, enfuse introduced exposure blending to the world, and hugin supports aligning and fusing bracketed stacks of photos, perfectly, all as part of the stitching process.
So now with hugin-0.7.0 and enblend-3.2 you can create realistic, photographic panoramas that have no over-exposed or under-exposed areas.
Makefile stitching
hugin-0.7.0 introduces a new stitching back-end: previously the various stitching tools were executed directly by the GUI, now all the commands required to generate the output are written to a Makefile which is then processed independently of hugin itself.
Aside from easier debugging and customisation; this background stitching allows you to get on with creating a new project while waiting for the previous job to finish - Stitching can also be deferred or shifted to another machine, even 'headless' servers can now be used.
Projections
Hugin has always had the ability to save panoramas using simulated normal and fisheye lenses, or 360 degree cylindrical and spherical projections.
Now a whole series of alternative cartographic mappings are available, of particular interest are the 'conformal' stereographic and Mercator projections which can be used to show extremely large angles of view with no local distortion.
Project templates
Hugin project files can now be used as templates for new panorama projects. This is useful if you take a lot of panoramas with exactly the same camera positions.
Other improvements
There's a whole lot of other new stuff in this release: numbering in the control-point editor, straight-line control-points, numeric transform, clicking to rotate the preview, a straighten button, cropping of the output and probably more.
Command-line tools
This release provides new command-line tools:
* align_image_stack: align a nearly-aligned stack of photos * pto2mk: create a stitching Makefile from a pto project * vig_optimise: optimise photometric parameters * tca_correct: calculate lens chromatic aberration * hugin_hdrmerge: assemble a bracketed stack to HDR * matchpoint: classify control point features
Control point generators
Hugin doesn't yet ship with a 'Patent Free' control point generator. So you either need to pick control points manually - Not as difficult as it sounds - or install and configure one of the following control-point generators as 'plug-ins', in no particular order:
* autopano-sift-C * panomatic * Autopano-SIFT * Autopano freeware version
Upgrading
Upgrading from previous versions of hugin should be seamless. If you do have problems with old settings, these can be reset in the Preferences by clicking 'Load defaults'.
See the the README and INSTALL_cmake files for more information.
Thanks to all the contributors to this release and members of the ptx mailing list, too many to mention here.
On Sat, Oct 4, 2008 at 6:34 PM, Bruno Postle <br...@postle.net> wrote:
> Congratulations to everyone responsible for this release!
> Changes since 0.6.1
> Hugin has changed enormously in the two years since the 0.6.1 > release, hardly any part of the code has remained untouched. There > have been many many bug-fixes, improvements to the interface and > lots of new features - Here are just some of them:
> Online help
> Hugin now has comprehensive help documentation for the entire user > interface, the manual now includes glossary items explaining many > panorama stitching and related photography concepts.
> Languages
> New translations include Slovak, Korean, Bulgarian and Spanish. This > means that hugin is now usable with a total of twenty languages.
> New Assistant panel
> Creating simple panoramas is much easier, hugin now starts showing > an Assistant with a simple 1-2-3 approach for loading images, > aligning and creating the final output.
> The Assistant will estimate lens and camera parameters, then pick a > suitable output projection and size, advanced options are still > available for manual adjustment.
> Photometric model
> Previous versions of hugin and panotools had basic support for > correcting vignetting and exposure differences between photos.
> This has been completely overhauled, hugin now internally uses the > EMoR model for representing exposure photometrically. This means > that the camera response curve, vignetting, colour balance and > exposure can now be optimised in much the same way as geometrical > properties such as position and lens distortion.
> The result is that blending between photos is better than ever > before.
> HDR
> Previously hugin supported High Dynamic Range imaging solely by > allowing stitching of HDR floating-point TIFF photos - These images > themselves had to be created in another tool.
> Now, thanks to the internal photometric model, hugin can now create > HDR output from normal exposure bracketed photos. The photos don't > have to be perfectly-aligned, they don't even need to be > nearly-aligned or have consistent exposure differences - The hugin > optimiser will sort all this stuff out, and the stitcher will create > OpenEXR or TIFF HDR output files for later tonemapping or use as > lightprobes.
> Exposure blending
> HDR and tonemapping isn't for everybody, enfuse introduced exposure > blending to the world, and hugin supports aligning and fusing > bracketed stacks of photos, perfectly, all as part of the stitching > process.
> So now with hugin-0.7.0 and enblend-3.2 you can create realistic, > photographic panoramas that have no over-exposed or under-exposed > areas.
> Makefile stitching
> hugin-0.7.0 introduces a new stitching back-end: previously the > various stitching tools were executed directly by the GUI, now all > the commands required to generate the output are written to a > Makefile which is then processed independently of hugin itself.
> Aside from easier debugging and customisation; this background > stitching allows you to get on with creating a new project while > waiting for the previous job to finish - Stitching can also be > deferred or shifted to another machine, even 'headless' servers can > now be used.
> Projections
> Hugin has always had the ability to save panoramas using simulated > normal and fisheye lenses, or 360 degree cylindrical and spherical > projections.
> Now a whole series of alternative cartographic mappings are > available, of particular interest are the 'conformal' stereographic > and Mercator projections which can be used to show extremely large > angles of view with no local distortion.
> Project templates
> Hugin project files can now be used as templates for new panorama > projects. This is useful if you take a lot of panoramas with exactly > the same camera positions.
> Other improvements
> There's a whole lot of other new stuff in this release: numbering in > the control-point editor, straight-line control-points, numeric > transform, clicking to rotate the preview, a straighten button, > cropping of the output and probably more.
> Command-line tools
> This release provides new command-line tools:
> * align_image_stack: align a nearly-aligned stack of photos > * pto2mk: create a stitching Makefile from a pto project > * vig_optimise: optimise photometric parameters > * tca_correct: calculate lens chromatic aberration > * hugin_hdrmerge: assemble a bracketed stack to HDR > * matchpoint: classify control point features
> Control point generators
> Hugin doesn't yet ship with a 'Patent Free' control point generator. > So you either need to pick control points manually - Not as > difficult as it sounds - or install and configure one of the > following control-point generators as 'plug-ins', in no particular > order:
> Upgrading from previous versions of hugin should be seamless. If you > do have problems with old settings, these can be reset in the > Preferences by clicking 'Load defaults'.
> See the the README and INSTALL_cmake files for more information.
> Thanks to all the contributors to this release and members of the > ptx mailing list, too many to mention here.
Big big thanks. I had written a long, moving post about how much Hugin
has evolved etc. but my sucky internet connection eated it. Short
version, thanks to everyone involved, Hugin rocks big time. Waiting
for the binaries/packages/installers to spread the words to the less
techie friends :)
On Oct 5, 1:34 am, Bruno Postle <br...@postle.net> wrote:
> Congratulations to everyone responsible for this release!
> Changes since 0.6.1
> Hugin has changed enormously in the two years since the 0.6.1
> release, hardly any part of the code has remained untouched. There
> have been many many bug-fixes, improvements to the interface and
> lots of new features - Here are just some of them:
> Online help
> Hugin now has comprehensive help documentation for the entire user
> interface, the manual now includes glossary items explaining many
> panorama stitching and related photography concepts.
> Languages
> New translations include Slovak, Korean, Bulgarian and Spanish. This
> means that hugin is now usable with a total of twenty languages.
> New Assistant panel
> Creating simple panoramas is much easier, hugin now starts showing
> an Assistant with a simple 1-2-3 approach for loading images,
> aligning and creating the final output.
> The Assistant will estimate lens and camera parameters, then pick a
> suitable output projection and size, advanced options are still
> available for manual adjustment.
> Photometric model
> Previous versions of hugin and panotools had basic support for
> correcting vignetting and exposure differences between photos.
> This has been completely overhauled, hugin now internally uses the
> EMoR model for representing exposure photometrically. This means
> that the camera response curve, vignetting, colour balance and
> exposure can now be optimised in much the same way as geometrical
> properties such as position and lens distortion.
> The result is that blending between photos is better than ever
> before.
> HDR
> Previously hugin supported High Dynamic Range imaging solely by
> allowing stitching of HDR floating-point TIFF photos - These images
> themselves had to be created in another tool.
> Now, thanks to the internal photometric model, hugin can now create
> HDR output from normal exposure bracketed photos. The photos don't
> have to be perfectly-aligned, they don't even need to be
> nearly-aligned or have consistent exposure differences - The hugin
> optimiser will sort all this stuff out, and the stitcher will create
> OpenEXR or TIFF HDR output files for later tonemapping or use as
> lightprobes.
> Exposure blending
> HDR and tonemapping isn't for everybody, enfuse introduced exposure
> blending to the world, and hugin supports aligning and fusing
> bracketed stacks of photos, perfectly, all as part of the stitching
> process.
> So now with hugin-0.7.0 and enblend-3.2 you can create realistic,
> photographic panoramas that have no over-exposed or under-exposed
> areas.
> Makefile stitching
> hugin-0.7.0 introduces a new stitching back-end: previously the
> various stitching tools were executed directly by the GUI, now all
> the commands required to generate the output are written to a
> Makefile which is then processed independently of hugin itself.
> Aside from easier debugging and customisation; this background
> stitching allows you to get on with creating a new project while
> waiting for the previous job to finish - Stitching can also be
> deferred or shifted to another machine, even 'headless' servers can
> now be used.
> Projections
> Hugin has always had the ability to save panoramas using simulated
> normal and fisheye lenses, or 360 degree cylindrical and spherical
> projections.
> Now a whole series of alternative cartographic mappings are
> available, of particular interest are the 'conformal' stereographic
> and Mercator projections which can be used to show extremely large
> angles of view with no local distortion.
> Project templates
> Hugin project files can now be used as templates for new panorama
> projects. This is useful if you take a lot of panoramas with exactly
> the same camera positions.
> Other improvements
> There's a whole lot of other new stuff in this release: numbering in
> the control-point editor, straight-line control-points, numeric
> transform, clicking to rotate the preview, a straighten button,
> cropping of the output and probably more.
> Command-line tools
> This release provides new command-line tools:
> * align_image_stack: align a nearly-aligned stack of photos
> * pto2mk: create a stitching Makefile from a pto project
> * vig_optimise: optimise photometric parameters
> * tca_correct: calculate lens chromatic aberration
> * hugin_hdrmerge: assemble a bracketed stack to HDR
> * matchpoint: classify control point features
> Control point generators
> Hugin doesn't yet ship with a 'Patent Free' control point generator.
> So you either need to pick control points manually - Not as
> difficult as it sounds - or install and configure one of the
> following control-point generators as 'plug-ins', in no particular
> order:
> Upgrading from previous versions of hugin should be seamless. If you
> do have problems with old settings, these can be reset in the
> Preferences by clicking 'Load defaults'.
> See the the README and INSTALL_cmake files for more information.
> Thanks to all the contributors to this release and members of the
> ptx mailing list, too many to mention here.
Am Sunday, October 05, 2008 um 0:34 schrieb Bruno Postle:
> Binary releases are expected to follow in the next few days.
I'd be very grateful if there where some. Best available from one place - preferable the sourceforge download page. As soon as there are binaries please announce on PanotoolsNG and other locations as well!
Many thanks for the great work!
best regards -- Erik Krause Offenburger Str. 33 79108 Freiburg
On Mon 06-Oct-2008 at 00:01 +0200, Erik Krause wrote:
>Am Sunday, October 05, 2008 um 0:34 schrieb Bruno Postle:
>> Binary releases are expected to follow in the next few days.
>I'd be very grateful if there where some. Best available from one >place - preferable the sourceforge download page. As soon as there >are binaries please announce on PanotoolsNG and other locations as >well!
Yes, will do.
I expect to see an OS X .dmg soon, but for Windows somebody (not me) needs to create an installer - See Yuval's email, subject: "Misc release stuff".
congratulations to everybody who has contributed to the 0.7.0 release.
Bruno Postle wrote: > for Windows somebody (not me) > needs to create an installer - See Yuval's email, subject: "Misc > release stuff".
to repeat again: the instructions and the code for the installer are in SVN. I'll be happy to coach whoever steps in. If nobody steps in I infer that the need is not important enough.
As far as I am concerned, my need is to progres on 0.7.1.
- I have updated the Windows SDK to build gsoc2008_integration branch. It will be published when the gsoc2008_integration branch will become the new trunk. - for this, the gsoc2008_integration branch need first be updated with the fixes that have gone into trunk since branching - Tim is working to solve a bug with OSX before integrating Celeste into gsoc2008_integration - IMO it is too early for Fahim's and Onur's projects, so once Tim has integrated Celeste I propose that we release the gsoc_integration branch as 0.7.1 beta 1. It would be neat if we can pull this together as a Christmas present.
an area that IMO is very important and requires attention is *documentation* of the code. We need a similar effort like the one we did last year with the documentation of the build, so that future contributors (e.g. participants to the next Summer of Code) can get quickly into the code. Something like a top down approach, from a simple description of the repository and its different folders, down to a file level and a class level, with and with the architetural decisions documented as well.
I just built the final 0.7.0 but I receive a "non-fatal" exiftool error in the end (maker notes not recognised) for some sets of images. for other sets it works OK even though none of the sets do contain maker notes (beats me). I will investigate that one before release. As it is a "non-fatal" error (exif-info for generated image not updated) I might still release it if I can't solve it (which I probably can't)
> On Mon 06-Oct-2008 at 00:01 +0200, Erik Krause wrote: > >Am Sunday, October 05, 2008 um 0:34 schrieb Bruno Postle:
> >> Binary releases are expected to follow in the next few days.
> >I'd be very grateful if there where some. Best available from one > >place - preferable the sourceforge download page. As soon as there > >are binaries please announce on PanotoolsNG and other locations as > >well!
> Yes, will do.
> I expect to see an OS X .dmg soon, but for Windows somebody (not me) > needs to create an installer - See Yuval's email, subject: "Misc > release stuff".
> On Mon 06-Oct-2008 at 00:01 +0200, Erik Krause wrote: >> Am Sunday, October 05, 2008 um 0:34 schrieb Bruno Postle:
>>> Binary releases are expected to follow in the next few days.
>> I'd be very grateful if there where some. Best available from one >> place - preferable the sourceforge download page. As soon as there >> are binaries please announce on PanotoolsNG and other locations as >> well!
> Yes, will do.
> I expect to see an OS X .dmg soon, but for Windows somebody (not me) > needs to create an installer - See Yuval's email, subject: "Misc > release stuff".
Mac binary is up. Please note the autopano-sift-c plugin is also recompiled with a patch to handle spaces in path. Please install it again.
>However each time there has been an error message at the end saying >that "There has been a stitching error - please report the whole >text" (at least I THINK that is what it said I have sent it away now.
>I have the text in case it is needed ... but I suspect that there has >NOT been an error really and that the pop-up is a false alarm.
I got the non-fatal error for the exif-tool as mentioned in this thread. I think George got the same error. Shouldn't we investigate that one before putting a binary up? One day more or less doesn't matter and I prefer to put a good binary up otherwise many users might complain that the 0.7.0 still contains an error. Especially new users might turn away when they encounter such an error which might even result in "bad press (reviews)" for Hugin on the web.
> On 2008-10-06, at 07:29, Bruno Postle wrote: > > On Mon 06-Oct-2008 at 00:01 +0200, Erik Krause wrote: > >> Am Sunday, October 05, 2008 um 0:34 schrieb Bruno Postle:
> >>> Binary releases are expected to follow in the next few days.
> >> I'd be very grateful if there where some. Best available from one > >> place - preferable the sourceforge download page. As soon as there > >> are binaries please announce on PanotoolsNG and other locations as > >> well!
> > Yes, will do.
> > I expect to see an OS X .dmg soon, but for Windows somebody (not me) > > needs to create an installer - See Yuval's email, subject: "Misc > > release stuff".
> Mac binary is up. > Please note the autopano-sift-c plugin is also recompiled with a patch > to handle spaces in path. Please install it again.
One way to deal with exiftool problems is to not use exiftool.
Some time ago I put a patch on the hugin tracker that makes running
exiftool an option in the preferences tab. I was told I couldn't
commit because it would introduce a UI label needing translation, and
there was a pre-release "translation freeze" in effect. So it has
only been tested on Win32, but as it works just like several other
options I would expect no platform dependence.
I suppose applying that patch to 0.7.0 would be violating some other
release regulation; but I am going to do it for my personal builds
(both Windows and Linux) because I have little use or admiration for
exiftool.
You might want to do the same.
Regards, Tom.
On Oct 6, 10:42 am, "Harry van der Wolf" <hvdw...@gmail.com> wrote:
> >However each time there has been an error message at the end saying
> >that "There has been a stitching error - please report the whole
> >text" (at least I THINK that is what it said I have sent it away now.
> >I have the text in case it is needed ... but I suspect that there has
> >NOT been an error really and that the pop-up is a false alarm.
> I got the non-fatal error for the exif-tool as mentioned in this thread. I
> think George got the same error. Shouldn't we investigate that one before
> putting a binary up? One day more or less doesn't matter and I prefer to put
> a good binary up otherwise many users might complain that the 0.7.0 still
> contains an error. Especially new users might turn away when they encounter
> such an error which might even result in "bad press (reviews)" for Hugin on
> the web.
> > On 2008-10-06, at 07:29, Bruno Postle wrote:
> > > On Mon 06-Oct-2008 at 00:01 +0200, Erik Krause wrote:
> > >> Am Sunday, October 05, 2008 um 0:34 schrieb Bruno Postle:
> > >>> Binary releases are expected to follow in the next few days.
> > >> I'd be very grateful if there where some. Best available from one
> > >> place - preferable the sourceforge download page. As soon as there
> > >> are binaries please announce on PanotoolsNG and other locations as
> > >> well!
> > > Yes, will do.
> > > I expect to see an OS X .dmg soon, but for Windows somebody (not me)
> > > needs to create an installer - See Yuval's email, subject: "Misc
> > > release stuff".
> > Mac binary is up.
> > Please note the autopano-sift-c plugin is also recompiled with a patch
> > to handle spaces in path. Please install it again.
On Sun 05-Oct-2008 at 23:36 -0400, Yuval Levy wrote:
>- IMO it is too early for Fahim's and Onur's projects, so once Tim has >integrated Celeste I propose that we release the gsoc_integration branch >as 0.7.1 beta 1. It would be neat if we can pull this together as a >Christmas present.
Fourteen months should be plenty of time...
My only comment is that 0.7.x is what we call the bugfix release when 0.7.0 has problems, so the gsoc feature release is 0.8.0.
On Mon, Oct 6, 2008 at 3:49 PM, Bruno Postle <br...@postle.net> wrote:
> On Sun 05-Oct-2008 at 23:36 -0400, Yuval Levy wrote:
> >- IMO it is too early for Fahim's and Onur's projects, so once Tim has > >integrated Celeste I propose that we release the gsoc_integration branch > >as 0.7.1 beta 1. It would be neat if we can pull this together as a > >Christmas present.
> Fourteen months should be plenty of time...
> My only comment is that 0.7.x is what we call the bugfix release > when 0.7.0 has problems, so the gsoc feature release is 0.8.0.
> -- > Bruno
Bruno,
If you plan on making a 0.7.1 release that is primarily bug fixes, would a branch at this point make sense? This would allow developers to start making other changes to the trunk. I have been working on a bracketed exposure interface and was waiting on the 0.7.0 release before posting it. I agree the gsoc integration should be 0.8.0 as well.
> >However each time there has been an error message at the end saying
> >that "There has been a stitching error - please report the whole
> >text" (at least I THINK that is what it said I have sent it away now.
> >I have the text in case it is needed ... but I suspect that there has
> >NOT been an error really and that the pop-up is a false alarm.
> I got the non-fatal error for the exif-tool as mentioned in this
> thread. I think George got the same error. Shouldn't we investigate
> that one before putting a binary up? One day more or less doesn't
> matter and I prefer to put a good binary up otherwise many users
> might complain that the 0.7.0 still contains an error. Especially
> new users might turn away when they encounter such an error which
> might even result in "bad press (reviews)" for Hugin on the web.
I thought George's report was on a separate bug where wx execute hack
on PPC affecting even the case that doesn't need the hack hence
leading to the error. The real question is whether ExifTool's minor
error actually leads to displaying the error message on Hugin even on
Intel. If so, that's something we should look at. Otherwise, it's just
a limitation of ExifTool to me.
As to the 'press', quality assurance-wise I actually have a very low
expectation from 0.7.0 anyway. Let alone problematic wxMac, as I have
made it clear when we started to use makefile for stitching, use of
multiple executables can easily become a nightmare. Having separate
command line executables may be easier to get something working in
first instance (and certainly is preferred way by Linux users), but it
is hard to make sure it works for 'all' users. Unexpected errors are
thrown out from components (command line programs) that normal users
are not expected to touch, and there are inter-process interactions
that is much harder to debug. If one programmed those components in a
good style having modularity in mind, using that components through
API should be as easy as calling those as external executables. I
still remember the time and effort trying to get old PTOptimiser
executable work from Hugin; we ended up using the functionality
directly from libpano after all. I'm quite happy that 0.7.0 finally
works for 'most' Mac users now, and I know from the past that quality
assurance beyond this point will be an inefficient process that I'm
not willing to afford much time.
> On 2008-10-06, at 07:29, Bruno Postle wrote:
> > On Mon 06-Oct-2008 at 00:01 +0200, Erik Krause wrote:
> >> Am Sunday, October 05, 2008 um 0:34 schrieb Bruno Postle:
> >>> Binary releases are expected to follow in the next few days.
> >> I'd be very grateful if there where some. Best available from one
> >> place - preferable the sourceforge download page. As soon as there
> >> are binaries please announce on PanotoolsNG and other locations as
> >> well!
> > Yes, will do.
> > I expect to see an OS X .dmg soon, but for Windows somebody (not me)
> > needs to create an installer - See Yuval's email, subject: "Misc
> > release stuff".
> Mac binary is up.
> Please note the autopano-sift-c plugin is also recompiled with a patch
> to handle spaces in path. Please install it again.
Bruno Postle wrote: > Congratulations to everyone responsible for this release!
Thanks a lot for doing the final hard work for making the release possible. Also thanks to all other developers who made this happen. I have been very busy with day time work and other commitments lately, so I didn't have the time to really contribute to hugins development lately.
As for the further development, I agree with Garry that we should do an svn cp hutin/trunk hugin/branches/release-0.7.0 to create a stable branch, which could be used for urgent bugfixes, should the need occur.
We could then merge the gsoc_integration branch into the trunk and contine developing the new functionality for the 0.8 release.
On Tue, Oct 7, 2008 at 1:54 PM, Pablo d'Angelo <pablo.dang...@web.de> wrote:
> We could then merge the gsoc_integration branch into the trunk and > contine developing the new functionality for the 0.8 release.
> Any objections?
> ciao > Pablo
Hi all,
I haven't been watching the GSOC integration branch very much. Have all of the projects been merged in? At one point I thought the plan was to merge all of the projects into a single branch, get everything (or most everything) working then merge it wholesale into the trunk. It does not matter much to me if the GSOC projects are brought now or when the integration branch is finished. I just don't want to lose track of where the up to date changes are.
Gerry Patterson wrote: > On Tue, Oct 7, 2008 at 1:54 PM, Pablo d'Angelo <pablo.dang...@web.de > <mailto:pablo.dang...@web.de>> wrote:
> We could then merge the gsoc_integration branch into the trunk and > contine developing the new functionality for the 0.8 release.
> Any objections?
> ciao > Pablo
> Hi all,
> I haven't been watching the GSOC integration branch very much. Have all > of the projects been merged in?
No, only the OpenGL preview and the batch stitching functionality is in the GSOC integration branch.
> At one point I thought the plan was to > merge all of the projects into a single branch, get everything (or most > everything) working then merge it wholesale into the trunk.
The most important reason was that integration could start while the last changes for the 0.7 release were made. Having all projects in there before the next release series 0.8 would be one possibility, but I fear it would introduce some delays.
> It does not
> matter much to me if the GSOC projects are brought now or when the > integration branch is finished. I just don't want to lose track of > where the up to date changes are.
To avoid delays and expose the new functionality earlier, I'd favor an early merge of the gsoc integration branch into the trunk. Once the remaining projects are ready for a merge, they can be merged into the trunk directly.
On Tue 07-Oct-2008 at 20:54 +0200, Pablo d'Angelo wrote:
>As for the further development, I agree with Garry that we should do an >svn cp hutin/trunk hugin/branches/release-0.7.0 >to create a stable branch, which could be used for urgent bugfixes, >should the need occur.
Ok, done based on rc6/final. I didn't copy the trunk as there have been some (minor) changes to the trunk since the rc6/final release.
>We could then merge the gsoc_integration branch into the trunk and >contine developing the new functionality for the 0.8 release.
Makes sense to me, who wants to do this? Probably there will be some conflicts.
Tom Sharpless wrote: > One way to deal with exiftool problems is to not use exiftool.
> Some time ago I put a patch on the hugin tracker that makes running > exiftool an option in the preferences tab. I was told I couldn't > commit because it would introduce a UI label needing translation, and > there was a pre-release "translation freeze" in effect. So it has > only been tested on Win32, but as it works just like several other > options I would expect no platform dependence.
> I suppose applying that patch to 0.7.0 would be violating some other > release regulation; but I am going to do it for my personal builds > (both Windows and Linux) because I have little use or admiration for > exiftool.
now that 0.7.0 is released, trunk is in a state of flux again. I'd say: go ahead and commit the patch.
also for the future I would suggest branching out release branches (like has been done now with release-0.7.0) rather than freezing trunk. Trunk should live on.
Bruno Postle wrote: > On Tue 07-Oct-2008 at 20:54 +0200, Pablo d'Angelo wrote: >> We could then merge the gsoc_integration branch into the trunk and >> contine developing the new functionality for the 0.8 release.
> Makes sense to me, who wants to do this? Probably there will be > some conflicts.
done (on my local machine for now - I am testing the build before committing).
there was only one file with a conflict, an xrc file (sorry I no longer recall which, but if it is important I'll grab that piece of information).
will commit later if the build does not return strange things.
Pablo d'Angelo wrote: > > It does not >> matter much to me if the GSOC projects are brought now or when the >> integration branch is finished. I just don't want to lose track of >> where the up to date changes are.
> To avoid delays and expose the new functionality earlier, I'd favor an > early merge of the gsoc integration branch into the trunk. Once the > remaining projects are ready for a merge, they can be merged into the > trunk directly.
each project's circumstances are unique, waiting for all of them to be ready for a big bang is IMO not very sensible.
let's release every time a bunch of features becomes somewhat usable / integrated so to get more user feedback on the way to robustness.
specifically, the fast preview and the batch processor have already been integrated in gsoc2008_integration, and will go into 0.8.0alpha1 if nobody disagrees.
Celeste is next in line. Tim has been working hard hard lately with help from Harry, trying to fix a weird behavior in OSX GUI.
for the last two projects I have not seen much from Fahim and Onur after GSoC ended. The circumstances are different too.
Fahim / Masking in GUI: we need to think how it will fit in the overall hugin process, while Fahim's project still need some fine tuning too according to him.
Onur / Feature Matching is a quite complex project. the parts need to be pulled together with Zoran's last year project. still a lot of work before anything can be integrated.
now that we have a release, I would like to express my sincere thanks to Pablo and the team for making it all possible. Hugin is an integral part of my photography now; I couldn't do without it.
As my contribution, I have now published a sequence of articles in a Royal Photographic Society (UK) magazine to spread the word about hugin locally; and I think that it is getting out amongst the UK photographers.
> Gerry Patterson wrote: > > On Tue, Oct 7, 2008 at 1:54 PM, Pablo d'Angelo <pablo.dang...@web.de > > <mailto:pablo.dang...@web.de>> wrote:
> > We could then merge the gsoc_integration branch into the trunk and > > contine developing the new functionality for the 0.8 release.
> > Any objections?
> > ciao > > Pablo
> > Hi all,
> > I haven't been watching the GSOC integration branch very much. Have all > > of the projects been merged in?
> No, only the OpenGL preview and the batch stitching functionality is in > the GSOC integration branch.
> > At one point I thought the plan was to > > merge all of the projects into a single branch, get everything (or most > > everything) working then merge it wholesale into the trunk.
> The most important reason was that integration could start while the > last changes for the 0.7 release were made. Having all projects in there > before the next release series 0.8 would be one possibility, but I fear > it would introduce some delays.
> > It does not > > matter much to me if the GSOC projects are brought now or when the > > integration branch is finished. I just don't want to lose track of > > where the up to date changes are.
> To avoid delays and expose the new functionality earlier, I'd favor an > early merge of the gsoc integration branch into the trunk. Once the > remaining projects are ready for a merge, they can be merged into the > trunk directly.
I installed it on my PowerMac G5 machine.
I also installed your new Autopano-SIFT-C plug-in replacing the
previous one in "Application Support"
I opened a recent project and tried using Autopano-SIFT-C to generate
a few control points ... the plugin selection dialogue was as expected
and then the running commentary seemed to go as usual but at the end
a pop-up appeared saying:
weExecute Error
Could not execute command /.../Application Support/Hiugin/
Autopano=SIFT-C 2.5.huginAutoCP/Contents/macOS/autopano-sift-c --
maxmatches 3 /private/var/tmp/folders.501/TemporaryItems/ap_resJOqSkP /
private/var/tmp/folders.501/TemporaryItems/ap_inprojrLDkvr
I tried the same task in the same project using an older version
(SVN-3390) and - even with the new Autopano-SIFT plug-in still in
place - it ran normally and generated the control points as
requested.
I am not sure whether this tells you anything you didn't already know.
all the best
George
On Oct 7, 3:22 am, Ippei UKAI <ippei_u...@mac.com> wrote:
> On 2008-10-06, at 23:42, Harry van der Wolf wrote:
> > Ippei,
> > for the RC6 George Row mentioned:
> > >However each time there has been an error message at the end saying
> > >that "There has been a stitching error - please report the whole
> > >text" (at least I THINK that is what it said I have sent it away now.
> > >I have the text in case it is needed ... but I suspect that there has
> > >NOT been an error really and that the pop-up is a false alarm.
> > I got the non-fatal error for the exif-tool as mentioned in this
> > thread. I think George got the same error. Shouldn't we investigate
> > that one before putting a binary up? One day more or less doesn't
> > matter and I prefer to put a good binary up otherwise many users
> > might complain that the 0.7.0 still contains an error. Especially
> > new users might turn away when they encounter such an error which
> > might even result in "bad press (reviews)" for Hugin on the web.
> I thought George's report was on a separate bug where wx execute hack
> on PPC affecting even the case that doesn't need the hack hence
> leading to the error. The real question is whether ExifTool's minor
> error actually leads to displaying the error message on Hugin even on
> Intel. If so, that's something we should look at. Otherwise, it's just
> a limitation of ExifTool to me.
> As to the 'press', quality assurance-wise I actually have a very low
> expectation from 0.7.0 anyway. Let alone problematic wxMac, as I have
> made it clear when we started to use makefile for stitching, use of
> multiple executables can easily become a nightmare. Having separate
> command line executables may be easier to get something working in
> first instance (and certainly is preferred way by Linux users), but it
> is hard to make sure it works for 'all' users. Unexpected errors are
> thrown out from components (command line programs) that normal users
> are not expected to touch, and there are inter-process interactions
> that is much harder to debug. If one programmed those components in a
> good style having modularity in mind, using that components through
> API should be as easy as calling those as external executables. I
> still remember the time and effort trying to get old PTOptimiser
> executable work from Hugin; we ended up using the functionality
> directly from libpano after all. I'm quite happy that 0.7.0 finally
> works for 'most' Mac users now, and I know from the past that quality
> assurance beyond this point will be an inefficient process that I'm
> not willing to afford much time.
> > On 2008-10-06, at 07:29, Bruno Postle wrote:
> > > On Mon 06-Oct-2008 at 00:01 +0200, Erik Krause wrote:
> > >> Am Sunday, October 05, 2008 um 0:34 schrieb Bruno Postle:
> > >>> Binary releases are expected to follow in the next few days.
> > >> I'd be very grateful if there where some. Best available from one
> > >> place - preferable the sourceforge download page. As soon as there
> > >> are binaries please announce on PanotoolsNG and other locations as
> > >> well!
> > > Yes, will do.
> > > I expect to see an OS X .dmg soon, but for Windows somebody (not me)
> > > needs to create an installer - See Yuval's email, subject: "Misc
> > > release stuff".
> > Mac binary is up.
> > Please note the autopano-sift-c plugin is also recompiled with a patch
> > to handle spaces in path. Please install it again.
PS having generated control points with an earlier version of Hugin I
was able to save the project file and then open it in the current,
released version. It then performed a stitch as expected producing a
resulting file that I was happy with. However ... it ended the
stitching process with a pop-up that said:
Error during Stitching
Error during Stitching
Please report the complere text to the bug tracker on http://sf.net/projects/hugin.
all the best
George
On Oct 8, 3:06 pm, grow <George...@gmail.com> wrote:
> I installed it on my PowerMac G5 machine.
> I also installed your new Autopano-SIFT-C plug-in replacing the
> previous one in "Application Support"
> I opened a recent project and tried using Autopano-SIFT-C to generate
> a few control points ... the plugin selection dialogue was as expected
> and then the running commentary seemed to go as usual but at the end
> a pop-up appeared saying:
> weExecute Error
> Could not execute command /.../Application Support/Hiugin/
> Autopano=SIFT-C 2.5.huginAutoCP/Contents/macOS/autopano-sift-c --
> maxmatches 3 /private/var/tmp/folders.501/TemporaryItems/ap_resJOqSkP /
> private/var/tmp/folders.501/TemporaryItems/ap_inprojrLDkvr
> I tried the same task in the same project using an older version
> (SVN-3390) and - even with the new Autopano-SIFT plug-in still in
> place - it ran normally and generated the control points as
> requested.
> I am not sure whether this tells you anything you didn't already know.
> all the best
> George
> On Oct 7, 3:22 am, Ippei UKAI <ippei_u...@mac.com> wrote:
> > On 2008-10-06, at 23:42, Harry van der Wolf wrote:
> > > Ippei,
> > > for the RC6 George Row mentioned:
> > > >However each time there has been an error message at the end saying
> > > >that "There has been a stitching error - please report the whole
> > > >text" (at least I THINK that is what it said I have sent it away now.
> > > >I have the text in case it is needed ... but I suspect that there has
> > > >NOT been an error really and that the pop-up is a false alarm.
> > > I got the non-fatal error for the exif-tool as mentioned in this
> > > thread. I think George got the same error. Shouldn't we investigate
> > > that one before putting a binary up? One day more or less doesn't
> > > matter and I prefer to put a good binary up otherwise many users
> > > might complain that the 0.7.0 still contains an error. Especially
> > > new users might turn away when they encounter such an error which
> > > might even result in "bad press (reviews)" for Hugin on the web.
> > I thought George's report was on a separate bug where wx execute hack
> > on PPC affecting even the case that doesn't need the hack hence
> > leading to the error. The real question is whether ExifTool's minor
> > error actually leads to displaying the error message on Hugin even on
> > Intel. If so, that's something we should look at. Otherwise, it's just
> > a limitation of ExifTool to me.
> > As to the 'press', quality assurance-wise I actually have a very low
> > expectation from 0.7.0 anyway. Let alone problematic wxMac, as I have
> > made it clear when we started to use makefile for stitching, use of
> > multiple executables can easily become a nightmare. Having separate
> > command line executables may be easier to get something working in
> > first instance (and certainly is preferred way by Linux users), but it
> > is hard to make sure it works for 'all' users. Unexpected errors are
> > thrown out from components (command line programs) that normal users
> > are not expected to touch, and there are inter-process interactions
> > that is much harder to debug. If one programmed those components in a
> > good style having modularity in mind, using that components through
> > API should be as easy as calling those as external executables. I
> > still remember the time and effort trying to get old PTOptimiser
> > executable work from Hugin; we ended up using the functionality
> > directly from libpano after all. I'm quite happy that 0.7.0 finally
> > works for 'most' Mac users now, and I know from the past that quality
> > assurance beyond this point will be an inefficient process that I'm
> > not willing to afford much time.
> > > On 2008-10-06, at 07:29, Bruno Postle wrote:
> > > > On Mon 06-Oct-2008 at 00:01 +0200, Erik Krause wrote:
> > > >> Am Sunday, October 05, 2008 um 0:34 schrieb Bruno Postle:
> > > >>> Binary releases are expected to follow in the next few days.
> > > >> I'd be very grateful if there where some. Best available from one
> > > >> place - preferable the sourceforge download page. As soon as there
> > > >> are binaries please announce on PanotoolsNG and other locations as
> > > >> well!
> > > > Yes, will do.
> > > > I expect to see an OS X .dmg soon, but for Windows somebody (not me)
> > > > needs to create an installer - See Yuval's email, subject: "Misc
> > > > release stuff".
> > > Mac binary is up.
> > > Please note the autopano-sift-c plugin is also recompiled with a patch
> > > to handle spaces in path. Please install it again.
> Am Sunday, October 05, 2008 um 0:34 schrieb Bruno Postle:
> > Binary releases are expected to follow in the next few days.
> I'd be very grateful if there where some. Best available from one
> place - preferable the sourceforge download page. As soon as there
> are binaries please announce on PanotoolsNG and other locations as
> well!
> Many thanks for the great work!
> best regards
> --
> Erik Krause
> Offenburger Str. 33
> 79108 Freiburg
Sorry for replying this late. I hoped Ippei would pick it up and than I forgot about it.
This final error you mention is most probably a "non-fatal" error by Exiftool. I reported on 6 October: *"I just built the final 0.7.0 but I receive a "non-fatal" exiftool error in the end (maker notes not recognised) for some sets of images. for other sets it works OK even though none of the sets do contain maker notes (beats me). I will investigate that one before release. As it is a "non-fatal" error (exif-info for generated image not updated) I might still release it if I can't solve it (which I probably can't)"*
I suppose that if you look at the error a bit more in detail (the window stays open anyway), that it might be the same or one alike for Exiftool.
I have been experimenting with sips lately (for my ImageFuser). sips is the comand line version of "Image Events" on Apple. It can do 90% of what Exiftool can and is standard available on every Mac (>10.2).
Just like Tom Sharpless mentions: it might be wise to get rid of Exiftool, even though as such it is a great cross-platform tool.
Getting back to your Autpano-sift-C issue: The command line mentions: /.../Application Support/Hiugin/Autopano=SIFT-C 2.5.huginAutoCP/Contents/macOS/autopano-sift-c --maxmatches 3
It says: "port/Hiugin/Auto" <-- Hiugin??? It also says: "ano=SIFT" <-- Did you copy&paste this or did you type it over? and also says: "--maxmatches 3" <-- maxmatches is not given to the plugin, so it should stick to the default which is 25. This is another weird issue.
I can't find the "Hiugin" in my source code. (This is also why I hoped Ippei would react).
> PS having generated control points with an earlier version of Hugin I > was able to save the project file and then open it in the current, > released version. It then performed a stitch as expected producing a > resulting file that I was happy with. However ... it ended the > stitching process with a pop-up that said:
> Error during Stitching > Error during Stitching > Please report the complere text to the bug tracker on > http://sf.net/projects/hugin.
> all the best
> George
> On Oct 8, 3:06 pm, grow <George...@gmail.com> wrote: > > Ippei, Harry,
> > I have just tried Ippei's new release.
> > I installed it on my PowerMac G5 machine. > > I also installed your new Autopano-SIFT-C plug-in replacing the > > previous one in "Application Support"
> > I opened a recent project and tried using Autopano-SIFT-C to generate > > a few control points ... the plugin selection dialogue was as expected > > and then the running commentary seemed to go as usual but at the end > > a pop-up appeared saying: > > weExecute Error > > Could not execute command /.../Application Support/Hiugin/ > > Autopano=SIFT-C 2.5.huginAutoCP/Contents/macOS/autopano-sift-c -- > > maxmatches 3 /private/var/tmp/folders.501/TemporaryItems/ap_resJOqSkP / > > private/var/tmp/folders.501/TemporaryItems/ap_inprojrLDkvr
> > I tried the same task in the same project using an older version > > (SVN-3390) and - even with the new Autopano-SIFT plug-in still in > > place - it ran normally and generated the control points as > > requested.
> > I am not sure whether this tells you anything you didn't already know.
> > all the best
> > George
> > On Oct 7, 3:22 am, Ippei UKAI <ippei_u...@mac.com> wrote:
> > > On 2008-10-06, at 23:42, Harry van der Wolf wrote:
> > > > Ippei,
> > > > for the RC6 George Row mentioned:
> > > > >However each time there has been an error message at the end saying > > > > >that "There has been a stitching error - please report the whole > > > > >text" (at least I THINK that is what it said I have sent it away > now.
> > > > >I have the text in case it is needed ... but I suspect that there > has > > > > >NOT been an error really and that the pop-up is a false alarm.
> > > > I got the non-fatal error for the exif-tool as mentioned in this > > > > thread. I think George got the same error. Shouldn't we investigate > > > > that one before putting a binary up? One day more or less doesn't > > > > matter and I prefer to put a good binary up otherwise many users > > > > might complain that the 0.7.0 still contains an error. Especially > > > > new users might turn away when they encounter such an error which > > > > might even result in "bad press (reviews)" for Hugin on the web.
> > > I thought George's report was on a separate bug where wx execute hack > > > on PPC affecting even the case that doesn't need the hack hence > > > leading to the error. The real question is whether ExifTool's minor > > > error actually leads to displaying the error message on Hugin even on > > > Intel. If so, that's something we should look at. Otherwise, it's just > > > a limitation of ExifTool to me.
> > > As to the 'press', quality assurance-wise I actually have a very low > > > expectation from 0.7.0 anyway. Let alone problematic wxMac, as I have > > > made it clear when we started to use makefile for stitching, use of > > > multiple executables can easily become a nightmare. Having separate > > > command line executables may be easier to get something working in > > > first instance (and certainly is preferred way by Linux users), but it > > > is hard to make sure it works for 'all' users. Unexpected errors are > > > thrown out from components (command line programs) that normal users > > > are not expected to touch, and there are inter-process interactions > > > that is much harder to debug. If one programmed those components in a > > > good style having modularity in mind, using that components through > > > API should be as easy as calling those as external executables. I > > > still remember the time and effort trying to get old PTOptimiser > > > executable work from Hugin; we ended up using the functionality > > > directly from libpano after all. I'm quite happy that 0.7.0 finally > > > works for 'most' Mac users now, and I know from the past that quality > > > assurance beyond this point will be an inefficient process that I'm > > > not willing to afford much time.
> > > > On 2008-10-06, at 07:29, Bruno Postle wrote: > > > > > On Mon 06-Oct-2008 at 00:01 +0200, Erik Krause wrote: > > > > >> Am Sunday, October 05, 2008 um 0:34 schrieb Bruno Postle:
> > > > >>> Binary releases are expected to follow in the next few days.
> > > > >> I'd be very grateful if there where some. Best available from one > > > > >> place - preferable the sourceforge download page. As soon as there > > > > >> are binaries please announce on PanotoolsNG and other locations as > > > > >> well!
> > > > > Yes, will do.
> > > > > I expect to see an OS X .dmg soon, but for Windows somebody (not > me) > > > > > needs to create an installer - See Yuval's email, subject: "Misc > > > > > release stuff".
> > > > Mac binary is up. > > > > Please note the autopano-sift-c plugin is also recompiled with a > patch > > > > to handle spaces in path. Please install it again.
|
