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

Re: [PanoToolsNG] krpano and tiles in ZIP files

Expand Messages
  • Roger Howard
    On Tue, 02 Jun 2009 04:32:23 -0000, Ingemar Bergmark ... I did something just like this for Zoomify some years ago... it raised enough flags on their end
    Message 1 of 3 , Jun 2, 2009
    • 0 Attachment
      On Tue, 02 Jun 2009 04:32:23 -0000, "Ingemar Bergmark"
      <ingemar@...> wrote:

      > I've tested this on my server, and it works fine. This is great for me,
      > since my webhost only allows 50.000 inodes and I'm already using 28.000.
      > If I plan to publish some gigapixel panoramas, then the remaining inodes
      > would get eaten up very quickly, but I think with the above aproach, I
      > might be able to survive a little longer. :-)
      > I'm not sure how much extra CPU-usage this kind of fetching will create
      > though. On a shared-hosting environment I might get into trouble, but
      > only time will tell.

      I did something just like this for Zoomify some years ago... it raised
      enough flags on their end that I switched hosts for that project to one
      that didn't care about inode counts. It added a lot of CPU load, IIRC, to
      an otherwise low-load viewer since you had to get PHP involved with every
      tile operation... it also adds a lot of additional i/o overhead since
      there's several extra reads (parsing the ZIP header) per tile.

      I played with other approaches - the most obvious is to pre-parse each ZIP
      file and create an index in a database, which holds just the file offsets
      of each tile within the ZIP. Assuming the zip is saved without compression
      (since there's no real benefit) then you can unpack files from it pretty
      quickly with a lot less load with simple file reads by byterange than
      actually using the PHP zip libraries for each tile read.

      Depending on your host, you may also consider storing tiles in the database
      - seems stupid, but in many cases there's a lot more excess database
      capacity than storage/inodes and it'd be trivial to store each tile in a
      blob and write a php shim for it.
    • Ingemar Bergmark
      ... Thanks for the extra info, we ll see what happens with my host. The pre-parsing approach is very interesting, I m definately going to give that a try... /
      Message 2 of 3 , Jun 2, 2009
      • 0 Attachment
        --- In PanoToolsNG@yahoogroups.com, Roger Howard <rogerhoward@...>
        > wrote:
        >
        > I did something just like this for Zoomify some years ago... it
        > raised enough flags on their end that I switched hosts for that
        > project to one that didn't care about inode counts. It added a lot
        > of CPU load, IIRC, to an otherwise low-load viewer since you had to
        > get PHP involved with every tile operation... it also adds a lot of
        > additional i/o overhead since there's several extra reads (parsing
        > the ZIP header) per tile.
        > I played with other approaches - the most obvious is to pre-parse
        > each ZIP file and create an index in a database, which holds just
        > the file offsets of each tile within the ZIP. Assuming the zip is
        > saved without compression (since there's no real benefit) then you
        > can unpack files from it pretty quickly with a lot less load with
        > simple file reads by byterange than actually using the PHP zip
        > libraries for each tile read.
        > Depending on your host, you may also consider storing tiles in the
        > database - seems stupid, but in many cases there's a lot more
        > excess database capacity than storage/inodes and it'd be trivial to
        > store each tile in a blob and write a php shim for it.
        >

        Thanks for the extra info, we'll see what happens with my host.
        The pre-parsing approach is very interesting, I'm definately going to give that a try...

        / Ingemar
      Your message has been successfully submitted and would be delivered to recipients shortly.