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.
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.
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...
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.
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?
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...
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?
For future reference, this discussion is now on Github: https://github.com/ruven/iipsrv/issues/255
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...
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?
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...
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...
Your images need to be tiled. You can find details on how to do this here: https://iipimage.sourceforge.io/documentation/images/
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?
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...
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.
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
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.
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!
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.
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
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...
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...
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
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; }
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 ...
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`
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.
You need to update your version of iipsrv to the latest Github code (https://github.com/ruven/iipsrv) for this to work. This will all be included in the forthcoming version 1.2 of iipsrv
It's probably being blocked because Mirador uses javascript to request the images and for this you need to have a CORS header set, so you should try setting CORS to "" (or just https://mirador-dev.netlify.app if you only want to allow the Mirador demo to work with your images)
Yes, that's the kind of thing. This manifest is even simpler: https://iiif.io/api/cookbook/recipe/0001-mvm-image/
You have to supply an IIIF presentation API manifest, not an IIIF image API json file. Does your content management system generate presentation manifests?
Running iipsrv from the command line on Windows now finally works. Use the latest development version from Github. This fix will be included in the forthcoming version 1.2 release. .\iipsrv.fcgi --bind "localhost:9000" Note that you may need to rename iipsrv.fcgi to iipsrv.exe to make it run
Look likes the new location for the Debian repository is here: https://salsa.debian.org/multimedia-team/iipimage/-/blob/master/debian/20-iipsrv.conf
Image Comparison of Ancient Mummy Portraits: The Appear Project
You just need to download and unzip the viewer files into any location your web server can access.
The svs format is based on TIFF, but includes a number of non-standard features that make it difficult to read. So, you will need to transcode your svs images to standard TIFF or JPEG2000 if you want to use it directly with iipsrv. I'll be adding OME-TIFF support soon, which could also be a good option for you.
It's not working because you are trying to do open index.html as a file (using your navigator's Open -> File) rather than as a web page. Connect via the URL for index.html - the URL will depend on where you have put this and on how Apache has been configured.
No, sorry, I haven't had a chance to add this functionality. I'll bump this up the list of priorities, though.
Yes, as you've already worked out yourself, you can point to any sub-directory within whatever you set as your filesystem_prefix, which in your case is /data/
FILESYSTEM_SUFFIX was only added recently and is not in version 1.1. It will be available in the future 1.2 release. Though, note that iipsrv can determine the file type of an image without using the suffix, so this functionality is only useful when you have images encoded in multiple formats in the same location. So, it's possible you don't need this. The kinds of paths like http://server/iiif/path_to_image.jp2 are technically not valid IIIF. iipsrv should redirect these with a 303 to the correct...
Glad it now works properly! A very Merry Christmas to you too!
but that can't be the solution, right? Indeed not! The iipimage-server package should be coherent with the rest of Xenial, so maybe you have some package mis-match somewhere? If your solution works, I would just keep it like this. One day you'll no doubt upgrade your distro, which will resolve it properly.
Yes, you need to upgrade to Ubuntu 20.04 to get iipsrv version 1.1 or you can just compile it yourself on 18.04 for now until you upgrade.
when the server has multiple cpu cores, there is an equal number of iipsrv instances iipsrv does threading internally for its various image processing routines through OpenMP, so this is probably what you are seeing here. when I start iipsrv with option "-F 10" from spawn-fcgi, 10 separate iipsrv instances are created When you use -F it's spawn-fcgi which does the delegation and load-balancing. Normally, the spawn-fcgi process should remain alive to handle this. If you want to start multiple instances,...
I'm not sure a Ubuntu-style EOL (I presume this is the kind of thing you are thinking of) makes sense for a particular version of iipsrv. Version 1.1 and future 1.x versions are and will be drop-in replacements for version 1.0, so in this sense iipsrv has on-going lifetime support. If you're looking for specific support, such as some kind of personalized paid support, please get in touch by email and we can look into how best to support your IIPImage deployment.
How are you starting the iipsrv process? If it's using something like Apache, then it will be the Apache user that will start iipsrv, so need to make sure your library path is added to that user's LD_LIBRARY_PATH
The Debian release is a fully open-source version and so Kakadu isn't available through this. If you have a Kakadu license and their source code, you should download the iipsrv source code and compile it yourself with the "--with-kakadu" flag. Otherwise, if you upgrade to the newly released Ubuntu 20.04, iipsrv version 1.1 is available, which includes support for JPEG2000 through the OpenJPEG library.
Which version of iipsrv are you using? First make sure you are using the latest 1.1 release. Also, what does it say in the iipsrv log file when you get the error?
There's still no 16 (or 32bit etc) output support in iipsrv, but it's something that will eventually be integrated. In the meantime, there are several forks you could try. The most up-to-date one to try is maybe this one: https://github.com/Cytomine-ULiege/iipsrv
This is fixed in the latest version on github: https://github.com/ruven/iipsrv
I see. I'll look into how best to add this kind of functionality. In the meantime, you can use your web server to modify the header on the fly. If you're using Apache, there are suggestions on how to do this here for example using Apach's "Header set" syntax: https://serverfault.com/questions/101948/how-to-send-content-disposition-headers-in-apache-for-files
It should be easy to add it as server-side directive like Cantaloupe's endpoint.iiif.content_disposition directive. How exactly are you looking to use this feature?
CVT requests use Content-Disposition inline with the filename set to the name of the TIFF or JP2 file. "Inline" allows the browser to display the image directly rather than as an "attachment", but the image can of course also be downloaded. There's currently no way to set Content-Disposition to "attachment".
Everything indeed seems to be there. Maybe there's some other redistributable that is required for Windows Server 2016? Have you tried with the previous release of iipsrv?
When you run from the command line, are you running it directly from the directory containing the executable and dlls? There should be libfcgi.dll, msvcp100.dll and msvcr100.dll as well as the executable iipsrv.fcgi. These should be all you need to run it.
The output JPEG image should have attached to it any ICC profile that has been embedded into the TIFF or JPEG2000 image. To test this, save the preview image using a command like this: .../iipsrv/?FIF=your_image.jp2&WID=200&CVT=jpeg Then check the resulting JPEG image using a command line tool such as jpeginfo or exiftool to see whether there is any metadata or ICC profile embedded. You can also just send me the output CVT JPEG if you prefer.
iipsrv 1.1 is available in Fedora 30 onwards as we can see from this build list, but seemingly not yet in EPEL, which is where CentOS sources the iipsrv package from: https://apps.fedoraproject.org/packages/iipsrv So, you'll have to either wait for EPEL to be updated, use a Fedora package file or build iipsrv 1.1 from source. Compilation is very straightforward - you'll just need to install the development packages for libtiff, libjpeg, zlib and openjpeg. You can find instructions here: https://...
Are you starting iipsrv through your web server (Apache)? What does the Apache (or whichever web server) error log say? Try perhaps starting iipsrv manually on the command line and pointing Apache to the this running instance to see what happens. By the way, is your version of iipsrv compiled by yourself or from a distro?
I'm using IIPMooViewer, do I have to change something in there? No, the version change shouldn't make any difference to IIPMooViewer. What does it say in the iipsrv log file when you get the 500 error?
Which fcgi-bin is the above refering to? Somewhere in a different set of documentation I read that if the fcgi-bin directory does not exist, to make it first, but it doesn't say where to put it. In the Visiomatic docs, the path is defined in the "Command" parameter as /var/www/fcgi-bin/ You can put the fcgi executable elsewhere, but to follow this example, you'll need to create this directory yourself, then simply copy the iipsrv.fcgi executable to this directory. You just need to make sure that...
After checking that it wasn't in use, I instead tried binding it to 127.0.0.1 on the same port and didn't get an error 127.0.0.1 would indeed have indeed been a better address for my example. You can check the log file in /tmp/iipsrv.log to see that it's started working properly. In order to access the IIPImage server I am going to need to use an FCGI enabled web server, so going to localhost:9000 in my browser after starting ippsrv from command line and binding the process to 127.0.0.1:9000 will...
If you follow the instructions on https://visiomatic.readthedocs.io/en/latest/server.html OpenLiteSpeed should start the iipsrv instance for you - you shouldn't need to start iipsrv from the command line. Where did you install iipsrv? Make sure that you have the correct path for your iipsrv.fcgi executable in the "Command" parameter of the External App section of the OpenLiteSpeed configuration. If this is correct and it's still not working after restarting OpenLiteSpeed, check what it says in the...
IPTC is usually stored in the XMP metadata stream, so it will be included. Exif is encoded differently and isn't currently supported in TIFF either. It's on the development roadmap, though!
In fact, XMP metadata is only currently extracted from TIFF files. It's enabled by default by the server. I'll look to get this working for JPEG2000 too, but OpenJPEG doesn't seem to provide an easy way to do this. There must surely be a way to do it, however!
It's not very clear what you are asking, but I'll try to reply as best I can: OpenJPEG development files found in system path These is essentially the openjpeg headers that are in the standard include path as defined by your OS. So, typically in /usr/include. iipsrv doesn't need the rest of the OpenJPEG source files - only the headers. Once compiled, the iipsrv executable is linked to the openjpeg library found in /usr/lib etc. If you compile your own version of OpenJPEG, you can use --with-openjpeg=/path/to/openjpeg/distribution...
iipsrv 1.1 released
The problem is caused by your TIFF image containing an extra resolution, which isn't in fact tiled. If you look at the output of tiffinfo you'll see that there are 9 resolution levels plus an extra image with description "Macro". So what happened is that iipsrv was expecting this final resolution to be tiled, but libtiff reports a bogus tile size for this final image, which caused the crash. I've added a fix that adds extra checking and avoids the crash - you can download the latest version here:...
Modify the ScriptAlias path directly in /etc/httpd/conf.d/iipsrv.conf
For information about images, see the documentation here: https://iipimage.sourceforge.io/documentation/images/ You can download a sample image here: http://merovingio.c2rmf.cnrs.fr/iipimage/PalaisDuLouvre.tif
The iipsrv-httpd-fcgi package should install the necessary config files for you. Did you restart Apache after installing? If not do this: sudo service restart httpd and iipsrv should now be running at the address: http://your.server/iipsrv For more details on installing on CentOS see this blog post: https://iipimage.sourceforge.io/2013/07/iipimage-now-an-official-fedora-package/
Good!
The XMP data is 62273 bytes, which is large, but still within the XMP spec. Your image doesn't crash on my setup, but I've just made a commit which adds an extra size check for XMP writing. Please try downloading the latest source code from github and let me know if this problem still occurs.
Looks like something in your XMP metadata is causing the problem. Could you send me your image BML_007-013.tif to test?
My tests are picking a random image and requesting a number of derivatives of the uncropped image with size set to full , a number with !3000,3000 and a number with !128,128. 1000 concurrent users is indeed quite extreme and the kind of requests you are doing are rather heavy on the server. For use with pan and zoom viewers, iipsrv's tile requests are highly optimized within the server and will scale more easily. FYI, our intention is to share as much as we can of our setup so this test can be replicated....
No matter how many Nginx workers I set up, 1 or 8 or 16, I always see 8 iipsrv processes: 1 parent and 7 children. I assume this number is tied to my processor cores, which is 8, correct? iipsrv has internal threading for it's various image processing routines, which indeed scales to the number of cores on your processor. However, there is currently only 1 thread that handles incoming requests (full request parallelization is on the TODO list!). To parallelize request handling, you need to spawn...
Let us know if this was indeed the problem and also what kind of throughput you manage to achieve.
A number of incompatible changes were made in Kakadu v7_A, so to compile you'll have to use the latest iipsrv source code from Github: https://github.com/ruven/iipsrv
At this point I'm tempted to remove the Docker factor and compile iipsrv directly in the AMI. Yes, that would be a good idea at this stage. Your iipsrv config looks fine. There are a bunch of NginX settings for FCGI you could look at, however. You could first try disabling all FCGI buffering within NginX by setting the fastcgi_buffering parameter to off and seeing how that affects things. Otherwise, you can enable buffers and play with the size parameters. There's fastcgi_buffer_size, fastcgi_buffers...
How exactly are you starting your iipsrv.fcgi instances? NginX won't start them automatically, so I presume you are using spawn-fcgi or a script of some kind? Also, as the goal here for you is to do load tests, reduce the number of iipsrv instances to a single one and test that first.
How are you getting the information? In general, if you perform some processing operation on the image (rotation, contrast change, resizing etc.) it won't change the underlying image metadata you receive through an IIP or IIIF request.
1.1 is not yet out, but URI_MAP is available in the current source code from Github: https://github.com/ruven/iipsrv Let me know if you have any issues with this feature.
The problem looks to be with Apache. You config file looks fine, but you said earlier that server-status gives "Server Version: Apache/2.4.18 (Ubuntu) mod_fastcgi/mod_fastcgi-SNAP-0910052141". Did you install mod_fastcgi manually yourself? There exist in fact 2 different FCGI modules for Apache. The Ubuntu package for IIPImage has mod_fcgid not mod_fastcgi as a dependency. Check the list in /etc/apache2/mods-enabled. There should be files called something like mod_fcgid.conf and iipsrv.conf inside....
OK, I just realized that you are using the wrong URL to connect. On Ubuntu, you should use: http://localhost/iipsrv/iipsrv.fcgi See this blog post for more information on how to use on Ubuntu: http://iipimage.sourceforge.net/2012/10/iipimage-now-an-official-ubuntu-package/
Did you restart Apache after installing the IIPImage server?
If you're using Apache 2.4, then the syntax has changed slightly for granting access to directories. So replace the 2 lines in the Apache configuration which read: Order allow,deny Allow from all with this: Require all granted Also if you are using the windows binary for iipsrv 1.0, then the URL will be http://127.0.0.1/fcgi-bin/iipsrv.fcgi This tutorial is from a many years ago - I'll do an updated one to reflect these changes.
You can find the contents of the 20-iipsrv.conf file here directly from the Debian package repository: https://anonscm.debian.org/viewvc/collab-maint/deb-maint/iipimage/trunk/debian/20-iipsrv.conf?view=markup It should install automatically, but if not, try creating the 20-iipsrv.conf file yourself
What parameters are you using to generate your image? Could you send me the image itself to test?
True, the Debian package description is misleading as their binary version does not include JPEG2000.
DZI images are images split into multiple Deepzoom tiles for use with a Deepzoom viewer. As such images are already split into JPEG tiles, you don't need to run this through iipsrv - as you say it already works correctly directly with OpenSeaDragon without the need for any additional server. If you want to use this image with iipsrv, then you will need to use the original TIFF image you used to generate the DZI tiles. If you don't have this anymore, you will need to reconstruct a single TIFF or JPEG2000...
Yes, you said you were using Kakadu to create these images, so you should be able to check using the Kakadu kdu_jp2info utility on the command line: kdu_jp2info -i 331724273_2.jp2 You will see an entry "palette box" in the output, which indicates use of a color palette. So, to identify all color-mapped images, just run this command on all your images and check for "palette box".
IIPImage does not require the use of cookies
It's not clear what you want "resolved" here. As I said previously, if you wish to use the commercial JPEG2000 codec, then you will need a paid license to remove the watermarking. If you don't require JPEG2000, then just use the standard iipsrv software.
OK, the watermark isn't being applied because the IIIF request is not a correct tile request, but in reality an arbitrary region request. It's asking for a region at position 2048,2048 with size 1972,646 to be exported with width 247px. The size 1972px is not exactly divisible by 256 and so isn't a tile. Also the export width of 247 doesn't correspond to any tile width. I don't know why your viewer is making such requests, but watermarking currently isn't applied to region requests with JPEG2000....
Can you try setting the logging level higher - like 5 or something, then restart iipsrv and try your above IIIF request and tell me what the log says? And you say this was compiled before your arrival. Perhaps the code was modified in some way by someone? Try compiling a fresh version using the official 1.0 version from the website and test that.
Glad it's now working! And yes, better to have iipsrv started by either systemd or Apache but not by both!