I am using iipsrv 1.3 (and kakadu 8.5) apache 2.4 the server log does not show anything strange, I thought at Disk IO at first, since the images are loaded from a NFS mount , then I tried using memcache but this was happening as well. this is happening only when loading the small images for the mirador navigation, or when loading a group of thumbnails, what I noticed is that this is happening for 2 or 3 images out the first 10 requested in the logs the images "37204602180215904973301709441820852317.jp2"...
What version of iipsrv are you running? And could you copy and paste the section of the log file when this happens? This kind of thing can also sometimes happen due to reasons unrelated to iipsrv, such buffering in disk input/output or at the front-end web server level. So check also your web server logs for anything abnormal.
Hallo I am using IIP image server compiled with kakadu to serve jp2000 from apache I am serving the images to mirador viewer, when mirador loads the initial thumbnail list (all thumbs are +-3KB) the thumbs are loaded in 150-300ms except a few, 3 or 4 that are loaded in +-1200ms , these are not sequential but like the 4th 7th en 9th . I tried to use memcached but no real improvement Where can the issue be ? This is my configuration: FcgidInitialEnv MAX_IMAGE_CACHE_SIZE "100" FcgidInitialEnv JPEG_QUALITY...
Alpine Linux
You can create the tiled pyramid TIFFs using vips in the usual way. However, JPEG doesn't support alpha channels, so make sure you save your TIFF either using lossless compression such as Deflate or LZW like this: vips tiffsave source_image output_image.tif --tile --pyramid --compression deflate --tile-width 256 --tile-height 256 Or if you want lossy compression, TIFF supports WebP compression which does allow transparency. You can then use your TIFF image through OpenSeaDragon's Deepzoom API using...
Hi, What is the best way of creating pyramids of images with transparent backgrounds? Is there a utility that can create pyramidal pngs? What would the URL syntax be for reading a pyramidal png in openseadragon? Thanks
By the way, I tried with a few images on the Chronicling America site and they all seem to work, so maybe it is indeed a problem at your end. Thank you, sir, for the information!
Again, I'm very sorry to inconvenience you, but thank you very much for your time and attention. No problem. By the way, I tried with a few images on the Chronicling America site and they all seem to work, so maybe it is indeed a problem at your end.
I'm afraid that you are correct that this is not the right place to ask. I'm sorry for the mistake! I mistakenly thought this was affiliated with OpenSeaDragon. Again, I'm very sorry to inconvenience you, but thank you very much for your time and attention. --Charlie Jack
Maybe this is the wrong place to post this, and if so, I apologize in advance, but here goes nothing: I'm afraid that you are correct that this is not the right place to ask. From what I can see, the Library of Congress does not use either the IIPImage server or viewer. The software they use is the OpenSeaDragon viewer, so you could try asking for help on their help forums.
Maybe this is the wrong place to post this, and if so, I apologize in advance, but here goes nothing: I'm getting a similar error message when I attempt to access the Library of Congress's Chronicling America newspaper database in the customary way (i. e., by clicking links on a blog): Unable to open [object Object]: HTTP 0 attempting to load TileSource I get a similar message when I try to access Chronicling America by entering their website. However, I can usually get the document (i. e., the newspaper...
For the moment, the only way to use images stored remotely (such as on cloud storage) is to mount the remote host so that the images are available to IIPImage on the local file system. For Amazon S3, for example, there's a tutorial on how to do this using NFS. Although this kind of solution can be made to work with IIPImage, be aware that this will necessarily be much slower than having the images and server hosted together. I've been meaning to look into the feasibility of adding this functionality...
Hi Ruven, is a server configuration possible that allows me to load and display an image by supplying an image URL? Thanks Christian
iipsrv 1.2 released
If you had to do anything differently or have any suggestions on how to make the instructions clearer, please let me know.
Yes for the most part I followed the instructions at that URL. Some of the instructions I struggled a bit with because I really didn't know what I was doing or what I was looking for... Probably made perfect sense to a system's person but not to a little ole data application programmer like me :). But my tests on the customer's system after installing the new iipsrv.fcgi seemed to work so I guess I got did it right...
I'm glad it's now working! Did you rebuild using the instructions here: https://iipimage.sourceforge.io/documentation/server/windows or did you have to change anything?
I ended up having to rebuild the IIPSrv package for 2019. Not an easy feat for someone who's never done anything like this before. The new package is working.
One additional bit of info that might help. I did try IIPImage version 0.99 on the site's 2019 server and that one DID give me the "IIPImage Server Version 0.99 Project Home Page: http://iipimage.sourceforge.net by Ruven Pillay" screen when I tried http://localhost/fcgi-bin/iipsrv.fcgi URL. Unfortunately, our software needs - at the very least - version 1.0 of your software to work and when I tried version 1.0 it too gave me the internal 500 error.
Well I did that and even rebooted the system but when I tried the URL http://localhost/fcgi-bin/iipsrv.fcgi?FIF=C:\NEWLADWEB\Benedict.tif&WID=500&CVT=JPEG still got the Internal 500.0 error but this time nothing was written into the iipsrv.log file for today. I can't even get the simple info screen (see attachment). I even tried re-adding the iipimage application in IIS before the reboot -- nada.
The QUERY_STRING is whatever is in your URL after the http://localhost/fcgi-bin/iipsrv.fcgi part. So, as you haven't made a requested for an image or anything, you should get back an info message in your browser. There doesn't seem to be any error in the iipsrv log file and iipsrv seems to be working, so try increasing the VERBOSITY parameter to 6 and do a full request with an image like http://localhost/fcgi-bin/iipsrv.fcgi?FIF=image.tif&WID=500&CVT=JPEG Exchange "image.ti" for your own image of...
Yes I did try version 1.1 -- it too gave me the 500.0 internal error. The iipsrv log: Fri Aug 11 17:41:44 2023 IIPImage Server. Version 1.1 *** Ruven Pillay ruven@users.sourceforge.net *** Verbosity level set to 1 Running in FCGI mode Setting maximum image cache size to 10MB Setting filesystem prefix to '' Setting default JPEG quality to 90 Setting maximum CVT size to 3000 Setting HTTP Cache-Control header to 'max-age=86400' Setting 3D file sequence name pattern to 'pyr' Setting Cross Origin Resource...
I don't know much about IIS either, but is there any more information in the iipsrv or IIS log files? And you say you're using iipsrv 1.0. Have you tried with version 1.1?
Hi. First, I am not a systems nor an IIS expert by any means imaginable: I know just enough to get myself into trouble :) We have a customer who's been using IIPImage 1.0 for several years now on a Windows 2012 R2 server. They are migrating to a new machine: Windows 2019 with IIS 10.0. Unfortunately, when I try to use the /fcgi-bin/iipsrv.fcgi URL I get an internal 500 error. I followed the same installation instructions I used to getting IIPImage 1.0 working on my own PC: Windows 10 Pro with IIS...
For future reference, this discussion is now on Github: https://github.com/ruven/iipsrv/issues/255
Hi @ruven Hope everything is fine. Could you please help on a above mentioned question? Also, wantedto know, do you have a discord or slack channel, for faster communication? Thanks in advance, Rafael
Thank you so much Ruven for your quick replies!
Glad it's now working properly! The image processing functions are multi-threaded and use OMP automatically, but the main event loop is not. One iipsrv instance should be enough in most cases, but if you want to start multiple iipsrv workers, you'll need to do this via the mechanism you are using to start iipsrv. How exactly are you running iipsrv itself? A good option here is to use supervisor to start and handle the iipsrv instances. You can see more details on how to do this here: https://iip...
Yes, Ruven. Thank you very much. I removed the old library and now it works fine! Just one more question: I see the iipsrv.fcgi process only runs on 1 vCPU (out of 8 available). It's correct? Depends on what? I set OMP_NUM_THREADS to 8 for iippsrv. Nginx created 8 worker process.
Yes I know, but I needed to see the performance differences between OpenJPEG and Kakadu. Patience...
No, you will need the Kakadu source code to be able to build it as iipsrv requires some Kakadu header files. But if you just need JPEG2000 support, OpenJPEG works fine - it's just slower than Kakadu, but still perfectly usable.
Looks like you compiled iipsrv against a different version of JPEG. Make sure you don't have an old version of libjpeg installed together with libjpeg-turbo. Your ldd command above shows that iipsrv is linking to this version: libjpeg.so.62 => /lib64/libjpeg.so.62 (0x00007efdc3618000) Are there any other libjpeg.so library files installed?
Another question: To use the Kakadu libraries is it necessary to have their source codes or is it possible to hook the libraries in some way? * libkdu_a80R.so * libkdu_jni.so * libkdu_v80R.so Thank you at
Thanks Ruven, changing the size I obtained a full log and I see an error: Full Request is IIIF=images/smithsonian-apollo11/NASM-001-tiled.tif/full/600,/0/default.jpg [1/1]: Command / Argument is IIIF : images/smithsonian-apollo11/NASM-001-tiled.tif/full/600,/0/default.jpg IIIF handler reached IIIF :: URL decoded to images/smithsonian-apollo11/NASM-001-tiled.tif/full/600,/0/default.jpg FIF handler reached FIF :: URL decoding/filtering: images/smithsonian-apollo11/NASM-001-tiled.tif => images/smithsonian-apollo11/NASM-001-tiled.tif...
Your TIFF image looks fine to me and works correctly with the latest version of iipsrv. I get the correct image when I use the same request. From the log, iipsrv is only sending a HTTP 304 response to this particular request. Try doing shift-reload in your browser to force iipsrv to send a new image. Maybe there was something old in your cache. Or just ask for a different size: fcgi-bin/iipsrv.fcgi?IIIF=images/smithsonian-apollo11/NASM-001-tiled.tif/full/500,/0/default.jpg You say that you are using...
Hi Ruven, in attachment the image. The log of request: Full Request is IIIF=images/smithsonian-apollo11/NASM-001-tiled.tif/full/max/0/default.jpg HTTP Header: If-Modified-Since: Wed, 15 Mar 2023 07:30:05 GMT [1/1]: Command / Argument is IIIF : images/smithsonian-apollo11/NASM-001-tiled.tif/full/max/0/default.jpg IIIF handler reached IIIF :: URL decoded to images/smithsonian-apollo11/NASM-001-tiled.tif/full/max/0/default.jpg FIF handler reached FIF :: URL decoding/filtering: images/smithsonian-apollo11/NASM-001-tiled.tif...
In terms of input: TIFF and JPEG2000. TIFF needs to be encoded with tiles and a multi-resolution (pyramid) structure. Any JPEG2000 can work, but you will see a significant improvement in speed if you follow the encoding recommendations on the IIPImage website. For output, JPEG, PNG and WebP. If you are getting corrupted output, please show me the section of the iipsrv log file that is written when this happens or send me a copy of the input TIFF image and the exact request you are using, which produces...
Hi Ruven, I'm a colleague of Massimiliano and I need more detailed information on compatible input and output formats. In input it seems to us that it is possible to use only TIFF (tiled but evidently created in a specific way) and JP2. In output we could only generate PNG, while with other formats (JP2/JPG/TIF) we get only a white square (JPG) or a message "IIIF :: unsupported output format" (JP2/TIF). Given that we are using RHEL8 and the libraries we have currently used in compiling are these......
Thank you Sir, I converted the image with ImageMagick convert NASM-001.tif -define tiff:tile-geometry=256x256 -compress jpeg 'ptif:NASM-001-tiled.tif' and now apparently I don't see any error in the log file but from the browser I see a small white square on a black background. thanks again
Your images need to be tiled. You can find details on how to do this here: https://iipimage.sourceforge.io/documentation/images/
Hi all, I installed iip 1.2 on RHEL8 behind nginx but when I process TIF immage I get this error: "TPTImage :: TIFF error: Can not read tiles from a stripped image" Sending HTTP 404 Not Found Total Request Time: 796 microseconds image closed and deleted Server count is 1 Here is the configuration: VERBOSITY=5 LOGFILE=/var/log/iipsrv.log MAX_IMAGE_CACHE_SIZE=0 JPEG_QUALITY=80 MAX_CVT=5000 FILESYSTEM_PREFIX=/usr/share/nginx/html/ IIIF_VERSION=3 ldd iipsrv.fcgi linux-vdso.so.1 (0x00007ffea19f3000) libwebpmux.so.3...
Ok, will try with newer version. Perhaps I was mislead by an old example. Will let you know what the outcome is (but first a short holiday)
Maybe it's because you're targeting specifically the gcc-4.9 docker build? This is very very old which will run inside an old version of Debian. Try targeting something more recent. Indeed, is there a reason to build this in a gcc docker environment? Why not just compile in a normal Debian or Ubuntu docker that matches the one you are using for your production environment?
We are not succeeding in our effort to compile iipimage against libpng12.so We tried several constructs and finally removed all the stuff that could possible interfere with the libpng version. But the ldd still shows libpng12.so.0 => not found in our minimal setup. Attached the build log. For the moment we go for the build with --disable-png so we can continue. But is there a way to compile iipimage against libpng16 instead of libpng12?
I'm a little bit confused. We build the iipimage on a pre-stage container with the official gcc docker image so we think this independent on what is following. Or am I wrong about that? This in the docker file of the pre-stage container FROM gcc:4.9 as build RUN mkdir /iipimage RUN mkdir /kakadu COPY docker/iipimage /iipimage/ COPY docker/kakadu /kakadu/ WORKDIR /iipimage RUN apt-get update RUN apt-get install libtool RUN apt-get install libpng-dev RUN sh ./autogen.sh RUN ./configure --with-kakadu=/kakadu/v6_4_1-01203N...
It looks like it's because in your Docker file you do an apt-get update after building iipsrv. iipsrv's configure occurs at step 10 and then later on you do this: Step 39/125 : RUN apt-get update && apt-get install -y libmagickwand-dev libjpeg-dev libpng-dev --no-install-recommends && rm -rf /var/lib/apt/lists/* This bumps libpng-dev up to version 1.6 as you can see later in your build log: 2023-02-15T08:22:57.5231623Z libjpeg-dev is already the newest version (1:2.0.6-4). 2023-02-15T08:22:57.5232859Z...
Tried again with the RUN apt-get install libpng-dev but the result is the same. Looks like the package is already present with the latest version 1.6.37 Attached the build logs. Also the ldd shows libpng12.so.0 => not found I am not an expert but the libs on Debian Bullseye have names like libpng16.so.0 ....perhaps is that the cause that the linked library is not found ?
We also applied --disable-png and now we have IIPImage Server Version 1.2 so that's fine with us. But if there is a solution for the libpng problem that would be nice. Some suggest that we should install the libpng12 seperately besides the 16 version.
Strange. Try explicitly installing libpng-dev then re-running ./configure and make: RUN apt-get install libpng-dev If it still doesn't work, what is the full output of iipsrv's configure script.
We have %>libpng-config --version shows 1.6.37 Looks like the libraries are in /usr/lib/x86_64-linux-gnu/ with a version 16 number like libpng16.so -> libpng16.so.16.37.0 etcetera The ldd shows a not found off course ldd iipsrv.fcgi linux-vdso.so.1 (0x00007ffd2050e000) libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007fbb94c02000) libpng12.so.0 => not found libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fbb94be5000) libkdu_v64R.so => /lib64/libkdu_v64R.so (0x00007fbb94922000) libpthread.so.0...
We have %>libpng-config --version shows 1.6.37 Looks like the libraries are in /usr/lib/x86_64-linux-gnu/ with a version 16 number like libpng16.so -> libpng16.so.16.37.0 etcetera The ldd shows a not found ldd iipsrv.fcgi linux-vdso.so.1 (0x00007ffd2050e000) libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007fbb94c02000) libpng12.so.0 => not found libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fbb94be5000) libkdu_v64R.so => /lib64/libkdu_v64R.so (0x00007fbb94922000) libpthread.so.0 =>...
Is libpng not installed in a standard location? What is the output of ldd on the iipsrv.fcgi binary: ldd iipsrv.fcgi Otherwise, just disable png as you did with libwebp: --disable-png
This solved the webp issue and it compiles. But the server won't start with the message ./iipsrv.fcgi -v error while loading shared libraries: libpng12.so.0: cannot open shared object file: No such file or directory. Looks like we're missing something.
This solved the webp issue and it compiles. Thanks for your support.
Thanks. This solved the webp issue and it compiles. One curious thing: when I view the version info at /fcgi-bin/iipsrv.fcgi it still shows 'Version 1.1' I verified if I had made a mistake with the upgrade but that was not the case. I also see in the configure this version wich looks ok to me. PACKAGE=fcgi VERSION=2.4.0
Thanks. This solved the webp issue and it compiles. One curious thing: when I view the version info at /fcgi-bin/iipsrv.fcgi it still shows 'Version 1.1' I verified if I had made a mistake with the upgrade but that was not the case. I also see in the configure this version wich look ok to me. PACKAGE=fcgi VERSION=2.4.0
From your build log, it looks like you are running Debian Jessie, which was released in 2015, so it is indeed rather old! Your version of libwep will be equally old, so if you don't need WebP support, just disable it by adding --disable-webp to the end of the ./configure command or uninstalling the libwebp-dev package.
Although I think it is not needed I added RUN apt-get install libwebp-dev But that didn't make any difference. The complete build log is attached and as you can see is libwebp the latest version
Looks like a problem with libwebp. Can you give me the output of the ./configure command? Did you install libwebp-dev? It should, in any case, disactivate WebP support if the libraries are not there. Or is your version of libwep also 10 years old!
Fetched the code from git and looks like the xmp version is fixed. But another issues arises that may not be related to kakadu as far as I can see. MT WebPCompressor.o -MD -MP -MF .deps/WebPCompressor.Tpo -c -o WebPCompressor.o WebPCompressor.cc WebPCompressor.cc: In member function 'virtual unsigned int WebPCompressor::Compress(RawTile&)': WebPCompressor.cc:183:34: error: 'WebPMemoryWriterClear' was not declared in this scope WebPMemoryWriterClear( &writer ); ^ Makefile:471: recipe for target 'WebPCompressor.o'...
Very nice. I can check it next week and let you know
Yes, that's kinda an old version. From over 10 years ago I think! The metadata XMP code won't work with your version of Kakadu, so to make sure it compiles I've just committed a fix that adds an extra version check. If you check out the latest version, it should now work.
We have overcome the libtool issue but next is a failure in the kakadu. I'm not sure which versions are supported but we use version v6_4_1-01203N which is off course an old one. It does serve our purposes for many years so we hope it can live on for a while.... This is the errror in the log DHAVE_STRERROR=1 -I. -fopenmp -I/kakadu/v6_4_1-01203N/managed/all_includes/ -I. -I../fcgi/include -I../fcgi -std=gnu++0x -g -O2 -MT KakaduImage.o -MD -MP -MF .deps/KakaduImage.Tpo -c -o KakaduImage.o KakaduImage.cc...
Maybe you need to make sure the necessary autoconf tools such as libtool is installed? RUN apt-get install libtool I guess it works with version 1.1 because that is a full release and you don't have to run autogen.sh before ./configure
We try to compile the github version on kubernetes container with gcc version 10.2.1 20210110 (Debian 10.2.1-6) with Kakadu support Our Docker looks like this FROM gcc:4.9 as build RUN mkdir /iipimage RUN mkdir /kakadu COPY docker/iipimage /iipimage/ COPY docker/kakadu /kakadu/ WORKDIR /iipimage RUN sh ./autogen.sh RUN ./configure --with-kakadu=/kakadu/v6_4_1-01203N Compilations fails with this log: Automatically preparing build ... Warning: autoreconf failed libtoolize being run by autoreconf is...
Hello Ruven and thanks a lot for the reply. We noticed that images with url that contains /full/full are downloaded without watermarks image url, containing /!280,180/0/default.jpg in the url, are loading with a watermark.
So, if I've understood correctly, you have IIPImage supplying an image to your PHP process, which then converts it into PDF? Is that correct? Have you checked that the images from IIPImage have the watermark?
The IIPImage server should already be doing what you suggest. On a first request by a client, the full processing chain is run and the output is stored by Memcached. A subsequent request by the same client with a HTTP_IF_MODIFIED_SINCE header will result in the server replying with a HTTP 304 Not Modified header with no TileManager or CVT process being run. If a different user now makes the exact same request, the server will fetch the result from Memcached and return that if it exists. If not, it...
Hello, we are using IIPimage. the system generates a PDF file using PHP. but when downloading a PDF, the watermark is not appearing on the PDF, but should. Could you please help on this? Thanks
Hello everyone, This explanation was very insightful, thanks. I do have a question I haven't been able to answer. What is the rationale for using the processed and compressed tiles stored in memory by memcached exclusively when the HTTP_IF_MODIFIED_SINCE header is present in the request header? Please correct me if I'm wrong. My understanding is that the HTTP_IF_MODIFIED_SINCE header is only sent in a request header when a resource has previously been accessed by a given client. In context, this...
The Debian package in fact supports 2 different ways to start iipsrv and you should one or the other. The first way is by having Apache (or Lighttpd) start and manage iipsrv automatically for you. In this case, the file /etc/apache2/mods-available/iipsrv.conf will be used. The 2nd way is via systemd. In this case, the configuration options are provided through /etc/default/iipsrv and you can start and manage the process independently of any web server by using the systemctl command. Systemd support...
Hello, Ruven, No, the file /etc/default/iipsrv was not created automatically during the Debian package installation. So, we manually created the file /etc/default/iipsrv, with the four configuration options that you specified, and that seems to have fixed the problem; iipsrv.service now starts properly. Thanks! A couple of quick questions, for future reference: We also have the IIPImage server installed, successfully, on a Debian 9 (stretch) server, and that server does not have a file /etc/default/iipsrv....
Does the file /etc/default/iipsrv exist? If not, you need to create it and put the parameters you want to give to iipsrv. For example: VERBOSITY=5 LOGFILE=/var/log/iipsrv.log MAX_CVT=5000 URI_MAP="iiif=>IIIF" Then try to restart the iipsrv.service script
Hello, We, by executing 'apt-get install iipimage-server' while logged in as 'root', installed the Debian bullseye package (https://packages.debian.org/bullseye/iipimage-server), however the iipsrv service does not start, and 'systemctl status iipsrv.service' and 'journalctl -xe' tell us the following: systemd[1]: iipsrv.service: Failed to load environment files: No such file or directory systemd[1]: iipsrv.service: Failed to run 'start' task: No such file or directory systemd[1]: iipsrv.service:...
Surprinsigly, that worked. Only the "fastcgi_param REQUEST_URI $request_uri;" was missing from my config. It is textbook from the doc but I completely missed that line. Thank you :)
OK, so your Nginx config should look something like this: location /iiif { fastcgi_pass localhost:9000; fastcgi_param PATH_INFO $fastcgi_script_name; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param QUERY_STRING $query_string; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_param SERVER_PROTOCOL $server_protocol; fastcgi_param REQUEST_URI $request_uri; fastcgi_param HTTPS $https if_not_empty; }
OK, so your Nginx config should look something like this: location / { fastcgi_pass localhost:9000; fastcgi_param PATH_INFO $fastcgi_script_name; fastcgi_param REQUEST_METHOD $request_method; fastcgi_param QUERY_STRING $query_string; fastcgi_param CONTENT_TYPE $content_type; fastcgi_param CONTENT_LENGTH $content_length; fastcgi_param SERVER_PROTOCOL $server_protocol; fastcgi_param REQUEST_URI $request_uri; fastcgi_param HTTPS $https if_not_empty; }
Apache is the config I'm switching from. This is all with nginx.
Did you remove the Apache rewrite rules for "iiif"? When you use the iipsrv URI_MAP function, you don't need to do any Apache re-writing, so remove these 2 lines from your Apache config: RewriteRule ^iiif/$ /iipsrv/iipsrv.fcgi [L] RewriteRule ^iiif/(.+)$ /iipsrv/iipsrv.fcgi?FIF=$1 [L] However, you do need to let Apache know that requests to /iiif/ should be handled by iipsrv, so add this line: ScriptAlias /iiif/ "/usr/lib/iipimage-server/iipsrv.fcgi" Now restart Apache and it will hopefully all ...
I don't know if it has to do with anything, but the log file here says that it's running in standalone mode compared to my current working config where it's running in FCGI mode. What could trigger that ?
Version is 1.1. The said line is there, here is the beginning : IIPImage Server. Version 1.1 Ruven Pillay ruven@users.sourceforge.net Verbosity level set to 6 Running in standalone mode on socket: 127.0.0.1:9000 with backlog: 2048 Setting maximum image cache size to 10MB Setting filesystem prefix to '/images/' Setting default JPEG quality to 90 Setting maximum CVT size to 2000 Setting HTTP Cache-Control header to 'max-age=86400' Setting 3D file sequence name pattern to 'pyr' Setting Allow Upscaling...
Which version of iipsrv are you using? Can you send me the beginning of the log file with the initialization information? You should see a line like: Setting URI mapping to iiif=>IIIF. Supported protocol: IIIF`
Sorry I forgot to include the content of the log file. I skipped some lines to make it shorter. https://myiip.com/iiif/?FIF=image.jp2&wid=2000&cvt=jpeg : Initialisation Complete. <-----------------------------------> Full Request is FIF=image.jp2&wid=2000&cvt=jpeg [1/3]: Command / Argument is FIF : image.jp2 FIF handler reached FIF :: URL decoding/filtering: image.jp2 => image.jp2 FIF :: Image cache initialization FIF :: JPEG2000 image detected FIF :: Created image FIF :: Image dimensions are 5280...
Hi, Some time has passed and we are changing from apache to nginx. Everything works fine but one thing : the URI_MAP parameter. This is working : https://myiip.com/iiif/?FIF=image.jp2&wid=2000&cvt=jpeg This is not : https://myiip.com/iiif/image.jp2 I know it is not valid IIIF but it is not the final URL, just a test to see if it is working. On apache, adding the URI_MAP parameter was enough to get rid of the "?FIF=" and "&wid=2000..." parts but not with nginx (or else I'm not doing it correctly)....
It works great!
That sounds awesome! Can't wait to test! Thanks!
OK, this functionality is now available in the latest iipsrv source code on Github (https://github.com/ruven/iipsrv). Note that it only works for Kakadu. The OpenJPEG library does not yet provide the functionality to do this.
