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

OUT OF MEMORY :( boo hoo

Expand Messages
  • Jeffrey Martin
    Hi Joost, I m stitching 890 images together (200mm, lots of overlap) (semi-handheld.... yeeeha!!!) the first 200 went great! (too good to be true) I unchecked
    Message 1 of 5 , Sep 26, 2007
    • 0 Attachment
      Hi Joost,

      I'm stitching 890 images together (200mm, lots of overlap)
      (semi-handheld.... yeeeha!!!)

      the first 200 went great! (too good to be true)
      I unchecked the yaw/pitch/roll for the first 200 (except for the last 15
      which might overlap the next 400)
      the next 400 went great!
      then I added all the rest, and checked yaw/pitch/roll for ALL 890 images.
      out of memory. both with
      ptgui and panotools blender.

      I'm running Windows Dog Poo (XP x64 - 64bit) with 8gb ram which I haven't
      yet successfully used all at the same time :-)

      the final pano seems to be 153000 pixels wide, and requires 1600gb of disk
      space. Well we'll deal with that part later :-D (maybe the "strip"
      processing with hugin/enblend would be more realistic here)

      I realize that this kind of project is not going to be something ptgui will
      have to deal with very often probably (I won't do this again until I have a
      robot at least) but still it would be nice if I could get it stitched :-)

      best,
      Jeffrey Martin
      --

      ------------------
      www.360cities.net
      www.prague360.com
      tel. +420 608 076 502
      skype jeffrey.s.martin


      [Non-text portions of this message have been removed]
    • Bernhard Vogl
      ... You re nuts. Buy Lego and build a robot: http://dativ.at/gigabot/ ;-) ... Your Windows dog poo is able to eat up all your resources but unfortunately PTGui
      Message 2 of 5 , Sep 26, 2007
      • 0 Attachment
        Jeffrey Martin schrieb:
        > Hi Joost,
        >
        > I'm stitching 890 images together (200mm, lots of overlap)
        > (semi-handheld.... yeeeha!!!)
        >
        You're nuts. Buy Lego and build a robot: http://dativ.at/gigabot/
        ;-)
        > the first 200 went great! (too good to be true)
        > I unchecked the yaw/pitch/roll for the first 200 (except for the last 15
        > which might overlap the next 400)
        > the next 400 went great!
        > then I added all the rest, and checked yaw/pitch/roll for ALL 890 images.
        > out of memory. both with
        > ptgui and panotools blender.
        >
        > I'm running Windows Dog Poo (XP x64 - 64bit) with 8gb ram which I haven't
        > yet successfully used all at the same time :-)
        >
        Your Windows dog poo is able to eat up all your resources but
        unfortunately PTGui isn't: It is still 32bit, which means, there is a
        hard limit at 2GB for the application, no matter how much RAM you
        actually have.
        You may need to reduce the number of control points. I had success
        editing a panorama in PTGui which was made from 1200 image, so it's
        basically possible. I wasn't able to render it with PTGui as i didn't
        have the needed terabytes of temp space at hand. You may use Autopano
        Pro for the final render (see below)
        > the final pano seems to be 153000 pixels wide, and requires 1600gb of disk
        > space. Well we'll deal with that part later :-D
        Yes, i also have seen that ;-)
        > (maybe the "strip"
        > processing with hugin/enblend would be more realistic here)
        >
        Never heard of that. Maybe you know something i don't?
        Though, a striped multi-file rendering would be a very useful feature:
        a) Computational needs for panorama raise ^2 with the image size.
        b) Application support for resulting file size is almost zero.
        c) It is nonsense to create a huge file just to slice it down in the
        next step.
        d) Everyone who needs the huge image in one file can easily import and
        assemble the stripes

        > I realize that this kind of project is not going to be something ptgui will
        > have to deal with very often probably (I won't do this again until I have a
        > robot at least) but still it would be nice if I could get it stitched :-)
        >
        Hugin is the only software that is available for 64bit (assuming that
        you can compile it yourself, eg. using Linux) but it doesn't support
        .psb files.
        Autopano Pro is also (yet) 32bit but it can render with low memory
        settings to psb file format. Takes ages to render...

        Best regards
        Bernhard
      • Joergen Geerds
        i agree with bernhard, this is a tough project. although i believe after you fixed the optimization OOM you should be able to render it to PSB. I would keep it
        Message 3 of 5 , Sep 26, 2007
        • 0 Attachment
          i agree with bernhard, this is a tough project.
          although i believe after you fixed the optimization
          OOM you should be able to render it to PSB. I would
          keep it in 8 bit, but for sanity purposes.

          Gerard maynard overdid it with his 13 gigapixel
          project also: http://www.harlem-13-gigapixels.com/

          the result is a technical achievement, but not a good
          photograph. i hope your's is better. and get a lego
          bot for that.

          i personally stick with my 500 megapixel panos, they
          are big enough for my purposes (printing at 300 dpi
          and 240cm width)

          good luck

          joergen
          http://newyorkpanorama.com

          --- Bernhard Vogl <bvogl@...> wrote:

          > Jeffrey Martin schrieb:
          > > Hi Joost,
          > >
          > > I'm stitching 890 images together (200mm, lots of
          > overlap)
          > > (semi-handheld.... yeeeha!!!)
          > >
          > You're nuts. Buy Lego and build a robot:
          > http://dativ.at/gigabot/
          > ;-)
          > > the first 200 went great! (too good to be true)
          > > I unchecked the yaw/pitch/roll for the first 200
          > (except for the last 15
          > > which might overlap the next 400)
          > > the next 400 went great!
          > > then I added all the rest, and checked
          > yaw/pitch/roll for ALL 890 images.
          > > out of memory. both with
          > > ptgui and panotools blender.
          > >
          > > I'm running Windows Dog Poo (XP x64 - 64bit) with
          > 8gb ram which I haven't
          > > yet successfully used all at the same time :-)
          > >
          > Your Windows dog poo is able to eat up all your
          > resources but
          > unfortunately PTGui isn't: It is still 32bit, which
          > means, there is a
          > hard limit at 2GB for the application, no matter how
          > much RAM you
          > actually have.
          > You may need to reduce the number of control points.
          > I had success
          > editing a panorama in PTGui which was made from 1200
          > image, so it's
          > basically possible. I wasn't able to render it with
          > PTGui as i didn't
          > have the needed terabytes of temp space at hand. You
          > may use Autopano
          > Pro for the final render (see below)
          > > the final pano seems to be 153000 pixels wide, and
          > requires 1600gb of disk
          > > space. Well we'll deal with that part later :-D
          > Yes, i also have seen that ;-)
          > > (maybe the "strip"
          > > processing with hugin/enblend would be more
          > realistic here)
          > >
          > Never heard of that. Maybe you know something i
          > don't?
          > Though, a striped multi-file rendering would be a
          > very useful feature:
          > a) Computational needs for panorama raise ^2 with
          > the image size.
          > b) Application support for resulting file size is
          > almost zero.
          > c) It is nonsense to create a huge file just to
          > slice it down in the
          > next step.
          > d) Everyone who needs the huge image in one file can
          > easily import and
          > assemble the stripes
          >
          > > I realize that this kind of project is not going
          > to be something ptgui will
          > > have to deal with very often probably (I won't do
          > this again until I have a
          > > robot at least) but still it would be nice if I
          > could get it stitched :-)
          > >
          > Hugin is the only software that is available for
          > 64bit (assuming that
          > you can compile it yourself, eg. using Linux) but it
          > doesn't support
          > .psb files.
          > Autopano Pro is also (yet) 32bit but it can render
          > with low memory
          > settings to psb file format. Takes ages to render...
          >
          > Best regards
          > Bernhard
          >
          >



          ____________________________________________________________________________________
          Check out the hottest 2008 models today at Yahoo! Autos.
          http://autos.yahoo.com/new_cars.html
        • paul womack
          ... Hmm. If one uses nona for the mapping, and generates cropped tiffs, that should go fine (apart from CPU load, obviously). The disc space used is
          Message 4 of 5 , Sep 27, 2007
          • 0 Attachment
            Bernhard Vogl wrote:
            > Jeffrey Martin schrieb:
            > actually have.
            > You may need to reduce the number of control points. I had success
            > editing a panorama in PTGui which was made from 1200 image, so it's
            > basically possible. I wasn't able to render it with PTGui as i didn't
            > have the needed terabytes of temp space at hand. You may use Autopano
            > Pro for the final render (see below)
            >> the final pano seems to be 153000 pixels wide, and requires 1600gb of disk
            >> space. Well we'll deal with that part later :-D
            > Yes, i also have seen that ;-)
            >> (maybe the "strip"
            >> processing with hugin/enblend would be more realistic here)
            >>
            > Never heard of that. Maybe you know something i don't?
            > Though, a striped multi-file rendering would be a very useful feature:
            > a) Computational needs for panorama raise ^2 with the image size.
            > b) Application support for resulting file size is almost zero.
            > c) It is nonsense to create a huge file just to slice it down in the
            > next step.
            > d) Everyone who needs the huge image in one file can easily import and
            > assemble the stripes

            Hmm. If one uses nona for the mapping, and generates
            cropped tiffs, that should go fine (apart from CPU load, obviously).

            The disc space used is proportionate to image size.

            To stitch a "strip" or "tile" (the target area), one would simply need to
            decide on the rectangle of interest, and identify
            which (cropped) tiffs overlap with the rectangle of interest.

            Getting the info (width, depth and offset) can be done with ImageMagick (identify).

            One could then use ImageMagick to crop out the required (active) area that falls
            within the target area. Hopefully ImageMagick can do this accurately.

            One then simply runs enblend on THIS set of tiffs in the usual way,
            resulting in a fully stitched target area.

            IIRC one needs ImageMagick 3.4 to handle cropped tiffs correctly.

            ImageMagick has "unfortunate" memory usage, so some other tool
            would be needed to concatanate the tiles/strips into a "final",
            should that be desired.

            Sounds like a perl script to me.

            BugBear
          • Don French
            The Panorama Factory version 4.5 claims to make use of all the RAM available on a Windows x64 system, theoretically up to 128 G. And the virtual memory system
            Message 5 of 5 , Sep 27, 2007
            • 0 Attachment
              The Panorama Factory version 4.5 claims to make use of all the RAM
              available on a Windows x64 system, theoretically up to 128 G. And the
              virtual memory system in Windows x64 gives each application 1 terabyte
              of virtual memory space -- providing the page file is big enough.
              Also, The Panorama Factory uses parallel processing to run
              proportionally faster on multi-processor systems (dual, quad or more).
              I don't think TPF supports psb output yet. However, the feature set
              appears pretty rich, according to this page,
              www.panoramafactory.com/features.html. I am about to try it out on my
              dual processor x64 system and will report back when I have personal
              experience from which to speak.

              -- Don French


              > >
              > Hugin is the only software that is available for 64bit (assuming that
              > you can compile it yourself, eg. using Linux) but it doesn't support
              > .psb files.
              > Autopano Pro is also (yet) 32bit but it can render with low memory
              > settings to psb file format. Takes ages to render...
              >
              > Best regards
              > Bernhard
              >
            Your message has been successfully submitted and would be delivered to recipients shortly.