ruven / iipsrv

iipsrv is an advanced high-performance feature-rich image server for web-based streamed viewing and zooming of ultra high-resolution images.
https://iipimage.sourceforge.io
GNU General Public License v3.0
292 stars 115 forks source link

[question] jpg support #251

Closed damonsson closed 2 months ago

damonsson commented 1 year ago

I'm using loris-imageserver to show .jpg images. Loris is not maintained from 2 years. I'm looking for something new, which is maintained.

I checked this project, but biggest problem is that just support tiff and jpeg2000. I have 20.000.000 images, and it's not possible to convert all images to this format, because of too high size image and dynamic behavior to images on my service. My images have not more than 3000x3000 resolution, so I don't need this extra performance which give tiff or jpeg2000.

My question is, how hard will be to implement .jpg support in this project? I can do simple things in C/C++ but more like student on his first year. Is it worth to try? Maybe process how iipsrv works totally not allow to serve .jpg files?

ruven commented 1 year ago

It shouldn't be too hard. The reason it has never been implemented in iipsrv is because reading directly from JPEG is very slow compared to TIFF or JPEG2000, especially for large images.

If you want to try something out, take a look at the example for OpenJPEG: https://github.com/ruven/iipsrv/blob/master/src/OpenJPEGImage.cc. There are essentially 3 main functions you would have to define:

  1. loadImageInfo() - load all metadata from JPEG file
  2. getTile() - extract an image "tile"
  3. getRegion() - extract a region

2 and 3 will essentially be the same in the case of a non-tiled non multi-resolution format, so it should be straightforward to get something rudimentary working.

ruven commented 2 months ago

I just added the functionality to directly read JPEG images in this commit: https://github.com/ruven/iipsrv/commit/ea8c7c5b096ab3cccfe23ad015db013a0d9c7511. It should be quite efficient if your images are not too large.