Loading ...
Sorry, an error occurred while loading the content.

hugin 0.6 - amazing!

Expand Messages
  • yuval_levy
    Hi all I have not had a look at hugin for over a year and this 0.6 version is just amazing. It installs easily (I have tested the Windows installer, after
    Message 1 of 13 , Jul 25, 2006
    • 0 Attachment
      Hi all

      I have not had a look at hugin for over a year and this 0.6 version is
      just amazing. It installs easily (I have tested the Windows installer,
      after wasting a few days trying to compile 0.5 from source to no
      avail) and shows a few very promising concepts.

      It still relies on external applications (autopano or autopano-sift)
      to identify control points - and the manual identification of control
      points has a somewhat slow response as it zooms the 8mpx TIFFs, but
      then the optimizer is fast and has very sensible pre-selected set of
      parameters to optimize.

      hugin processed very well my six input images (Sigma 8mm on a Canon
      350D) and was able to deal with my tilted camera position.

      it is not yet as efficient to work with as PTgui, but the advances are
      very promising and it is definitely a very valid alternative for those
      on a tight budget or those who want to run a native
      MacOSX/Linux/FreeBSD stitcher.

      Kudos, Pablo, Bruno et al.
      <http://hugin.sourceforge.net/>

      Yuv
    • JD Smith
      ... Hi Yuv: Since most of us Hugin users do not use PTGui, I wonder if you could go into more detail on where the inefficiencies are? Some are obvious, but
      Message 2 of 13 , Jul 31, 2006
      • 0 Attachment
        On Wed, 26 Jul 2006 05:10:39 +0000, yuval_levy wrote:

        > Hi all
        >
        > I have not had a look at hugin for over a year and this 0.6 version is
        > just amazing. It installs easily (I have tested the Windows installer,
        > after wasting a few days trying to compile 0.5 from source to no avail)
        > and shows a few very promising concepts.
        >
        > It still relies on external applications (autopano or autopano-sift) to
        > identify control points - and the manual identification of control points
        > has a somewhat slow response as it zooms the 8mpx TIFFs, but then the
        > optimizer is fast and has very sensible pre-selected set of parameters to
        > optimize.
        >
        > hugin processed very well my six input images (Sigma 8mm on a Canon 350D)
        > and was able to deal with my tilted camera position.
        >
        > it is not yet as efficient to work with as PTgui, but the advances are
        > very promising and it is definitely a very valid alternative for those on
        > a tight budget or those who want to run a native MacOSX/Linux/FreeBSD
        > stitcher.

        Hi Yuv:

        Since most of us Hugin users do not use PTGui, I wonder if you could go
        into more detail on where the inefficiencies are? Some are obvious, but
        some we probably aren't even aware of. Did you have a chance to evaluate
        the automatic vignetting and TCA corrections (unique among PanoTools
        front-ends, I believe)?

        JD
      • mike@panoclub.de
        A friend of mine bought PTGui - so we were sitting together trying Hugin and PTGui on the same panorama (6 6MP images taken with the Sigma 8mm). The main
        Message 3 of 13 , Aug 1, 2006
        • 0 Attachment
          A friend of mine bought PTGui - so we were sitting together trying Hugin and PTGui on the same panorama (6 6MP images taken with the Sigma 8mm).

          The main advantage of PTGui I have observed:
          It's dammend easy for beginners. The simple mode developed a good result just clicking a handful of buttons without knowing how panotools are 'ticking' - great!
          This is very remarkable since in the early days of hugin one of Pablo's major targets was to develop an easy to use/learn panorama frontend. I think hugin is stable, comfortable, easy to use, but it's definitevely not easy to learn.

          Things have changed a lot and meanwhile it's easier than ever to start developing panoramas. Hugin (and PTGui as well) gives you a complete package and straight from downloading and installing you can start - that's really cool.

          Hugin isn't able to detect the correct lens setting for my old Sigma 8mm MF - PTGui can. If you have a file stored with the lens setting you found once you're fine. I think Hugin will address this by using the ptlens database soon?!

          PTGui can find the right cropcircle automatically - cool! Not a big deal in Hugin (just 2 clicks), but a newbie will not know that such a function is there and what it is good for.

          Using autopano-sift/autopano within hugin is fine. Best results I get using autopano-sift without ransac check. So there are wrong controlpoints I need to filter for. Usually I optimize 2-4 times and delete the points with very large values using the controlpointlist. That are only a few clicks, but a newbie will stumble on this.

          The default optimization method of hugin is very helpful to detect wrong points and to bring the images into a general order. For good results you need to select another method (maybe "All" or "Custom"). Having not enough cp's, no verticals/horizontals or only many cp's, that are crowded around the center this can result in settings that are less good (Hugin reports that, like PTGui does). That's not an issue and due to UNDO etc. this can be easily and quickly solved. But a newbie would stumble here again. I think PTGui optimizes only y,p,r,b (and v?!) in simple mode to avoid those situations.

          Preview in hugin is fine and fast and automatically updated if needed - well done! It also show's you the influence of the vignetting tool!!!

          You can use Hugin to try finding the the correct vignetting parameters (works fine, but very slow) or easily prove your own flatfiles - cool!
          I'm thankful for the vignetting capabilities although I think this belongs into a RAW converter (for a professional workflow). But it's very useful for newbies that it is in - thanks a lot. I would like to have an additional ruler here to adjust the strenght of the correction (moving the polynom curve up and down). In practise, I think, one would correct hard vignetting not fully and let enblend/smartblend do the rest?!.

          Stitching tab is simple and fine. One bug here.
          It can happen, that calculating the optimal output size can lead to an odd pixel value for width (and therefore to an not matching value for height)!

          In the end, the result in Hugin (using my usual technique) was better (less stitching errors) than in PTGui using simple mode. Deleting one wrong controlpoint in PTGui (using the controlpoint list) and adding 2 addional points finally leaded to very similar results.

          Two intersting observations:
          We got a fieldofview of ~181 deg in PTgui and ~177 in Hugin?!
          We got a size of 5???x2??? pixel in PTGui and 6???x3??? (what we expected) in PTGui?! How can I find out what the correct optimal size is?

          My recommendations to make Hugin more newby-friendly:
          - A wizard/druid (maybe a range of wizards "Spherical with Fish", "Multirow with Rect", etc..) that triggers autopano/-sift with useful parameters, does basic optimisation and cp filtering, stable post-optimisation, comes up with a preview and shows a short report what you can do next to improve your panorama (or a button "Stitch Now?").

          - A bad-cp-filtering-by-optimisation tool would be nice as well for advanced users.

          - A basic HTML creation tab (just some fields for author, title, template, etc.) to create a folder with ptviewer, an html file (using a HTML template file), and the equirectangular image in would be a nice goodie for beginners too.

          best, mike
          ----- Original Message -----
          From: jdsmith@... <JD Smith>
          To: PanoToolsNG@yahoogroups.com
          Date: 31.07.2006 19:42:48
          Subject: [PanoToolsNG] Re: hugin 0.6 - amazing!
          > On Wed, 26 Jul 2006 05:10:39 +0000, yuval_levy wrote:
          >
          >
          > Since most of us Hugin users do not use PTGui, I wonder if you could go
          > into more detail on where the inefficiencies are? Some are obvious, but
          > some we probably aren't even aware of. Did you have a chance to evaluate
          > the automatic vignetting and TCA corrections (unique among PanoTools
          > front-ends, I believe)?
          >
          > JD
        • Yuval Levy
          Hi JD short answer - I am tight on time and on a lunch break. ... some have been addressed by Mike, see my answer to his post. some I will have to take more
          Message 4 of 13 , Aug 1, 2006
          • 0 Attachment
            Hi JD

            short answer - I am tight on time and on a lunch break.

            JD Smith wrote:
            > Since most of us Hugin users do not use PTGui, I wonder if you could go
            > into more detail on where the inefficiencies are?
            some have been addressed by Mike, see my answer to his post. some I will
            have to take more time to run the two side by side and articulate them
            better.
            > Did you have a chance to evaluate the automatic vignetting and TCA corrections ?
            >
            No and in their current incarnation they are of no interest to me. IMHO
            the best place to correct for lens aberrations, particularly for TCA, is
            when demosaicizing the RAW, before interpolation into TIFF. This is what
            Adobe RAW Converter, BibblePro and SilkyPix all do. I feed corrected
            TIFFs into my stitching tool. For such functionality to be interesting
            in a stitching tool, it would have to take RAW files as input. I have
            not searched for such a functionality in hugin. I'd rather see stitching
            tools able to process HDR files than RAW files.

            Next version?

            Yuv
          • Yuval Levy
            ... It s even better for advanced users. ... I used this mode only once and decide that it is better for me to run PTgui in semi-automatd mode. ... With the
            Message 5 of 13 , Aug 1, 2006
            • 0 Attachment
              mike@... wrote:
              > The main advantage of PTGui I have observed:
              > It's dammend easy for beginners.
              It's even better for advanced users.

              > The simple mode developed a good result just clicking a handful of buttons without knowing how panotools are 'ticking' - great!
              >
              I used this mode only once and decide that it is better for me to run
              PTgui in semi-automatd mode.

              > This is very remarkable since in the early days of hugin one of Pablo's major targets was to develop an easy to use/learn panorama frontend. I think hugin is stable, comfortable, easy to use, but it's definitevely not easy to learn.
              >
              With the advanced knowledge from PTgui I found the trasition easy. The
              process is the same, the tabs replicating it in the user interface are
              similar. The difficulties (and the inefficiencies) are at the user
              interface level, not the functionality which is almost identical.

              > Things have changed a lot and meanwhile it's easier than ever to start developing panoramas. Hugin (and PTGui as well) gives you a complete package and straight from downloading and installing you can start - that's really cool.
              >
              Indeed, both of them do, as does Autopano Pro. I have not tried
              Stitcher, but it does this too. Gone are the day of difficult installs.

              > Hugin isn't able to detect the correct lens setting for my old Sigma 8mm MF - PTGui can. If you have a file stored with the lens setting you found once you're fine. I think Hugin will address this by using the ptlens database soon?!
              >
              > PTGui can find the right cropcircle automatically - cool! Not a big deal in Hugin (just 2 clicks), but a newbie will not know that such a function is there and what it is good for.
              >
              My way of working is to set up a template for a specific combo of camera
              and lens. The template has been around for a while, so I was not aware
              that PTgui finds the crop circle automatically. Nice for a newbie. A
              template is more efficient (though it could be made even more efficient
              if the stitching software would verify that there has not been a shift
              of the circle).

              > Using autopano-sift/autopano within hugin is fine. Best results I get using autopano-sift without ransac check. So there are wrong controlpoints I need to filter for. Usually I optimize 2-4 times and delete the points with very large values using the controlpointlist. That are only a few clicks, but a newbie will stumble on this.
              >
              CP are IMHO one of the major weaknesses of hugin. Although the automated
              zoom in is nice, it slows the machine down. The round circles
              identifying the CPs are very difficult to read. I'd rather have a
              crosshair X or something else that identifies the exact point, not the
              appoximate area where it is located. Working through the list of CP is
              difficult, as is manual entry of yaw/pitch/roll in the image parameters.
              I do not know if this is hugin, or the widgets used for its GUI, but it
              slows me down.

              > The default optimization method of hugin is very helpful to detect wrong points and to bring the images into a general order. For good results you need to select another method (maybe "All" or "Custom"). Having not enough cp's, no verticals/horizontals or only many cp's, that are crowded around the center this can result in settings that are less good (Hugin reports that, like PTGui does). That's not an issue and due to UNDO etc. this can be easily and quickly solved. But a newbie would stumble here again. I think PTGui optimizes only y,p,r,b (and v?!) in simple mode to avoid those situations.
              >
              I like the different preset optimization methods. I also like PTgui
              granularity that allows me to select individually which parameter to
              optimize when I need to do so. In my PTgui template I have it preset to
              what is my usual first step. Only for difficult stitches I have to
              change what is optimized. Having the ability to create such custom sets
              (i.e. going further than what hugin does now) and save the set under a
              name would be a bonus.

              True, a newbie would stumble, but then the question is who is the target
              audience. And: it is possible to have the same user interface for both
              experts and newbies, as PTgui shows. The reference for newbies however
              is Autopano: drop a directory on it with source images for 10 panos and
              it will compose all of them with *no* user intervention. Unfortunately
              it does not yet support Fisheye.

              > Preview in hugin is fine and fast and automatically updated if needed - well done! It also show's you the influence of the vignetting tool!!!
              >
              Yes, I liked the preview. This is where in PTgui I do numerical
              transform to "frame" the view as I want it. I do not recall if this was
              possible in hugin too.

              > I'm thankful for the vignetting capabilities although I think this belongs into a RAW converter
              agree.

              > In the end, the result in Hugin (using my usual technique) was better (less stitching errors) than in PTGui using simple mode. Deleting one wrong controlpoint in PTGui (using the controlpoint list) and adding 2 addional points finally leaded to very similar results.
              It took me significantly more time to finish the stitch in hugin, with
              similar quality. IMHO stitching applications no longer differentiate on
              the set of features. They all have great features and do a decent job.
              What matters to me now is efficiency. Speed. Usability.

              > My recommendations to make Hugin more newby-friendly:
              > - A wizard/druid (maybe a range of wizards "Spherical with Fish", "Multirow with Rect", etc..) that triggers autopano/-sift with useful parameters, does basic optimisation and cp filtering, stable post-optimisation, comes up with a preview and shows a short report what you can do next to improve your panorama (or a button "Stitch Now?").
              >
              could be helpful. I'd rather see hugin using a different auto CP
              functionality - one that does not come with the strings attached of
              autopano/-sift (there are patents in there).

              > - A bad-cp-filtering-by-optimisation tool would be nice as well for advanced users.
              >
              yes, and hopefully that auto CP functionality will work. I've stitched
              hundreds of panos in PTgui and had seldom bad CPs. Only in two instances
              (very symmetric buildings) I encountered massive problems. I sent them
              to Joost and I believe he has improved autoCP in the meantime.

              > - A basic HTML creation tab (just some fields for author, title, template, etc.) to create a folder with ptviewer, an html file (using a HTML template file), and the equirectangular image in would be a nice goodie for beginners too.
              >
              IMHO this does not belong into a stitching tool, and there are good
              authoring tools out there. Pano2QTVR takes the stitched equirect and
              generates all the necessary output / formats.

              What I'd like to see is HDR end to end: take HDR input pictures and
              output a stitched HDR pano.

              For newbies I prefer the Autopano Pro approach. No wizards. No
              explanations. Just drop the folder on the app and let it run. At this
              level, competition is anyway from the non-perspective corrected
              stitching tools that come bundled with consumer digital cameras and not
              the perspective corrected tools like the ones we discuss here.


              Yuv
            • Mike Runge
              Hi Yuv, please see my answers between the lines. ... No doubt, that it is a very good tool. I m using hugin since the very first time - I just like it :-) ...
              Message 6 of 13 , Aug 1, 2006
              • 0 Attachment
                Hi Yuv,
                please see my answers between the lines.

                Yuval Levy wrote:
                > mike@... wrote:
                >
                >> The main advantage of PTGui I have observed:
                >> It's dammend easy for beginners.
                >>
                > It's even better for advanced users.
                >
                No doubt, that it is a very good tool. I'm using hugin since the very
                first time - I just like it :-)
                >
                >> The simple mode developed a good result just clicking a handful of buttons without knowing how panotools are 'ticking' - great!
                >>
                >>
                > I used this mode only once and decide that it is better for me to run
                > PTgui in semi-automatd mode.
                >
                So did I. No doubt, that you can reach excellent results with both
                tools. I found it very interesting, that 'start making panoramas' has
                become so easy - so I focussed on this point.
                >
                >> This is very remarkable since in the early days of hugin one of Pablo's major targets was to develop an easy to use/learn panorama frontend. I think hugin is stable, comfortable, easy to use, but it's definitevely not easy to learn.
                >>
                >>
                > With the advanced knowledge from PTgui I found the trasition easy. The
                > process is the same, the tabs replicating it in the user interface are
                > similar. The difficulties (and the inefficiencies) are at the user
                > interface level, not the functionality which is almost identical.
                >
                agree
                >
                >> Things have changed a lot and meanwhile it's easier than ever to start developing panoramas. Hugin (and PTGui as well) gives you a complete package and straight from downloading and installing you can start - that's really cool.
                >>
                >>
                > Indeed, both of them do, as does Autopano Pro. I have not tried
                > Stitcher, but it does this too. Gone are the day of difficult installs.
                >
                >
                >> Hugin isn't able to detect the correct lens setting for my old Sigma 8mm MF - PTGui can. If you have a file stored with the lens setting you found once you're fine. I think Hugin will address this by using the ptlens database soon?!
                >>
                >> PTGui can find the right cropcircle automatically - cool! Not a big deal in Hugin (just 2 clicks), but a newbie will not know that such a function is there and what it is good for.
                >>
                >>
                > My way of working is to set up a template for a specific combo of camera
                > and lens. The template has been around for a while, so I was not aware
                > that PTgui finds the crop circle automatically. Nice for a newbie. A
                > template is more efficient (though it could be made even more efficient
                > if the stitching software would verify that there has not been a shift
                > of the circle).
                >
                So do I. I have observed, that the really first panorama is the most
                complicated for newbies. Once you have a template for the lens setting
                it's much much easier. For somebody doing his very first panorama it's a
                mess finding the right lens parameters without knowing how the panotools
                and the optimizer are working. BTW: Hugin has a switch (default is on)
                to move the cropcircle with d,e.
                >
                >> Using autopano-sift/autopano within hugin is fine. Best results I get using autopano-sift without ransac check. So there are wrong controlpoints I need to filter for. Usually I optimize 2-4 times and delete the points with very large values using the controlpointlist. That are only a few clicks, but a newbie will stumble on this.
                >>
                >>
                > CP are IMHO one of the major weaknesses of hugin. Although the automated
                > zoom in is nice, it slows the machine down. The round circles
                > identifying the CPs are very difficult to read. I'd rather have a
                > crosshair X or something else that identifies the exact point, not the
                > appoximate area where it is located. Working through the list of CP is
                > difficult, as is manual entry of yaw/pitch/roll in the image parameters.
                > I do not know if this is hugin, or the widgets used for its GUI, but it
                > slows me down.
                >
                Do not agree.
                I like the way of manual/semi-manual CP setting in Hugin. While setting
                a point, you have a crosshair, for later comparision the circles are
                fine (or use the cp-finetune function for individual points or all points).
                Keyin in y,p,r etc. in the images tab still needs a additional 'Tab' or
                'Enter' - don't like that too. I think it's the widget behaving
                different on different platforms?! I would like to do that kind of
                editing directly in the optimizer tab (including the multiple selection
                possibilities of the images tab).
                >
                >> The default optimization method of hugin is very helpful to detect wrong points and to bring the images into a general order. For good results you need to select another method (maybe "All" or "Custom"). Having not enough cp's, no verticals/horizontals or only many cp's, that are crowded around the center this can result in settings that are less good (Hugin reports that, like PTGui does). That's not an issue and due to UNDO etc. this can be easily and quickly solved. But a newbie would stumble here again. I think PTGui optimizes only y,p,r,b (and v?!) in simple mode to avoid those situations.
                >>
                >>
                > I like the different preset optimization methods. I also like PTgui
                > granularity that allows me to select individually which parameter to
                > optimize when I need to do so. In my PTgui template I have it preset to
                > what is my usual first step. Only for difficult stitches I have to
                > change what is optimized. Having the ability to create such custom sets
                > (i.e. going further than what hugin does now) and save the set under a
                > name would be a bonus.
                >
                Normally, I use the default method to kick out the wrong CP's. If that's
                fine, I check the horizon. If needed, I set 2 or 3 verticals or directly
                "Optimize all". It's simple, works reliable and fast, but only with a
                good lens template. Otherwise you better do it step-by-step.
                > True, a newbie would stumble, but then the question is who is the target
                > audience. And: it is possible to have the same user interface for both
                > experts and newbies, as PTgui shows. The reference for newbies however
                > is Autopano: drop a directory on it with source images for 10 panos and
                > it will compose all of them with *no* user intervention. Unfortunately
                > it does not yet support Fisheye.
                >
                The idea of autopano is great, but I don't like tolls that give you all
                or nothing.
                I like autopano Pro. If it just works fine - ok. If you have problems -
                export a Hugin ptofile and go on with hugin. But it's not for free and I
                like the possibility to infect people doing panoramas by trying free
                software. I have no problem to pay for software - but free software is
                still a big bonus.
                >
                >> Preview in hugin is fine and fast and automatically updated if needed - well done! It also show's you the influence of the vignetting tool!!!
                >>
                >>
                > Yes, I liked the preview. This is where in PTgui I do numerical
                > transform to "frame" the view as I want it. I do not recall if this was
                > possible in hugin too.
                >
                >
                >> I'm thankful for the vignetting capabilities although I think this belongs into a RAW converter
                >>
                > agree.
                >
                >
                >> In the end, the result in Hugin (using my usual technique) was better (less stitching errors) than in PTGui using simple mode. Deleting one wrong controlpoint in PTGui (using the controlpoint list) and adding 2 addional points finally leaded to very similar results.
                >>
                > It took me significantly more time to finish the stitch in hugin, with
                > similar quality. IMHO stitching applications no longer differentiate on
                > the set of features. They all have great features and do a decent job.
                > What matters to me now is efficiency. Speed. Usability.
                >
                My usual workflow is quite efficient for stitching a range of panoramas:
                - Editing a simple batchfile that runs autopano-sift over a range of
                folder (each one contains the source images of a specific panorama)
                - running the batchfile (gives a Hugin.pto in each folder)
                - for each folder
                - opening Hugin.pto
                - setting r=90deg for all images
                - applying lens template
                - setting crop for all images
                - optimize, delete wrong cp's, optimize, delete wrong cp's, ...
                (- set verticals)
                - optimize all
                - set stitch options
                - save
                - editing a second simple batchfile that runs nona and smartblend over
                the folders

                It's a bit more interaction (editing the pathes in the batchfiles), but
                the advantage is, that the time-consuming processes (like processing
                CP's, stitching and blending) all can run in batch mode (e.g. over night).
                I guess, a similar workflow is possible with PTGui too?!
                >
                >> My recommendations to make Hugin more newby-friendly:
                >> - A wizard/druid (maybe a range of wizards "Spherical with Fish", "Multirow with Rect", etc..) that triggers autopano/-sift with useful parameters, does basic optimisation and cp filtering, stable post-optimisation, comes up with a preview and shows a short report what you can do next to improve your panorama (or a button "Stitch Now?").
                >>
                >>
                > could be helpful. I'd rather see hugin using a different auto CP
                > functionality - one that does not come with the strings attached of
                > autopano/-sift (there are patents in there).
                >
                agree - cutting these strings would be nice.
                >
                >> - A bad-cp-filtering-by-optimisation tool would be nice as well for advanced users.
                >>
                >>
                > yes, and hopefully that auto CP functionality will work. I've stitched
                > hundreds of panos in PTgui and had seldom bad CPs. Only in two instances
                > (very symmetric buildings) I encountered massive problems. I sent them
                > to Joost and I believe he has improved autoCP in the meantime.
                >
                >
                >> - A basic HTML creation tab (just some fields for author, title, template, etc.) to create a folder with ptviewer, an html file (using a HTML template file), and the equirectangular image in would be a nice goodie for beginners too.
                >>
                >>
                > IMHO this does not belong into a stitching tool, and there are good
                > authoring tools out there. Pano2QTVR takes the stitched equirect and
                > generates all the necessary output / formats.
                >
                I use/like pano2qtvr too ;-)
                It's just to have the whole stuff needed in one package so you could
                tell somebody:
                "Get this hugin package, throw in your images, follow the tabs and on
                the end you can put your result straight to the web".
                > What I'd like to see is HDR end to end: take HDR input pictures and
                > output a stitched HDR pano.
                >
                agree
                > For newbies I prefer the Autopano Pro approach. No wizards. No
                > explanations. Just drop the folder on the app and let it run. At this
                > level, competition is anyway from the non-perspective corrected
                > stitching tools that come bundled with consumer digital cameras and not
                > the perspective corrected tools like the ones we discuss here.
                >
                >
                > Yuv
                >
                best, mike
                >
                >
                > --
                >
                > Yahoo! Groups Links
                >
                >
                >
                >
                >
                >
                >
                >
                >
              • yertletertle
                ... corrections ? ... Thanks for the thoughts. Not everyone shoots RAW of course, and for them (me) vignetting correction as a pre-stitch step makes perfect
                Message 7 of 13 , Aug 1, 2006
                • 0 Attachment
                  --- In PanoToolsNG@yahoogroups.com, Yuval Levy <yahoo06@...> wrote:

                  > > Did you have a chance to evaluate the automatic vignetting and TCA
                  corrections ?
                  > >
                  > No and in their current incarnation they are of no interest to me. IMHO
                  > the best place to correct for lens aberrations, particularly for TCA, is
                  > when demosaicizing the RAW, before interpolation into TIFF. This is what
                  > Adobe RAW Converter, BibblePro and SilkyPix all do. I feed corrected
                  > TIFFs into my stitching tool. For such functionality to be interesting
                  > in a stitching tool, it would have to take RAW files as input. I have
                  > not searched for such a functionality in hugin. I'd rather see stitching
                  > tools able to process HDR files than RAW files.

                  Thanks for the thoughts. Not everyone shoots RAW of course, and for
                  them (me) vignetting correction as a pre-stitch step makes perfect
                  sense. Since it is a large scale effect, doing it at the RAW stage
                  should make very little difference. If you're concerned about
                  numerical clipping and round-off inherent in VC and TCA, you can of
                  course convert your RAW to 16bit and work with that... everything in
                  Hugin works on all the many supported data types (up to 32bit floating
                  point!). See, e.g.,
                  http://wiki.panotools.org/RAW_dynamic_range_extraction.

                  The other *main* advantage which you didn't see is the ability of
                  Hugin to directly estimate from the resulting overlap of images the
                  radial falloff due to vignetting. So even for people who don't care
                  to go to all the trouble, the "waving vertical bands of dark" issue
                  can be improved.
                • Yuval Levy
                  ... AFAIK all digital cameras shoot RAW, which is then converted by the camera internal RAW converter if storage on the memory card is in a different format.
                  Message 8 of 13 , Aug 2, 2006
                  • 0 Attachment
                    yertletertle wrote:

                    > Not everyone shoots RAW of course

                    AFAIK all digital cameras shoot RAW, which is then converted by the
                    camera internal RAW converter if storage on the memory card is in a
                    different format.

                    > If you're concerned about
                    > numerical clipping and round-off inherent in VC and TCA, you can of
                    > course convert your RAW to 16bit and work with that...

                    This is not my concern. The RAW conversion without prior VC and TCA
                    correction will have inherent flaws that will multiply themselves
                    through the demosaicing/interpolation in a way that might be
                    irreversible. In most digital cameras, during demosaicing, each pixel of
                    the RAW image is added colour from adjacent pixels. If due to TCA the
                    adjacent pixel shows a color that it is not supposed to show, the
                    conversion from RAW to TIFF will be flawed. I suspect that no TCA
                    correction later on will be able to revert this. It affects
                    8/12/16/32bit pixels.

                    Not affected are Foveon sensors. For them the hugin process of VC and
                    TCA after RAW conversion makes sense. Same for the scan of photos and
                    slides.


                    > The other *main* advantage which you didn't see is the ability of
                    > Hugin to directly estimate from the resulting overlap of images the
                    > radial falloff due to vignetting.

                    True I did not see this. I also do not have any use for this as I have
                    other methods to measure for and correct light falloff. Why reinvent the
                    wheel?


                    > So even for people who don't care
                    > to go to all the trouble, the "waving vertical bands of dark" issue
                    > can be improved

                    I believe Autopano Pro does this too. There are plenty of ways to
                    achieve the same result. IMO the VC and TCA functionalities of Hugin
                    would be more useful if applied before demosaicing the RAW and I am not
                    inclined to play with them just for the fun of testing a functionality
                    for which I find no practical use in my case.


                    Yuv
                  • Yuval Levy
                    Hi Mike, thanks for your comments. ... where? I did not see any crosshair on my Windows install of hugin. Which platform do you use hugin on? ... the
                    Message 9 of 13 , Aug 2, 2006
                    • 0 Attachment
                      Hi Mike,

                      thanks for your comments.

                      Mike Runge wrote:
                      >> CP are IMHO one of the major weaknesses of hugin. Although the automated
                      >> zoom in is nice, it slows the machine down. The round circles
                      >> identifying the CPs are very difficult to read. I'd rather have a
                      >> crosshair X or something else that identifies the exact point, not the
                      >> appoximate area where it is located. Working through the list of CP is
                      >> difficult, as is manual entry of yaw/pitch/roll in the image parameters.
                      >> I do not know if this is hugin, or the widgets used for its GUI, but it
                      >> slows me down.
                      >>
                      >>
                      > Do not agree.
                      > I like the way of manual/semi-manual CP setting in Hugin. While setting
                      > a point, you have a crosshair
                      where? I did not see any crosshair on my Windows install of hugin. Which
                      platform do you use hugin on?
                      > for later comparision the circles are
                      > fine (or use the cp-finetune function for individual points or all points).
                      >
                      the cp-finetune option is neat, especially for difficult light
                      situations. still, i find the circles way too big and intrusive. I
                      prefer numbered points (like PTgui) with a smaller symbol.

                      > Keyin in y,p,r etc. in the images tab still needs a additional 'Tab' or
                      > 'Enter' - don't like that too. I think it's the widget behaving
                      > different on different platforms?! I would like to do that kind of
                      > editing directly in the optimizer tab (including the multiple selection
                      > possibilities of the images tab).
                      >
                      if it is the widget behavior, I am afraid that we will have to live with
                      this as it is, even though, like you, I also would like to do that kind
                      of editing directly in any tab.

                      >>> The default optimization method of hugin is very helpful to detect wrong points and to bring the images into a general order. For good results you need to select another method (maybe "All" or "Custom"). Having not enough cp's, no verticals/horizontals or only many cp's, that are crowded around the center this can result in settings that are less good (Hugin reports that, like PTGui does). That's not an issue and due to UNDO etc. this can be easily and quickly solved. But a newbie would stumble here again. I think PTGui optimizes only y,p,r,b (and v?!) in simple mode to avoid those situations.
                      >>>
                      >>>
                      >>>
                      >> I like the different preset optimization methods. I also like PTgui
                      >> granularity that allows me to select individually which parameter to
                      >> optimize when I need to do so. In my PTgui template I have it preset to
                      >> what is my usual first step. Only for difficult stitches I have to
                      >> change what is optimized. Having the ability to create such custom sets
                      >> (i.e. going further than what hugin does now) and save the set under a
                      >> name would be a bonus.
                      >>
                      >>
                      > Normally, I use the default method to kick out the wrong CP's. If that's
                      > fine, I check the horizon. If needed, I set 2 or 3 verticals or directly
                      > "Optimize all". It's simple, works reliable and fast, but only with a
                      > good lens template. Otherwise you better do it step-by-step.
                      >
                      in PTgui I took the habit of always set 3 verticals. It's so fast and a
                      no-brainer. then there is no need to do anything else than "optimize
                      all", unless this is a very difficult stitch.



                      > The idea of autopano is great, but I don't like tolls that give you all
                      > or nothing.
                      >
                      I also prefer tools that let you enable/disable individual automatism.
                      This is why I love PTgui so much. Still, there are some functionalities
                      of Autopano Pro that I am missing.

                      > I like autopano Pro. If it just works fine - ok. If you have problems -
                      > export a Hugin ptofile and go on with hugin. But it's not for free and I
                      > like the possibility to infect people doing panoramas by trying free
                      > software. I have no problem to pay for software - but free software is
                      > still a big bonus.
                      >
                      PTgui is not free either. While free software is nice, price is not the
                      only factor I consider in choosing my software. Usability and
                      performance, just to mention two more. Productivity is the goal,
                      measured as how much effort do I have to put in (minutes) to produce a
                      panorama.

                      >>> I'm thankful for the vignetting capabilities although I think this belongs into a RAW converter
                      >>>
                      >>>
                      >> agree.
                      >>
                      well, maybe somebody will be crazy enough to program a RAW stitcher?
                      it's just three separate stitches for the three color channels of the
                      mosaic before demosaicing :-)

                      > My usual workflow is quite efficient for stitching a range of panoramas:
                      > - Editing a simple batchfile that runs autopano-sift over a range of
                      > folder (each one contains the source images of a specific panorama)
                      > - running the batchfile (gives a Hugin.pto in each folder)
                      > - for each folder
                      > - opening Hugin.pto
                      > - setting r=90deg for all images
                      > - applying lens template
                      > - setting crop for all images
                      > - optimize, delete wrong cp's, optimize, delete wrong cp's, ...
                      > (- set verticals)
                      > - optimize all
                      > - set stitch options
                      > - save
                      > - editing a second simple batchfile that runs nona and smartblend over
                      > the folders
                      >
                      > It's a bit more interaction (editing the pathes in the batchfiles), but
                      > the advantage is, that the time-consuming processes (like processing
                      > CP's, stitching and blending) all can run in batch mode (e.g. over night).
                      > I guess, a similar workflow is possible with PTGui too?!
                      >
                      In PTgui I am now below 6 minutes per pano. This includes:
                      - download the RAWs from the camera
                      - separating each pano project in folders
                      - converting the RAWs, including CA & Vignetting correction, to TIFFs
                      (can be 16bit or 8bit)
                      - feed the TIFFs to PTgui
                      - apply PTgui template (lens, initial yaw/tilt/roll, stitch options)
                      - add three vertical CP
                      - autogenerate CP
                      - optimize all
                      - if necessary: delete wrong cp and repeate optimization until happy
                      - use preview to "frame" the view
                      - set file name (other stitch options are in the template)
                      - save

                      the run the batch overnight, at about 15 minutes per 7000x3500 pano

                      > I use/like pano2qtvr too ;-)
                      > It's just to have the whole stuff needed in one package so you could
                      > tell somebody:
                      > "Get this hugin package, throw in your images, follow the tabs and on
                      > the end you can put your result straight to the web".
                      >
                      then the makers of the stitching and authoring tool should bundle their
                      stuff for distribution together - but the last thing I'd like to see is
                      the wheel reinvented, i.e. develop a stitching package to do authoring
                      work or the other way around.

                      >> What I'd like to see is HDR end to end: take HDR input pictures and
                      >> output a stitched HDR pano.
                      >>
                      >>
                      > agree
                      >


                      ... mhhh... HDR end to end or RAW end to end? or both?
                      I am day dreaming...

                      ciao
                      Yuv
                    • Pajuaba Gmail
                      ... You mean all DSLR, right? Because there is plenty of cameras around that don´t allow the user access to the raw data, which, for me - and for the sake of
                      Message 10 of 13 , Aug 2, 2006
                      • 0 Attachment
                        Yuval Levy escreveu:
                        > yertletertle wrote:
                        >
                        >
                        >>Not everyone shoots RAW of course
                        >
                        >
                        > AFAIK all digital cameras shoot RAW, which is then converted by the
                        > camera internal RAW converter if storage on the memory card is in a
                        > different format.

                        You mean all DSLR, right? Because there is plenty of cameras around that
                        don´t allow the user access to the raw data, which, for me - and for the
                        sake of the thread, in my view - means they don´t shoot RAW. We are nor
                        talking about russian cracks to the firmware, that can not only damage
                        the camera, but void the warranty too.


                        >
                        >
                        > True I did not see this. I also do not have any use for this as I have
                        > other methods to measure for and correct light falloff. Why reinvent the
                        > wheel?
                        >

                        Because not everybody has access to the raw data, where this could be
                        done easier and with better results.
                        Remember, not everything that works for us works for everyone - and some
                        day maybe you´ll be faced with the need to use this feature ;-) .
                        Regards,
                        Rodolpho Pajuaba
                      • Roger Howard
                        ... I ve thought a lot about this. The easiest thing to do here would be to support linearized (de-mosaiced) DNG as input. I don t think stitching before
                        Message 11 of 13 , Aug 2, 2006
                        • 0 Attachment
                          On Wed, August 2, 2006 11:54 am, Yuval Levy wrote:
                          > well, maybe somebody will be crazy enough to program a RAW stitcher?
                          > it's just three separate stitches for the three color channels of the
                          > mosaic before demosaicing :-)

                          I've thought a lot about this. The easiest thing to do here would be to
                          support "linearized" (de-mosaiced) DNG as input. I don't think stitching
                          before demosaicing is necessary or even useful, but I'd LOVE to have a
                          demosaiced RAW stitcher, so I can then perform final corrections to the
                          equirectangular image in my RAW processor of choice.

                          As for vignette and CA correction, I don't think, IIRC, that these steps
                          are done until after demosaicing, so I see no problem in principle with
                          performing these steps on processed 16bit TIFFs either. The difference, if
                          any, between the two would be insignificant. If it was a concern, then
                          using a linear 16bit TIFF output from your RAW file, using dcraw for
                          instance, would be roughly equivalent anyhow. There's so much tonal
                          manipulation happening anyhow as a result of the blending, that I tend to
                          look at VC, in particular, as just a first step in eliminating seams. CA
                          is different, of course, and needs to be done before remapping, but maybe
                          not before demosaicing of the RAW data. Certainly, if we could stitch with
                          linear DNGs we'd need to integrate CA correction into the process.

                          -R
                        • Roger Howard
                          ... You re both agreeing, I think Yuval was just being quite literal. All camera sensors do capture RAW data, of course. But that s irrelevant to this thread
                          Message 12 of 13 , Aug 2, 2006
                          • 0 Attachment
                            On Wed, August 2, 2006 12:00 pm, Pajuaba Gmail wrote:
                            >
                            >
                            > Yuval Levy escreveu:
                            >> yertletertle wrote:
                            >>
                            >>
                            >>>Not everyone shoots RAW of course
                            >>
                            >>
                            >> AFAIK all digital cameras shoot RAW, which is then converted by the
                            >> camera internal RAW converter if storage on the memory card is in a
                            >> different format.
                            >
                            > You mean all DSLR, right? Because there is plenty of cameras around that
                            > don´t allow the user access to the raw data, which, for me - and for the
                            > sake of the thread, in my view - means they don´t shoot RAW. We are nor
                            > talking about russian cracks to the firmware, that can not only damage
                            > the camera, but void the warranty too.

                            You're both agreeing, I think Yuval was just being quite literal. All
                            camera sensors do capture RAW data, of course. But that's irrelevant to
                            this thread unless they also support SAVING the RAW data into some file
                            format that supports it. Of course many cameras don't support saving
                            anything but non-linear, processed JPEGs.

                            I think this is a semantics debate. Yes, all cameras shoot RAW. No, all
                            cameras don't shoot RAW :)
                          • Pajuaba Gmail
                            Yes, indeed! ;-) Regards, Rodolpho Pajuaba
                            Message 13 of 13 , Aug 2, 2006
                            • 0 Attachment
                              Yes, indeed! ;-)
                              Regards,
                              Rodolpho Pajuaba

                              Roger Howard escreveu:
                              > But that's irrelevant to
                              > this thread unless they also support SAVING the RAW data into some file
                              > format that supports it. Of course many cameras don't support saving
                              > anything but non-linear, processed JPEGs.
                              >
                              > I think this is a semantics debate. Yes, all cameras shoot RAW. No, all
                              > cameras don't shoot RAW :)
                              >
                              >
                            Your message has been successfully submitted and would be delivered to recipients shortly.