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

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

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