<html>
  <head>
    <style type="text/css">
      <!--
        body { margin-bottom: 1px; font-variant: normal; margin-left: 4px; margin-top: 4px; line-height: normal; margin-right: 4px }
        p { margin-bottom: 0; margin-top: 0 }
      -->
    </style>
    
  </head>
  <body style="margin-bottom: 1px; margin-left: 4px; margin-top: 4px; margin-right: 4px">
    <p style="margin-top: 0; margin-bottom: 0">
      <font size="3" face="Comic Sans MS">All,</font>    </p>
<br>      
    <p style="margin-top: 0; margin-bottom: 0">
      <font size="3" face="Comic Sans MS">Can someone remind me again, are we talking about saving space, or making it easier to implement something . . .  :c)</font>    </p>
<br>      
    <p style="margin-top: 0; margin-bottom: 0">
      <font size="3" face="Comic Sans MS">I personally prefer nice simple internal pyramided tiles with indexing, about 10% extra space, and very good performance. </font>    </p>
<br>      
    <p style="margin-top: 0; margin-bottom: 0">
      <font size="3" face="Comic Sans MS">Someone earlier in this thread spoke about some of these technologies being somewhat obsolete what with the new network and bandwidth speeds available for publishing.</font>    </p>
<br>      
    <p style="margin-top: 0; margin-bottom: 0">
      <font size="3" face="Comic Sans MS">bobb</font>    </p>
<br>      <br>
    <p style="margin-top: 0; margin-bottom: 0">
      <br>
      <br>
      >>> "Lucena, Ivan" <ivan.lucena@pmldnet.com> wrote:<br>    </p>
    <div style="padding-left: 7px; border-left: solid 1px #050505; margin-bottom: 0; background-color: #f3f3f3; margin-left: 15px; margin-top: 0; margin-right: 0">
      <p style="margin-top: 0; margin-bottom: 0">
        But you can't compress data types other than byte in JPG. Can you do that in JP2K?<br><br><br>>  -------Original Message-------<br>>  From: Landon Blake <lblake@ksninc.com><br>>  Subject: RE: [OSGeo-Discuss] Open FileFormatsandProprietaryAlgorithms[SEC=UNCLASSIFIED]<br>>  Sent: Aug 21 '09 12:42<br>> <br>>  Paul,<br>> <br>>  I was wondering the same thing.<br>> <br>>  It seems a little like choosing to drive a Honda Accord, or a Ferrari.<br>>  The Ferrari is a lot faster and comes with a better looking trophy wife<br>>  (or husband), but the Honda is a lot easier to fix. (Try finding an<br>>  affordable Ferrari mechanic in Stockton, California.)<br>> <br>>  To tie this back into our original discussion, it seems like the<br>>  government should be choosing to drive a Honda Accord when it can,<br>>  instead of the Ferrari.<br>> <br>>  I guess you'd really have to crunch the numbers and see if the savings<br>>  in bandwidth/disk space costs were really worth the compression savings<br>>  that result from a proprietary compression scheme ("wavelet black<br>>  magic").<br>> <br>>  The problem with this is a lot of the benefits that come from the Honda<br>>  Accord (open image format + open compression algorithm) aren't easily<br>>  calculated in dollars and cents.<br>> <br>>  Still, this speaks to an important truth I have discovered in open<br>>  source development: Simple is better, even when it isn't necessarily<br>>  faster and smaller.<br>> <br>>  I'd rather have code that I can understand, or a file format that a<br>>  programmer in 20 years will understand, than a Ferrari you can't drive<br>>  unless you have a PHD and did a thesis on wavelet compression. :]<br>> <br>>  Landon<br>>  Office Phone Number: (209) 946-0268<br>>  Cell Phone Number: (209) 992-0658<br>> <br>> <br>> <br>>  -----Original Message-----<br>>  From: discuss-bounces@lists.osgeo.org<br>>  [mailto:discuss-bounces@lists.osgeo.org] On Behalf Of Paul Ramsey<br>>  Sent: Friday, August 21, 2009 10:36 AM<br>>  To: OSGeo Discussions<br>>  Subject: Re: [OSGeo-Discuss] Open File<br>>  FormatsandProprietaryAlgorithms[SEC=UNCLASSIFIED]<br>> <br>>  So hung up on wavelets, we are.<br>> <br>>  Internally tiled TIFF with JPEG compression and similarly formatted<br>>  internal overviews can achieve 10:1 compression rates without<br>>  noticeable image quality reductions, and as an added bonus can be<br>>  decompressed a heck of a lot faster than wavelet-based formats. The<br>>  wavelet stuff is k00l, in that there is no need for an overview<br>>  pyramid (it's implicit in the compression math) and much higher<br>>  compression rates can be achieved. But operationally, you can go a<br>>  long way with the more primitive (open image format + open compression<br>>  algorithm) approach.<br>> <br>>  P.<br>>  _______________________________________________<br>>  Discuss mailing list<br>>  Discuss@lists.osgeo.org<br>>  <a href="http://lists.osgeo.org/mailman/listinfo/discuss">http://lists.osgeo.org/mailman/listinfo/discuss</a><br>> <br>> <br>>  Warning:<br>>  Information provided via electronic media is not guaranteed against defects including translation and transmission<br>errors. If the reader is not the intended recipient, you are hereby notified that any dissemination, distribution or<br>copying of this communication is strictly prohibited. If you have received this information in error, please notify the<br>sender immediately.<br>>  _______________________________________________<br>>  Discuss mailing list<br>>  Discuss@lists.osgeo.org<br>>  <a href="http://lists.osgeo.org/mailman/listinfo/discuss">http://lists.osgeo.org/mailman/listinfo/discuss</a><br>> <br>_______________________________________________<br>Discuss mailing list<br>Discuss@lists.osgeo.org<br><a href="http://lists.osgeo.org/mailman/listinfo/discuss">http://lists.osgeo.org/mailman/listinfo/discuss</a><br>
      </p>
    </div>
  </body>
</html>