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

krpano and tiles in ZIP files

Expand Messages
  • Ingemar Bergmark
    This turned out to be less work than I thought. I created a php file which will fetch the required tile from a ZIP file. The section in the XML file
    Message 1 of 3 , Jun 1, 2009
    • 0 Attachment
      This turned out to be less work than I thought.
      I created a php file which will fetch the required tile from a ZIP file.

      The <image> section in the XML file was modified as follows:

      <preview type="CUBESTRIP" url="unzip.php?tile=krpano.tiles/preview.jpg"
      />
      <image type="CUBE" multires="true" tilesize="607">
      <level tiledimagewidth="2126" tiledimageheight="2126">
      <left url="unzip.php?tile=krpano.tiles/l2_l_%v_%h.jpg" />
      <front url="unzip.php?tile=krpano.tiles/l2_f_%v_%h.jpg" />
      <right url="unzip.php?tile=krpano.tiles/l2_r_%v_%h.jpg" />
      <back url="unzip.php?tile=krpano.tiles/l2_b_%v_%h.jpg" />
      <up url="unzip.php?tile=krpano.tiles/l2_u_%v_%h.jpg" />
      <down url="unzip.php?tile=krpano.tiles/l2_d_%v_%h.jpg" />
      </level>
      <level tiledimagewidth="709" tiledimageheight="709">
      <left url="unzip.php?tile=krpano.tiles/l1_l_%v_%h.jpg" />
      <front url="unzip.php?tile=krpano.tiles/l1_f_%v_%h.jpg" />
      <right url="unzip.php?tile=krpano.tiles/l1_r_%v_%h.jpg" />
      <back url="unzip.php?tile=krpano.tiles/l1_b_%v_%h.jpg" />
      <up url="unzip.php?tile=krpano.tiles/l1_u_%v_%h.jpg" />
      <down url="unzip.php?tile=krpano.tiles/l1_d_%v_%h.jpg" />
      </level>
      </image>

      unzip.php looks like this (no errorhandling though)

      <?php
      $tName = (array_key_exists("tile", $_GET)) ? $_GET["tile"] : "";
      $zFile = "krpano.tiles.zip";

      $z = new ZipArchive();
      if ($z->open($zFile))
      {
      $im_string = $z->getFromName($tName);
      $im = imagecreatefromstring($im_string);
      $z->close();
      }

      header("Content-Type: image/jpeg");
      header("Content-Disposition: inline");
      imagejpeg($im);
      ?>

      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.

      / Ingemar
      http://panoramas.bergmark.com <http://panoramas.bergmark.com>



      [Non-text portions of this message have been removed]
    • 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 2 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 3 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.