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

Re: [PanoToolsNG] Re: hugin 0.6 - amazing!

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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 6 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 7 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 8 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 9 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 10 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 11 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.