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

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

Expand Messages
  • Yuval Levy
    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
    • Show all 13 messages in this topic