jpeg compression

DGSL
2009-08-31
2012-10-06
  • DGSL

    DGSL - 2009-08-31

    This question has not to do with IIPimage server, but with production of the images to be served.
    For my own images I use the original tiffs, with deflate compression.
    But for the images I let users upload to my server, I need to limit their quota.

    For these, I am using VIPS for jpeg-->tiff conversion, and I would expect that thi command would produce a pyramidal tiff with a size similar to the original JPEG file ... but not:

    vips im_vips2tiff original.jpg new.tif:jpeg:100,tile:256x256,pyramid

    Even if I decrease jpeg quality from 100 to as low as 5, I got a tiff bigger than the original file ... and the image looks awful.

    What am I missing? What should I expect from "jpeg compressed tiffs"?

    Also, when do you expect the next release will be available? (with jpeg support)

    Cheers!

     
    • Ruven

      Ruven - 2009-08-31

      The command vips im_vips2tiff original.jpg new.tif:jpeg:100,tile:256x256,pyramid will give you a TIFF file with each tile encoded in JPEG. This can give you a much smaller file than an uncompressed TIFF, but it will always be bigger than a pure JPEG. What are the differences in size you are getting? It shouldn't be so much.

      The next version of the server will be ready soon. The code in SVN already contains new features such as exact CVT resizing, Zoomify protocol support and some memory and speed improvements etc. I'm not too sure about the normal JPEG support. I have some test code that works, but it is very slow. I'm also working on JPEG2000 support, but that will be for the release after this one ;-)

       
    • DGSL

      DGSL - 2009-09-01

      Thanks for your fast reply, Ruven:

      > What are the differences in size you are getting? It shouldn't be so much.

      Well, I am getting very different results depending on the original JPEG (the problem is that I do not understand what it depends on ... perhaps on the background?). I will show you some results, always setting JPEG quality at 100 (max value), with images taken from web:

      I have the feeling that for images with a more or less regular background (black or white), the final tiff size is quite small (similar or even smaller than original jpeg) :

      WHITE background:
      1213598 D.cantabrica.jpg
      1261665 D.cantabrica.jpg.jpeg.100.pyr.tif
      ... taken from http://www.farmalierganes.com/images/Dactylorhiza_sambucina_gr/Dactylorhiza_insularis/Dactylorhiza_cantabrica_SAT50170_Hs_Lu_Caurel_left-right-flower.JPG

      BLACK background:
      1467539 Staehelina.jpg
      731297 Staehelina.jpg.jpeg.100.pyr.tif
      ... taken from http://herbarivirtual.uib.es/imatges/118923.jpg

      But, for JPEGs taken at field with digital cameras, the result is quite different. And the problem is that most of our server uploaded images will be like those below.
      I have the feeling that in this kind of images there is not an homogeneous background. Could this be the reason?
      These are my results (tiff is always between 2-6 times greater than original jpeg):
      383516 Ria.jpg
      2201661 Ria.jpg.jpeg.100.pyr.tif
      299771 Suaeda.jpg
      662921 Suaeda.jpg.jpeg.100.pyr.tif
      311941 Triglochin.jpg
      1019069 Triglochin.jpg.jpeg.100.pyr.tif
      ... all taken from http://www.biga.org/Plantae/Galeria/Familias/Juncaginaceae/Triglochin/Triglochin_maritimum.html
      Can you get a smaller final size (reasonably good looking) with other im_vips2tiff conversion settings?

      > The next version of the server will be ready soon

      Great ... but can you state a deadline for "soon"? ;)
      I mean within 2009 or perhaps not?
      Anyway, regarding JPEG2000, does this also support pyramidal tiling? Is possible to use vips to generate jpeg2000 from tiff?

      By the way, I have already tried zoomify compatibility and it goes really fast. Superb!

      Did you know about other AJAX viewers based on zoomify? Perhaps you could grab some ideas (like scale measuring or label annotations) for IIPmooviewer from here:
      http://brainmaps.org/index.php?p=brain-maps-api

       
      • Ruven

        Ruven - 2009-09-01

        Have you tried a JPEG compression of about 95? 100 results in a much larger file size with no visible difference. The TIFFs will still be bigger than the JPEG because of the multi-resolution layers.

        There are no definite deadlines, but I hope to release the next version within a month or two.

        Yes, annotations and active regions are something I plan to include in the next version of iipmooviewer. There is already a scale in the current version. You need to give the pixels/mm to the IIP class constructor.

         
        • DGSL

          DGSL - 2009-09-02

          > Have you tried a JPEG compression of about 95? 100 results in a much larger file size with no visible difference

          Sure! I tried 100, 75, 50, 25, 10, 5 and 1, with all the images.
          The odd thing was that for those "non flat backgrounded" images all jpeg quality factors above 10 resulted in file sizes bigger than the original jpeg. And of course, below 10 the image quality was horrible.
          I posted the original images URLs so anyone could try im_vips2tiff, but I think it's not an error of mine. Any TIFF with jpeg compression is much bigger than the original JPEG when the image has not a big homogeneus portion (like a flat colored bacground). But in other case (for example an scanned text with white background), then compression is much more effective.
          I just would like somebody to confirm me this empirical assumption (hopefully with a theorical explanation), so I do not waste time trying impossible things out of my knowledge. ;)

          Regarding iipmoviewer, scale measure and annotations are great news ... maybe I ask something in another post

           
          • Ruven

            Ruven - 2009-09-02

            The JPEG encoded TIFFs will always be bigger than the original JPEGs (at a similar compression level). The multi-resolution structure adds a fair amount of overhead. If space is an important issue, the only solution is to try to find the lowest JPEG quality level you are happy with and use that.

             


Anonymous

Cancel  Add attachments





Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks