iipsrv is an advanced high-performance feature-rich image server for web-based streamed viewing and zooming of ultra high-resolution images.
Home Page: https://iipimage.sourceforge.io
License: GNU General Public License v3.0
It would be great to support the new IIIF 2.0 syntax and description. The URL structure hasn't changed significantly, and the JSON information is structured differently but is no harder to build.
The documentation: http://iiif.io/api/image/2.0/
When a request is made to IIP, and any of the FCGI parameters "QUERY_STRING", "SERVER_PROTOCOL", "HTTP_HOST", or "REQUEST_URI" are not set, IIP will segfault with no useful error message.
Two changes need to be made to fix this issue:
Line 454 in 9ebed35
Line 491 in 9ebed35
fastcgi_param SERVER_PROTOCOL $server_protocol;
fastcgi_param REQUEST_URI $request_uri;
should also be present.
We're deploying IIPImage in a RHEL environment and would prefer to use yum to install iipsrv rather than building from source.
We would like to make use of the IIIF functionality, but the package hasn't been updated since the original announcement
What would it take to get the Fedora package updated? It looks like @trasher did a lot of the original work to create the package.
We are using Open layer to display JP2 images via the Zoomify protocol. On the server side we have Apache2 and the latest version of IIPSrv (compiled just a few days ago from github) through fcgi.
Most of the times the zoomify tiles display correctly in the browser. But from time to time OpenLayer will show broken tiles/images. A typical scenario is that all four tiles fail. One with a 500 error and the three others with net::ERR_EMPTY_RESPONSE (in Chrome). I paste the corresponding log below.
All other non iipsrv requests made to Apache by the web page always return a valid response. This is why I'm thinking the issue might be with IIPSrv (or the way it is configured).
In the log below you can see the 4 requests. The first two and the fourth are terminated, The second (which returns a 500 error tot he browser) is probably crashing while handling the tiles. Note that at the time of execution I had two IIPSrv processes running in parallel.
Have you seen this before? I'm quite puzzled by the terminated requests and wondering if the cause is within IIPSrv or in Apache.
Thanks in advance for any hint about what's going on here.
Caught Terminated signal. Terminating after 2 accesses
Mon Aug 17 23:42:01 2015
<----------------------------------->
Caught Terminated signal. Terminating after 2 accesses
Mon Aug 17 23:42:01 2015
<----------------------------------->
<----------------------------------->
Mon Aug 17 23:42:07 2015
IIPImage Server. Version 1.0
*** Ruven Pillay <[email protected]> ***
Verbosity level set to 10
Running in FCGI mode
Setting maximum image cache size to 256MB
Setting filesystem prefix to '/vol/[...]'
Setting default JPEG quality to 75
Setting maximum CVT size to 5000
Setting HTTP Cache-Control header to 'max-age=86400'
Setting 3D file sequence name pattern to '_pyr_'
Setting max quality layers (for supported file formats) to 10
Setting up JPEG2000 support via Kakadu SDK
Initialisation Complete.
<----------------------------------->
Full Request is zoomify=jp2/test.jp2/TileGroup0/1-1-0.jpg
[1/1]: Command / Argument is zoomify : jp2/test.jp2/TileGroup0/1-1-0.jpg
Zoomify handler reached
FIF handler reached
FIF :: URL decoding/filtering: jp2/test.jp2 => jp2/test.jp2
FIF :: Image cache initialization
FIF :: JPEG2000 image detected
FIF :: Created image
FIF :: Image dimensions are 3666 x 3479
FIF :: Image contains 3 channels with 8 bits per channel
FIF :: Image timestamp: Tue, 04 Nov 2014 15:16:21 GMT
FIF :: Total command time 508 microseconds
Zoomify :: Tile request for resolution:1 at x:1, y:0
JTL handler reached
TileManager :: Cache Miss for resolution: 1, tile: 1
TileManager :: Cache Size: 0 tiles, 0 MB
Caught Terminated signal. Terminating after 0 accesses
Mon Aug 17 23:42:07 2015
<----------------------------------->
Since some resolutions are present in the jpeg2000 file or pyramid tiff,
one could add the attribute sizes in the info.json
cf. http://iiif.io/api/image/2.0/#image-information
That would make the server usable for level-0-clients.
The Readme says:
Detailed class descriptions (generated using doxygen) are available in the
doc subdirectory
But these were removed by 4cc076b
I understand that I could compile them myself with doxygen, but I just have a casual interest, and I'd like to see the docs before I decide between using IIP or something like Loris
Hi, trying to compile the code of last master (commit 0877fd8) . I'm having this error:
g++ -DPACKAGE_NAME="iipsrv" -DPACKAGE_TARNAME="iipsrv" -DPACKAGE_VERSION="1.0" -DPACKAGE_STRING="iipsrv\ 1.0" -DPACKAGE_BUGREPORT="[email protected]" -DPACKAGE_URL="" -DPACKAGE="iipsrv" -DVERSION="1.0" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=".libs/" -DHAVE_GLOB_H=1 -DHAVE_TIME_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -DHAVE_LOG2=1 -DHAVE_SETENV=1 -DHAVE_EXT_POOL_ALLOCATOR_H=1 -DHAVE_UNORDERED_MAP=// -DHAVE_TR1_UNORDERED_MAP=// -DHAVE_NAMESPACES=// -DHAVE_EXT_HASH_MAP=// -DHAVE_JPEG=1 -DHAVE_LIBMEMCACHED_MEMCACHED_H=1 -DHAVE_MEMCACHED=1 -DHAVE_TIFF=1 -DNPROCS=1 -DHAVE_PNG_H=1 -DHAVE_STREAMBUF_CHAR_TYPE=1 -DHAVE_LIBNSL=1 -DHAVE_FPOS=1 -DHAVE_SYS_SOCKET_H=1 -DHAVE_NETDB_H=1 -DHAVE_NETINET_IN_H=1 -DHAVE_ARPA_INET_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_UNISTD_H=1 -DHAVE_FILENO_PROTO=1 -DHAVE_STRERROR=1 -I. -I. -m64 -std=gnu++0x -m64 -MT Task.o -MD -MP -MF .deps/Task.Tpo -c -o Task.o Task.cc
Task.cc: In static member function âstatic Task* Task::factory(const string&)â:
Task.cc:37:64: error: âtransformâ was not declared in this scope
Task.cc: In member function âvirtual void CMP::run(Session_, const string&)â:
Task.cc:315:67: error: âtransformâ was not declared in this scope
make[1]: *_* [Task.o] Error 1
make[1]: Leaving directory `/home/archivio/tomcat/software/iipimage/iipsrv-svn/src'
make: *** [all-recursive] Error 1
Should mention running ./autogen.sh before ./configure and make
Have anyone tried to build iipsrv with Intel's Integrated Performance Primitives?
It could give us a major speed boost.
On requesting a tile, incorrect and seemingly random tiles (at least to me) are being returned from the server.
Using a tiled tif (made with ImageMagick use the guide on the website) if I request something along the lines of:
/iipsrv/gb179/public/GB179_DD_OCR_1_1/cover_1media.tif/0,0,2048,2048/256,/0/default.jpg
I get this image:
What I expect to receive is this one:
As you can tell the image IIPServer gives me is around half of the dimensions i'm expecting and also slightly stretched.
I'm thinking this is likely user error on my part not understanding the specific dimensions that IIPServer is willing to serve. However I can't figure out the logic around the images i'm getting nor why they are slightly stretched.
It appears to be from the code following this line in IIIF.cc:
265: // Get most suitable resolution and recalculate width and height of region in this resolution
And the logs display:
Full Request is IIIF=gb179/public/GB179_DD_OCR_1_1/cover_1media.tif/0,0,2048,2048/256,/0/default.jpg
[1/1]: Command / Argument is IIIF : gb179/public/GB179_DD_OCR_1_1/cover_1media.tif/0,0,2048,2048/256,/0/default.jpg
IIIF handler reached
IIIF :: URL decoded to gb179/public/GB179_DD_OCR_1_1/cover_1media.tif/0,0,2048,2048/256,/0/default.jpg
FIF handler reached
FIF :: URL decoding/filtering: gb179/public/GB179_DD_OCR_1_1/cover_1media.tif => gb179/public/GB179_DD_OCR_1_1/cover_1media.tif
FIF :: Image cache hit. Number of elements: 1
FIF :: TIFF image detected
FIF :: Created image
FIF :: Image dimensions are 3525 x 4891
FIF :: Image contains 3 channels with 8 bits per channel
FIF :: Image timestamp: Wed, 28 Jan 2015 15:29:53 GMT
FIF :: Total command time 935 microseconds
IIIF :: Requested Region: x:0, y:0, w:2048, h:2048
IIIF :: Requested Size: 256x256
IIIF :: Requested Rotation: 0 degrees
IIIF :: Requested Quality: default with format: jpg
IIIF :: image request for gb179/public/GB179_DD_OCR_1_1/cover_1media.tif with arguments: region: 0,0,1024,1024; size: 256x256; rotation: 0; mirroring: 0
CVT handler reached
CVT :: Using resolution 3 with size 440x611
CVT :: Region: 0,0,128,128
CVT :: Requested scaled region size is 256x256 at resolution 3. Nearest existing resolution is 128x128
TileManager getRegion :: Total tiles in image: 2x3 tiles
TileManager getRegion :: Tile start: 0,0 with offset: 0,0
TileManager getRegion :: Tile end: 0,0
TileManager :: Cache Hit for resolution: 3, tile: 0, compression: UNCOMPRESSED
TileManager :: Cache Size: 2 tiles, 0.38474 MB
TileManager :: Total Tile Access Time: 85 microseconds
TileManager getRegion :: Tile access time 214 microseconds for tile 0 at resolution 3
TileManager getRegion :: Tile data is 3 channels, 8 bits per channel
TileManager getRegion :: destination tile width: 128, tile height: 128
CVT :: Resizing using bilinear interpolation in 6498 microseconds
CVT :: About to JPEG compress strip with height 128
CVT :: Compressed data strip length is 3164
CVT :: About to JPEG compress strip with height 128
CVT :: Compressed data strip length is 3576
CVT :: Total command time 9522 microseconds
IIIF :: Total command time 10892 microseconds
Total Request Time: 11329 microseconds
image closed and deleted
Server count is 6
System: Ubuntu Linux 14.04, Kakadu 7.5
The build fails at the linking stage:
link: g++ -std=gnu++0x -g -O2 -o iipsrv.fcgi IIPImage.o TPTImage.o JPEGCompressor.o TileManager.o IIPResponse.o View.o Transforms.o Task.o OBJ.o FIF.o JTL.o TIL.o ICC.o CVT.o Zoomify.o DeepZoom.o SPECTRA.o PFL.o IIIF.o Watermark.o Main.o KakaduImage.o -fopenmp /home/ahankins/src/kdu/apps/make/jpx.o /home/ahankins/src/kdu/apps/make/jp2.o /home/ahankins/src/kdu/apps/make/kdu_stripe_decompressor.o /home/ahankins/src/kdu/apps/make/libkdu_v75R.so -lmemcached -lz -lpthread ../fcgi/libfcgi/libfcgi.a -ljpeg /usr/lib/x86_64-linux-gnu/libtiff.so -lm -fopenmp
/home/ahankins/src/kdu/apps/make/kdu_stripe_decompressor.o: In function `kd_supp_local::kdsd_tile::init(kd_supp_local::kdsd_component_state*, int)':
kdu_stripe_decompressor.cpp:(.text+0x50a): undefined reference to `kd_supp_simd::ssse3_int16_to_uint8_rs_ilv3(unsigned char*, short**, int, int, int, bool, bool, int)'
kdu_stripe_decompressor.cpp:(.text+0x524): undefined reference to `kd_supp_simd::avx2_int16_to_uint8_rs_ilv3(unsigned char*, short**, int, int, int, bool, bool, int)'
.... (more of the same) ...
kdu_stripe_decompressor.cpp:(.text+0x9c4): undefined reference to `kd_supp_simd::ssse3_floats_to_int16_ilv1(short*, float**, int, int, int, bool, bool, int)'
collect2: error: ld returned 1 exit status
make[1]: *** [iipsrv.fcgi] Error 1
make[1]: Leaving directory `/home/ahankins/src/iipsrv/src'
make: *** [all-recursive] Error 1
Hi,
We've numerous examples of tiles being corrupted using IIIF at certain zoom levels, and also full-sized images when requested at high resolution. I can supply the jp2s to allow reproduction (they're around 1MB & 4MB). I'm including the params sent to IIIF here:
/iipiiifsrv5.fcgi?IIIF=/mnt/SCIF2/newspapers/derivatives/apnau/jp2/apnau01300594.jp2/1024,2048,512,512/256,/0/native.jpg
Produces:
iipiiifsrv5.fcgi?IIIF=/mnt/SCIF2/newspapers/derivatives/apnbp/jp2/apnbp00400082.jp2/full/,3000/0/native.jpg
Produces (this is a screenshot as it isn't a complete JPEG):
We were hoping that iipimage@fb3244d would fix this, but no joy.
Can I email you the JP2s Ruven?
We have tried to compile 0.9.9 src in CentOS 6.5 hosted in VirtualBox. We have compiled kakadu successfully and run this configure command
[vagrant@iipserver-dev-vm iipsrv]$ ./configure --with-kakadu=/vagrant/kakadu
…
Options Enabled:
---------------
Memcached:
JPEG2000 (Kakadu): true
Unfortunately, we couldn't compile it further with make as following error occurred
…
g++ -DPACKAGE_NAME=\"iipsrv\" -DPACKAGE_TARNAME=\"iipsrv\" -DPACKAGE_VERSION=\"1.0\" -DPACKAGE_STRING=\"iipsrv\ 1.0\" -DPACKAGE_BUGREPORT=\"[email protected]\" -DPACKAGE=\"iipsrv\" -DVERSION=\"1.0\" -DSTDC_HEADERS=1 -DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1 -DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1 -DHAVE_UNISTD_H=1 -DHAVE__BOOL=1 -DHAVE_STDBOOL_H=1 -DHAVE_DLFCN_H=1 -DLT_OBJDIR=\".libs/\" -DHAVE_GLOB_H=1 -DHAVE_TIME_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_STDLIB_H=1 -DHAVE_MALLOC=1 -DHAVE_LOG2=1 -DHAVE_SETENV=1 -DHAVE_EXT_POOL_ALLOCATOR_H=1 -DHAVE_STDCXX_0X=/\*\*/ -DHAVE_UNORDERED_MAP=/\*\*/ -DHAVE_TR1_UNORDERED_MAP=/\*\*/ -DHAVE_NAMESPACES=/\*\*/ -DHAVE_EXT_HASH_MAP=/\*\*/ -DHAVE_ISFINITE=1 -DHAVE_JPEG=1 -DHAVE_TIFF=1 -DHAVE_KAKADU=1 -DHAVE_STREAMBUF_CHAR_TYPE=1 -DHAVE_FPOS=1 -DHAVE_SYS_SOCKET_H=1 -DHAVE_NETDB_H=1 -DHAVE_NETINET_IN_H=1 -DHAVE_ARPA_INET_H=1 -DHAVE_SYS_TIME_H=1 -DHAVE_LIMITS_H=1 -DHAVE_SYS_PARAM_H=1 -DHAVE_UNISTD_H=1 -DHAVE_FILENO_PROTO=1 -I. -I/vagrant/kakadu/managed/all_includes/ -I. -I../fcgi/include -I../fcgi -std=gnu++0x -g -O2 -MT FIF.o -MD -MP -MF .deps/FIF.Tpo -c -o FIF.o FIF.cc
In file included from FIF.cc:29:
KakaduImage.h:49: error: expected class-name before ‘{’ token
KakaduImage.h:72: error: ‘kdu_message_formatter’ does not name a type
KakaduImage.h:73: error: ‘kdu_message_formatter’ does not name a type
KakaduImage.h:85: error: ‘kdu_codestream’ does not name a type
KakaduImage.h:88: error: ISO C++ forbids declaration of ‘kdu_compressed_source’ with no type
KakaduImage.h:88: error: expected ‘;’ before ‘*’ token
KakaduImage.h:91: error: ‘jpx_source’ does not name a type
KakaduImage.h:94: error: ‘jp2_family_src’ does not name a type
KakaduImage.h:97: error: ‘jpx_codestream_source’ does not name a type
KakaduImage.h:100: error: ‘kdu_stripe_decompressor’ does not name a type
KakaduImage.h:103: error: ‘kdu_dims’ does not name a type
make[1]: *** [FIF.o] Error 1
make[1]: Leaving directory `/vagrant/iipsrv/src'
make: *** [all-recursive] Error 1
[vagrant@iipserver-dev-vm iipsrv]$
Any ideas what is causing the problem, please?
Thank you.
The latest stable version (0.9.9) does not build on Mavericks 10.9.
The build fails with:
./Cache.h:52:10: fatal error: 'ext/pool_allocator.h' file not found
#include <ext/pool_allocator.h>
Fortunately this was fixed in f3beda8.
However, I was trying to contribute a formula for Homebrew for IIP when I ran into this problem. Homebrew likes to include only 'releases' in their system, using a tar file, instead of checking out the code from git.
Will there be an updated release that includes this fix sometime soon?
Hi,
It seems that the version number has been 1.0 for a long time now despite a log of fixes and changes. It would be useful if you had more frequent increments otherwise we have to use commit numbers to refer to the version we are testing or using on our site.
Geoffroy
We have jpg2000 images that are large than 5000 pixels and decided to try increasing the value of MAX_CVT to allow us to retrieve large jpeg thumbnails which we need. Once this was raised the iipsrv started crashing when we requested images wider or higher than 5000 pixels. I saw the max image cache parameter thought that increasing it might help but it had no effect.
The requests we are sending are in the form of
http://server/cgi-bin/iipsrv.fcgi?FIF=image.jp2&OBJ=IIP,1.0&HEI=10320&CVT=JPEG
Any height value above ~5400 causes the server to seg fault.
How can we get our images in widths and heights larger than 5000.
i've this error when compiling on 10.8.5
View.cc: In member function ‘unsigned int View::getViewLeft()’:
View.cc:163: error: call of overloaded ‘pow(double, unsigned int)’ is ambiguous
/usr/include/math.h:436: note: candidates are: double pow(double, double)
/usr/include/c++/4.2.1/cmath:373: note: long double std::pow(long double, int)
/usr/include/c++/4.2.1/cmath:369: note: float std::pow(float, int)
/usr/include/c++/4.2.1/cmath:365: note: double std::pow(double, int)
/usr/include/c++/4.2.1/cmath:361: note: long double std::pow(long double, long double)
/usr/include/c++/4.2.1/cmath:357: note: float std::pow(float, float)
View.cc: In member function ‘unsigned int View::getViewTop()’:
View.cc:171: error: call of overloaded ‘pow(double, unsigned int)’ is ambiguous
/usr/include/math.h:436: note: candidates are: double pow(double, double)
/usr/include/c++/4.2.1/cmath:373: note: long double std::pow(long double, int)
/usr/include/c++/4.2.1/cmath:369: note: float std::pow(float, int)
/usr/include/c++/4.2.1/cmath:365: note: double std::pow(double, int)
/usr/include/c++/4.2.1/cmath:361: note: long double std::pow(long double, long double)
/usr/include/c++/4.2.1/cmath:357: note: float std::pow(float, float)
View.cc: In member function ‘unsigned int View::getViewWidth()’:
View.cc:179: error: call of overloaded ‘pow(double, unsigned int)’ is ambiguous
/usr/include/math.h:436: note: candidates are: double pow(double, double)
/usr/include/c++/4.2.1/cmath:373: note: long double std::pow(long double, int)
/usr/include/c++/4.2.1/cmath:369: note: float std::pow(float, int)
/usr/include/c++/4.2.1/cmath:365: note: double std::pow(double, int)
/usr/include/c++/4.2.1/cmath:361: note: long double std::pow(long double, long double)
/usr/include/c++/4.2.1/cmath:357: note: float std::pow(float, float)
View.cc: In member function ‘unsigned int View::getViewHeight()’:
View.cc:192: error: call of overloaded ‘pow(double, unsigned int)’ is ambiguous
/usr/include/math.h:436: note: candidates are: double pow(double, double)
/usr/include/c++/4.2.1/cmath:373: note: long double std::pow(long double, int)
/usr/include/c++/4.2.1/cmath:369: note: float std::pow(float, int)
/usr/include/c++/4.2.1/cmath:365: note: double std::pow(double, int)
/usr/include/c++/4.2.1/cmath:361: note: long double std::pow(long double, long double)
/usr/include/c++/4.2.1/cmath:357: note: float std::pow(float, float)
make[1]: *** [View.o] Error 1
make: *** [all-recursive] Error 1
The iipsrv expects the identifier in the IIIIF parameter to be double encoded.
But how can you accomplish this in nginx by use of url-rewrite:
merge_slashes off;
location /iiif {
rewrite ^/iiif/(.*) /iip?IIIF=$1 last;
}
Nginx matches on a normalized uri, and url-encodes this normalized string.
So the identifier is url-encoded only once. Any ideas?
Per: http://merovingio.c2rmf.cnrs.fr/iiif/HD7.tif/info.json
That the server supports the gray quality is indicated already in the qualities list. Features in the supports list that aren't defined by the specification, must be URIs.
(minor, and noting that native in the qualities field does not have the same issue)
Hi,
this problem was discussed in #21. It seems that it still occurs if the width or height of requested region is very small. For example 1024,1024,2,512/2,/0/default.jpg outputs 2x128 image instead of 2x512.
Hi I am trying to get iipsrv running with leaflet. The server is answering regular requests without a problem but it seems that the retrieval of certain metadata fails. I could not find any documentation of the metadata service so I am asking here what could be the cause of such an error:
Request
.../fcgi-bin/iipsrv.fcgi?FIF=o.tif&obj=IIP,1.0&obj=max-size&obj=tile-size&obj=resolution-number&obj=bits-per-channel&obj=min-max-sample-values&obj=subject
Response
Error/25:3 2 min-max-sample-val
I am using iipsrv/0.9.9 from the ubuntu repo. The image i am using is a 16k JPEG converted to TIFF using the imagemagick method described in the docs. Any pointers in the right direction would be great!
We had to use install_name_tool to manually point to the libfcgi binaries included when we installed libfcgi through Homebrew.
Downloaded and unpacked http://oldmapsonline.googlecode.com/files/iipsrv-0.9.9-j2k-OSX.zip.
Ran otool -L iipsrv.fcgi in unzipped directory. This produced the following output:
/usr/lib/libfcgi.0.dylib (compatibility version 1.0.0, current version 1.0.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.3)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 125.2.11)
/usr/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.9.0)
This was a problem because /usr/local/lib/libfcgi.0.dylib did not exist on the drive.
brew install fcgi to install libfcgi. Homebrew installed libfcgi.0.dylib to /usr/local/lib/libfcgi.0.dylib, not /usr/lib/libfcgi.0.dylib which was the location that iipsrv.fcgi referenced.install_name_tool -change /usr/lib/libfcgi.0.dylib /usr/local/lib/libfcgi.0.dylib iipsrv.fcgi. This solved the problem.I've tried using ./configure --with-kakadu=/opt/kakadu/kakadu-7.5 but this leaves the bare lib name of "libkdu_v75R.so" in the FCGI executable, instead of what I was expecting "/opt/kakadu/kakadu-7.5/apps/make/libkdu_v75R.so". This is causing an installation of iipsrv with lighttpd and Kakadu-support to fail if following the instructions.
I see that configure.ac was changed by commit [https://github.com/ruven/iipsrv/commit/880cfd14ea00b2e133f01310c47093ffcefcfb13]
Although I can understand the reason for the change, it's not mentioned in the Git instructions that you have to have the Kakadu library in the same folder as the executable now.
hi,
i have a problem with one tiff file.
this is a tiffinfo log:
TIFF Directory at offset 0x297c4 (169924)
Image Width: 4096 Image Length: 3364
Tile Width: 256 Tile Length: 256
Resolution: 300, 300 pixels/inch
Bits/Sample: 1
Compression Scheme: LZW
Photometric Interpretation: min-is-black
FillOrder: msb-to-lsb
Orientation: row 0 top, col 0 lhs
Samples/Pixel: 1
Rows/Strip: 16
Planar Configuration: single image plane
Page Number: 0-7
TIFF Directory at offset 0x37866 (227430)
Subfile Type: reduced-resolution image (1 = 0x1)
Image Width: 2048 Image Length: 1682
Tile Width: 256 Tile Length: 256
Resolution: 150, 150 pixels/inch
Bits/Sample: 1
Compression Scheme: LZW
Photometric Interpretation: min-is-black
FillOrder: msb-to-lsb
Orientation: row 0 top, col 0 lhs
Samples/Pixel: 1
Rows/Strip: 32
Planar Configuration: single image plane
Page Number: 1-7
TIFF Directory at offset 0x3b6d0 (243408)
Subfile Type: reduced-resolution image (1 = 0x1)
Image Width: 1024 Image Length: 841
Tile Width: 256 Tile Length: 256
Resolution: 75, 75 pixels/inch
Bits/Sample: 1
Compression Scheme: LZW
Photometric Interpretation: min-is-black
FillOrder: msb-to-lsb
Orientation: row 0 top, col 0 lhs
Samples/Pixel: 1
Rows/Strip: 64
Planar Configuration: single image plane
Page Number: 2-7
TIFF Directory at offset 0x3c328 (246568)
Subfile Type: reduced-resolution image (1 = 0x1)
Image Width: 512 Image Length: 420
Tile Width: 256 Tile Length: 256
Resolution: 37.5, 37.5 pixels/inch
Bits/Sample: 1
Compression Scheme: LZW
Photometric Interpretation: min-is-black
FillOrder: msb-to-lsb
Orientation: row 0 top, col 0 lhs
Samples/Pixel: 1
Rows/Strip: 128
Planar Configuration: single image plane
Page Number: 3-7
TIFF Directory at offset 0x3c574 (247156)
Subfile Type: reduced-resolution image (1 = 0x1)
Image Width: 256 Image Length: 210
Tile Width: 256 Tile Length: 256
Resolution: 18.75, 18.75 pixels/inch
Bits/Sample: 1
Compression Scheme: LZW
Photometric Interpretation: min-is-black
FillOrder: msb-to-lsb
Orientation: row 0 top, col 0 lhs
Samples/Pixel: 1
Rows/Strip: 256
Planar Configuration: single image plane
Page Number: 4-7
TIFF Directory at offset 0x3c7b0 (247728)
Subfile Type: reduced-resolution image (1 = 0x1)
Image Width: 128 Image Length: 105
Tile Width: 256 Tile Length: 256
Resolution: 9.375, 9.375 pixels/inch
Bits/Sample: 1
Compression Scheme: LZW
Photometric Interpretation: min-is-black
FillOrder: msb-to-lsb
Orientation: row 0 top, col 0 lhs
Samples/Pixel: 1
Rows/Strip: 512
Planar Configuration: single image plane
Page Number: 5-7
TIFF Directory at offset 0x3c9f2 (248306)
Subfile Type: reduced-resolution image (1 = 0x1)
Image Width: 64 Image Length: 52
Tile Width: 256 Tile Length: 256
Resolution: 4.6875, 4.6875 pixels/inch
Bits/Sample: 1
Compression Scheme: LZW
Photometric Interpretation: min-is-black
FillOrder: msb-to-lsb
Orientation: row 0 top, col 0 lhs
Samples/Pixel: 1
Rows/Strip: 1024
Planar Configuration: single image plane
Page Number: 6-7
If I open the file with the file display appears correctly, but if you use iipsrv the file is not displayed correctly, but are displayed pieces of other images.
this is the relative path for image /fcgi-bin/iipsrv.fcgi?iiif=/DU/2015/1/tif/13f8633e-05e2-4c5a-b62a-22e66f8d8c61.tif/info.json
Hi,
mi iipsrv based server just hung up - permitted number of iipsrv processes got defunct and apache hasn't killed them.
My fcgi config:
# Set our environment variables for the IIP server
FcgidInitialEnv VERBOSITY "2"
FcgidInitialEnv LOGFILE "/var/log/iipsrv/iipsrv.log"
FcgidInitialEnv MAX_IMAGE_CACHE_SIZE "10"
FcgidInitialEnv JPEG_QUALITY "90"
FcgidInitialEnv MAX_CVT "5000"
FcgidInitialEnv MEMCACHED_SERVERS "localhost"
# Define the idle timeout as unlimited and the number of
# processes we want
FcgidIdleTimeout 0
FcgidMaxProcessesPerClass 2
31967 ? 00:02:42 iipsrv7.fcgi
31971 ? 00:02:39 iipsrv7.fcgi
From apache error.log
First: mod_fcgid: ap_pass_brigade failed in handle_request_ipc
Later: mod_fcgid: can't get pipe mutex,
finally: mod_fcgid: can't apply process slot for
(on apache restart).
child process 9261 still did not exit, sending a SIGKILL
child process 31546 still did not exit, sending a SIGKILL
child process 31437 still did not exit, sending a SIGKILL
and it worked. but imho apache should take care of this.
What should I do?
It would be nice if we could query the iipsrv.fcgi instance and return a JSON formatted list of features this instance supports. For example:
http://example.com/fcgi-bin/iipsrv.fcgi?getInfo
Might return:
{
"name": "IIP Image Server",
"version": "1.0.0",
"enabled_modules": ["TIFF", "Kakadu"]
... Any other data ...
}
With some JP2 images, iipserver (version 0.9.9) seems to serve an invalid tile and subsequent tiles are 'moved'. With most of the JP2 images the issue is not present, the only real difference I spotted was a difference in dimensions (width / height)
As the log below shows, the request for the 3rd tile returns a 1 x 256 pixel image which in fact is an invalid JPG. The 4th tile is returned ok, but the contents is what I expected in the 3rd tile! The same for tile 7 which is invalid, the 8th tile returns the contents I expected in tile 6.
In table form this looks like this:
normal | actual
0 1 2 | 0 1 2
3 4 5 | x 4(=3 ) 5(=4)
6 7 8 | 6(=5) x 8 (=6)
Strangly enough, this occurs with resolution 2, 3 and 4. With resolution 3 the tiles 6,13,20 and 27 are invalid. With resolution 4 the tiles 12,25,38,51,64,77,90 and 103 are invalid. With resolution 0, 1 and 5 all of the tiles are correct! This issue is reproducable, also after server restart (empty cache).
The logfile below shows that the 3rd and 7th tile (resolution 2) return an 1x256 pixel tile, but shows no errors!
CVT maximum viewport size set to 6400
Full Request is FIF=sc/1869-1917/1903-005/1903-005_00021.jp2&obj=IIP,1.0&obj=Max-size&obj=Tile-size&obj=Resolution-number
[1/5]: Command / Argument is FIF : sc/1869-1917/1903-005/1903-005_00021.jp2
FIF handler reached
FIF :: URL decoding/filtering: sc/1869-1917/1903-005/1903-005_00021.jp2 => sc/1869-1917/1903-005/1903-005_00021.jp2
FIF :: Image cache initialisation
FIF :: JPEG2000 image requested
FIF :: Created image
FIF :: Image dimensions are 6145 x 4353
FIF :: Image timestamp: Fri, 25 Jul 2014 14:42:12 GMT
FIF :: Total command time 511 microseconds
[2/5]: Command / Argument is obj : IIP,1.0
OBJ :: iip,1.0 to be handled
OBJ :: Total command time 1 microseconds
[3/5]: Command / Argument is obj : Max-size
OBJ :: max-size to be handled
OBJ :: Max-size is 6145 4353
OBJ :: Total command time 14 microseconds
[4/5]: Command / Argument is obj : Tile-size
OBJ :: tile-size to be handled
OBJ :: Tile-size is 256 256
OBJ :: Total command time 7 microseconds
[5/5]: Command / Argument is obj : Resolution-number
OBJ :: resolution-number to be handled
OBJ :: Resolution-number handler returning 6
OBJ :: Total command time 6 microseconds
---
Server: iipsrv/0.9.9
Cache-Control: max-age=86400
Last-Modified: Fri, 25 Jul 2014 14:42:12 GMT
Content-Type: application/vnd.netfpx
IIP:1.0
Max-size:6145 4353
Tile-size:256 256
Resolution-number:6
---
Total Request Time: 873 microseconds
image closed and deleted
Server count is 1
CVT maximum viewport size set to 6400
Full Request is FIF=sc/1869-1917/1903-005/1903-005_00021.jp2&WID=228&QLT=95&CVT=jpeg
[1/4]: Command / Argument is FIF : sc/1869-1917/1903-005/1903-005_00021.jp2
FIF handler reached
FIF :: URL decoding/filtering: sc/1869-1917/1903-005/1903-005_00021.jp2 => sc/1869-1917/1903-005/1903-005_00021.jp2
FIF :: Image cache hit. Number of elements: 1
FIF :: JPEG2000 image requested
FIF :: Created image
FIF :: Image dimensions are 6145 x 4353
FIF :: Image timestamp: Fri, 25 Jul 2014 14:42:12 GMT
FIF :: Total command time 216 microseconds
[2/4]: Command / Argument is WID : 228
WID handler reached
WID :: requested width is 228
[3/4]: Command / Argument is QLT : 95
[4/4]: Command / Argument is CVT : jpeg
CVT handler reached
CVT :: JPEG output handler reached
CVT :: image set to 385x273 using resolution 1
CVT :: No view port set
CVT :: Requested scaled region size is 227x161. Nearest pyramid region size is 385x273
CVT :: About to JPEG compress image
CVT :: Compressed data strip length is 79057
CVT :: Total command time 51464 microseconds
Total Request Time: 51913 microseconds
image closed and deleted
Server count is 2
CVT maximum viewport size set to 6400
Full Request is FIF=sc/1869-1917/1903-005/1903-005_00021.jp2&SDS=0,90&JTL=2,4
[1/3]: Command / Argument is FIF : sc/1869-1917/1903-005/1903-005_00021.jp2
FIF handler reached
FIF :: URL decoding/filtering: sc/1869-1917/1903-005/1903-005_00021.jp2 => sc/1869-1917/1903-005/1903-005_00021.jp2
FIF :: Image cache hit. Number of elements: 1
FIF :: JPEG2000 image requested
FIF :: Created image
FIF :: Image dimensions are 6145 x 4353
FIF :: Image timestamp: Fri, 25 Jul 2014 14:42:12 GMT
FIF :: Total command time 233 microseconds
[2/3]: Command / Argument is SDS : 0,90
SDS handler reached
SDS :: set to 0, 90
[3/3]: Command / Argument is JTL : 2,4
JTL handler reached
TileManager :: Cache Miss for resolution: 2, tile: 4
TileManager :: Cache Size: 0 tiles, 0 MB
TileManager :: JPEG Compression Time: 4398 microseconds
TileManager :: Tile cache insertion time: 105 microseconds
TileManager :: Total Tile Access Time: 31149 microseconds
JTL :: Tile size: 256 x 256
JTL :: Channels per sample: 1
JTL :: Bits per channel: 8
JTL :: Compressed tile size is 41684
JTL :: Total command time 31239 microseconds
Total Request Time: 31627 microseconds
image closed and deleted
Server count is 3
CVT maximum viewport size set to 6400
Full Request is FIF=sc/1869-1917/1903-005/1903-005_00021.jp2&SDS=0,90&JTL=2,1
[1/3]: Command / Argument is FIF : sc/1869-1917/1903-005/1903-005_00021.jp2
FIF handler reached
FIF :: URL decoding/filtering: sc/1869-1917/1903-005/1903-005_00021.jp2 => sc/1869-1917/1903-005/1903-005_00021.jp2
FIF :: Image cache hit. Number of elements: 1
FIF :: JPEG2000 image requested
FIF :: Created image
FIF :: Image dimensions are 6145 x 4353
FIF :: Image timestamp: Fri, 25 Jul 2014 14:42:12 GMT
FIF :: Total command time 217 microseconds
[2/3]: Command / Argument is SDS : 0,90
SDS handler reached
SDS :: set to 0, 90
[3/3]: Command / Argument is JTL : 2,1
JTL handler reached
TileManager :: Cache Miss for resolution: 2, tile: 1
TileManager :: Cache Size: 1 tiles, 0.0410713 MB
TileManager :: JPEG Compression Time: 4101 microseconds
TileManager :: Tile cache insertion time: 30 microseconds
TileManager :: Total Tile Access Time: 32361 microseconds
JTL :: Tile size: 256 x 256
JTL :: Channels per sample: 1
JTL :: Bits per channel: 8
JTL :: Compressed tile size is 37983
JTL :: Total command time 32421 microseconds
Total Request Time: 32793 microseconds
image closed and deleted
Server count is 4
CVT maximum viewport size set to 6400
Full Request is FIF=sc/1869-1917/1903-005/1903-005_00021.jp2&SDS=0,90&JTL=2,3
[1/3]: Command / Argument is FIF : sc/1869-1917/1903-005/1903-005_00021.jp2
FIF handler reached
FIF :: URL decoding/filtering: sc/1869-1917/1903-005/1903-005_00021.jp2 => sc/1869-1917/1903-005/1903-005_00021.jp2
FIF :: Image cache hit. Number of elements: 1
FIF :: JPEG2000 image requested
FIF :: Created image
FIF :: Image dimensions are 6145 x 4353
FIF :: Image timestamp: Fri, 25 Jul 2014 14:42:12 GMT
FIF :: Total command time 218 microseconds
[2/3]: Command / Argument is SDS : 0,90
SDS handler reached
SDS :: set to 0, 90
[3/3]: Command / Argument is JTL : 2,3
JTL handler reached
TileManager :: Cache Miss for resolution: 2, tile: 3
TileManager :: Cache Size: 2 tiles, 0.0785283 MB
TileManager :: JPEG Compression Time: 78 microseconds
TileManager :: Tile cache insertion time: 9 microseconds
TileManager :: Total Tile Access Time: 17732 microseconds
JTL :: Tile size: 1 x 256
JTL :: Channels per sample: 1
JTL :: Bits per channel: 8
JTL :: Compressed tile size is 196
JTL :: Total command time 17783 microseconds
Total Request Time: 18145 microseconds
image closed and deleted
Server count is 5
CVT maximum viewport size set to 6400
Full Request is FIF=sc/1869-1917/1903-005/1903-005_00021.jp2&SDS=0,90&JTL=2,5
[1/3]: Command / Argument is FIF : sc/1869-1917/1903-005/1903-005_00021.jp2
FIF handler reached
FIF :: URL decoding/filtering: sc/1869-1917/1903-005/1903-005_00021.jp2 => sc/1869-1917/1903-005/1903-005_00021.jp2
FIF :: Image cache hit. Number of elements: 1
FIF :: JPEG2000 image requested
FIF :: Created image
FIF :: Image dimensions are 6145 x 4353
FIF :: Image timestamp: Fri, 25 Jul 2014 14:42:12 GMT
FIF :: Total command time 216 microseconds
[2/3]: Command / Argument is SDS : 0,90
SDS handler reached
SDS :: set to 0, 90
[3/3]: Command / Argument is JTL : 2,5
JTL handler reached
TileManager :: Cache Miss for resolution: 2, tile: 5
TileManager :: Cache Size: 3 tiles, 0.079084 MB
TileManager :: JPEG Compression Time: 4364 microseconds
TileManager :: Tile cache insertion time: 30 microseconds
TileManager :: Total Tile Access Time: 32517 microseconds
JTL :: Tile size: 256 x 256
JTL :: Channels per sample: 1
JTL :: Bits per channel: 8
JTL :: Compressed tile size is 42596
JTL :: Total command time 32584 microseconds
Total Request Time: 33051 microseconds
image closed and deleted
Server count is 6
CVT maximum viewport size set to 6400
Full Request is FIF=sc/1869-1917/1903-005/1903-005_00021.jp2&SDS=0,90&JTL=2,7
[1/3]: Command / Argument is FIF : sc/1869-1917/1903-005/1903-005_00021.jp2
FIF handler reached
FIF :: URL decoding/filtering: sc/1869-1917/1903-005/1903-005_00021.jp2 => sc/1869-1917/1903-005/1903-005_00021.jp2
FIF :: Image cache hit. Number of elements: 1
FIF :: JPEG2000 image requested
FIF :: Created image
FIF :: Image dimensions are 6145 x 4353
FIF :: Image timestamp: Fri, 25 Jul 2014 14:42:12 GMT
FIF :: Total command time 246 microseconds
[2/3]: Command / Argument is SDS : 0,90
SDS handler reached
SDS :: set to 0, 90
[3/3]: Command / Argument is JTL : 2,7
JTL handler reached
TileManager :: Cache Miss for resolution: 2, tile: 7
TileManager :: Cache Size: 4 tiles, 0.121046 MB
TileManager :: JPEG Compression Time: 72 microseconds
TileManager :: Tile cache insertion time: 9 microseconds
TileManager :: Total Tile Access Time: 18939 microseconds
JTL :: Tile size: 1 x 256
JTL :: Channels per sample: 1
JTL :: Bits per channel: 8
JTL :: Compressed tile size is 119
JTL :: Total command time 18974 microseconds
Total Request Time: 19376 microseconds
image closed and deleted
Server count is 7
CVT maximum viewport size set to 6400
Full Request is FIF=sc/1869-1917/1903-005/1903-005_00021.jp2&SDS=0,90&JTL=2,0
[1/3]: Command / Argument is FIF : sc/1869-1917/1903-005/1903-005_00021.jp2
FIF handler reached
FIF :: URL decoding/filtering: sc/1869-1917/1903-005/1903-005_00021.jp2 => sc/1869-1917/1903-005/1903-005_00021.jp2
FIF :: Image cache hit. Number of elements: 1
FIF :: JPEG2000 image requested
FIF :: Created image
FIF :: Image dimensions are 6145 x 4353
FIF :: Image timestamp: Fri, 25 Jul 2014 14:42:12 GMT
FIF :: Total command time 213 microseconds
[2/3]: Command / Argument is SDS : 0,90
SDS handler reached
SDS :: set to 0, 90
[3/3]: Command / Argument is JTL : 2,0
JTL handler reached
TileManager :: Cache Miss for resolution: 2, tile: 0
TileManager :: Cache Size: 5 tiles, 0.121526 MB
TileManager :: JPEG Compression Time: 4244 microseconds
TileManager :: Tile cache insertion time: 32 microseconds
TileManager :: Total Tile Access Time: 28661 microseconds
JTL :: Tile size: 256 x 256
JTL :: Channels per sample: 1
JTL :: Bits per channel: 8
JTL :: Compressed tile size is 38094
JTL :: Total command time 28724 microseconds
Total Request Time: 29094 microseconds
image closed and deleted
Server count is 8
CVT maximum viewport size set to 6400
Full Request is FIF=sc/1869-1917/1903-005/1903-005_00021.jp2&SDS=0,90&JTL=2,2
[1/3]: Command / Argument is FIF : sc/1869-1917/1903-005/1903-005_00021.jp2
FIF handler reached
FIF :: URL decoding/filtering: sc/1869-1917/1903-005/1903-005_00021.jp2 => sc/1869-1917/1903-005/1903-005_00021.jp2
FIF :: Image cache hit. Number of elements: 1
FIF :: JPEG2000 image requested
FIF :: Created image
FIF :: Image dimensions are 6145 x 4353
FIF :: Image timestamp: Fri, 25 Jul 2014 14:42:12 GMT
FIF :: Total command time 216 microseconds
[2/3]: Command / Argument is SDS : 0,90
SDS handler reached
SDS :: set to 0, 90
[3/3]: Command / Argument is JTL : 2,2
JTL handler reached
TileManager :: Cache Miss for resolution: 2, tile: 2
TileManager :: Cache Size: 6 tiles, 0.159092 MB
TileManager :: JPEG Compression Time: 4073 microseconds
TileManager :: Tile cache insertion time: 114 microseconds
TileManager :: Total Tile Access Time: 27753 microseconds
JTL :: Tile size: 256 x 256
JTL :: Channels per sample: 1
JTL :: Bits per channel: 8
JTL :: Compressed tile size is 37832
JTL :: Total command time 27814 microseconds
Total Request Time: 28163 microseconds
image closed and deleted
Server count is 9
CVT maximum viewport size set to 6400
Full Request is FIF=sc/1869-1917/1903-005/1903-005_00021.jp2&SDS=0,90&JTL=2,6
[1/3]: Command / Argument is FIF : sc/1869-1917/1903-005/1903-005_00021.jp2
FIF handler reached
FIF :: URL decoding/filtering: sc/1869-1917/1903-005/1903-005_00021.jp2 => sc/1869-1917/1903-005/1903-005_00021.jp2
FIF :: Image cache hit. Number of elements: 1
FIF :: JPEG2000 image requested
FIF :: Created image
FIF :: Image dimensions are 6145 x 4353
FIF :: Image timestamp: Fri, 25 Jul 2014 14:42:12 GMT
FIF :: Total command time 222 microseconds
[2/3]: Command / Argument is SDS : 0,90
SDS handler reached
SDS :: set to 0, 90
[3/3]: Command / Argument is JTL : 2,6
JTL handler reached
TileManager :: Cache Miss for resolution: 2, tile: 6
TileManager :: Cache Size: 7 tiles, 0.196401 MB
TileManager :: JPEG Compression Time: 4318 microseconds
TileManager :: Tile cache insertion time: 31 microseconds
TileManager :: Total Tile Access Time: 29684 microseconds
JTL :: Tile size: 256 x 256
JTL :: Channels per sample: 1
JTL :: Bits per channel: 8
JTL :: Compressed tile size is 41241
JTL :: Total command time 29753 microseconds
Total Request Time: 30214 microseconds
image closed and deleted
Server count is 10
CVT maximum viewport size set to 6400
Full Request is FIF=sc/1869-1917/1903-005/1903-005_00021.jp2&SDS=0,90&JTL=2,8
[1/3]: Command / Argument is FIF : sc/1869-1917/1903-005/1903-005_00021.jp2
FIF handler reached
FIF :: URL decoding/filtering: sc/1869-1917/1903-005/1903-005_00021.jp2 => sc/1869-1917/1903-005/1903-005_00021.jp2
FIF :: Image cache hit. Number of elements: 1
FIF :: JPEG2000 image requested
FIF :: Created image
FIF :: Image dimensions are 6145 x 4353
FIF :: Image timestamp: Fri, 25 Jul 2014 14:42:12 GMT
FIF :: Total command time 257 microseconds
[2/3]: Command / Argument is SDS : 0,90
SDS handler reached
SDS :: set to 0, 90
[3/3]: Command / Argument is JTL : 2,8
JTL handler reached
TileManager :: Cache Miss for resolution: 2, tile: 8
TileManager :: Cache Size: 8 tiles, 0.23704 MB
TileManager :: JPEG Compression Time: 408 microseconds
TileManager :: Tile cache insertion time: 10 microseconds
TileManager :: Total Tile Access Time: 4554 microseconds
JTL :: Tile size: 256 x 33
JTL :: Channels per sample: 1
JTL :: Bits per channel: 8
JTL :: Compressed tile size is 2849
JTL :: Total command time 4592 microseconds
Total Request Time: 5022 microseconds
image closed and deleted
Server count is 11
configure.ac uses pkg-config to check for openjpeg, but autogen.sh does not check for pkg-config, resulting in a broken configure script:
./configure: line 18075: syntax error near unexpected token `OPENJPEG,'
./configure: line 18075: ` PKG_CHECK_MODULES(OPENJPEG, libopenjp2, OPENJPEG=true, OPENJPEG=false)'
Hello, I looked into https://github.com/ruven/iipsrv/blob/master/src/IIIF.cc and did not find where/how the service property is passed to the info.json response. I know this is optional property but I suppose it would be great if it is supported.
Commit a0849aa is producing a bad build for us on Ubuntu 14.04.4 machines (not tested on anything else).
The latest (HEAD) compiles, but when it tries to display a JPEG 2000 image it produces the error:
Error in `/usr/local/share/iipsrv-latest/iipsrv/src/iipsrv.fcgi': munmap_chunk(): invalid pointer: 0x0000000001c8eca0
Error in `/usr/local/share/iipsrv-latest/iipsrv/src/iipsrv.fcgi': munmap_chunk(): invalid pointer: 0x0000000001083ca0
Error in `/usr/local/share/iipsrv-latest/iipsrv/src/iipsrv.fcgi': munmap_chunk(): invalid pointer: 0x000000000254bca0
Error in `/usr/local/share/iipsrv-latest/iipsrv/src/iipsrv.fcgi': double free or corruption (out): 0x0000000002082ca0
Error in `/usr/local/share/iipsrv-latest/iipsrv/src/iipsrv.fcgi': free(): invalid size: 0x0000000001afdca0
This occurs with both KDU 7.7.1 and 7.8.
Reverting this change:
a0849aa#diff-4b5b06b344106556a47cef8e50e19e92L584
seems to fix it.
Thanks to @jeromepl for finding this one.
When I set the width or height of a region to "0", then the iipsrv hangs forever
version of iipsrv: 1.0 (git branch)
The last I see in the log:
Full Request is IIIF=/data/datadir/2012/1/27/10/40/5/1139-P-00001_2004_0001_AC.jp2/0,0,0,100/full/0/default.jpg
[1/1]: Command / Argument is IIIF : /data/datadir/2012/1/27/10/40/5/1139-P-00001_2004_0001_AC.jp2/0,0,0,100/full/0/default.jpg
IIIF handler reached
IIIF :: URL decoded to /data/datadir/2012/1/27/10/40/5/1139-P-00001_2004_0001_AC.jp2/0,0,0,100/full/0/default.jpg
FIF handler reached
FIF :: URL decoding/filtering: /data/datadir/2012/1/27/10/40/5/1139-P-00001_2004_0001_AC.jp2 => /data/datadir/2012/1/27/10/40/5/1139-P-00001_2004_0001_AC.jp2
FIF :: Image cache initialization
FIF :: JPEG2000 image detected
FIF :: Created image
FIF :: Image dimensions are 2008 x 3009
FIF :: Image contains 3 channels with 8 bits per channel
FIF :: Image timestamp: Wed, 07 Oct 2015 14:35:42 GMT
FIF :: Total command time 1137 microseconds
IIIF :: Requested Region: x:0, y:0, w:0, h:100
IIIF :: Requested Size: 8x100
IIIF :: Requested Rotation: 0 degrees
IIIF :: Requested Quality: default with format: jpg
IIIF :: image request for /data/datadir/2012/1/27/10/40/5/1139-P-00001_2004_0001_AC.jp2 with arguments: region: 0,0,8,100; size: 8x100; rotation: 0; mirroring: 0
Hello
The IIIF image api requires encoding of subdirectory slashes in the base uri, which means a url like http://server/iipsrv?IIIF=/directory%2Fsubdirectory%2Fsubdirectory%2Ffile.jp2/full/full/0/default.jpg is needed.
However an info.json request for the same file will not work as http://server/iipsrv?IIIF=/directory%2Fsubdirectory%2Fsubdirectory%2Ffile.jp2/info.json, but only as http://server/iipsrv?IIIF=/directory/subdirectory/subdirectory/file.jp2/info.json. All you get with the %2F url is a truncated json file that stops at "directory".
Have I missed something in configuration? I've tried adjusting apache settings but it seems to be an iipsrv issue.
Thank you.
Hello, I have installation very similar to this provided by the docker image but my I build directly from the master branch of this repo (not from the fork of stweil). When compiling I provide the --enable-openjpeg option to the ./configure command and have openjpeg installed. However when I request info.json for some images (i.e. url http://..../fcgi-bin/iipsrv.fcgi?IIIF=63aa6713-d643-4b6a-9c6a-fc0dae0bd069.ptif/info.json) I get an exception. The apache responds with code 500 saying that:
[fcgid:warn] [pid 27:tid 139732331788032] [client 172.17.0.1:38043] mod_fcgid: error reading data, FastCGI server closed connection
[core:error] [pid 27:tid 139732331788032] [client 172.17.0.1:38043] End of script output before headers: iipsrv.fcgi
[fcgid:error] [pid 26:tid 139732498884480] mod_fcgid: process /var/www/localhost/fcgi-bin/iipsrv.fcgi(104) exit(communication error), get unexpected signal 11
However if I request the image with specific dimensions (i..e http://..../fcgi-bin/iipsrv.fcgi?IIIF=63aa6713-d643-4b6a-9c6a-fc0dae0bd069.ptif/full/,64/0/default.jpg) the iip server provides the image correctly.
I'm attaching an archive holding the particular image and the iip server log file (iipsrv.log).
As discussed here:
http://sourceforge.net/p/iipimage/discussion/299493/thread/c11e322b/
It'd be very useful for some users to have direct openslide input, although It'd probably be computationally demanding, as no pyramid tiles are stored in most cases.
This branch https://github.com/richstoner/iipsrv has not yet worked for me, although compiled correctly.
Using 0.9.9 on Ubuntu 12.04.4 LTS. Already complied Kakadu v7_601588L (disabled both SSE3 and AVX2 since it was causing issues, having looked at issues #22 and #35) and I am now trying to compile IIP.
./autogen.sh and ./configure --with-kakadu=/home/user/kakadu/v7_601588L have been run succesfully.
When running make, I am seeing this error:
mv -f .deps/KakaduImage.Tpo .deps/KakaduImage.Po
/bin/bash ../libtool --tag=CXX --mode=link g++ -std=gnu++0x -g -O2 -o iipsrv.fcgi IIPImage.o TPTImage.o JPEGCompressor.o TileManager.o IIPResponse.o View.o Transforms.o Task.o OBJ.o FIF.o JTL.o TIL.o ICC.o CVT.o Zoomify.o DeepZoom.o SPECTRA.o PFL.o Watermark.o Main.o KakaduImage.o -lmemcached -lz -lpthread /home/alfresco/kakadu/v7_6-01588L/apps/make/jpx.o /home/alfresco/kakadu/v7_6-01588L/apps/make/jp2.o /home/alfresco/kakadu/v7_6-01588L/apps/make/kdu_stripe_decompressor.o /home/alfresco/kakadu/v7_6-01588L/apps/make/*.so -lpthread ../fcgi/libfcgi/libfcgi.a -ljpeg -ltiff -lm
libtool: link: g++ -std=gnu++0x -g -O2 -o iipsrv.fcgi IIPImage.o TPTImage.o JPEGCompressor.o TileManager.o IIPResponse.o View.o Transforms.o Task.o OBJ.o FIF.o JTL.o TIL.o ICC.o CVT.o Zoomify.o DeepZoom.o SPECTRA.o PFL.o Watermark.o Main.o KakaduImage.o /home/alfresco/kakadu/v7_6-01588L/apps/make/jpx.o /home/alfresco/kakadu/v7_6-01588L/apps/make/jp2.o /home/alfresco/kakadu/v7_6-01588L/apps/make/kdu_stripe_decompressor.o /home/alfresco/kakadu/v7_6-01588L/apps/make/libkdu_v76R.so -lmemcached -lz -lpthread ../fcgi/libfcgi/libfcgi.a -ljpeg /usr/lib/x86_64-linux-gnu/libtiff.so -lm
/home/alfresco/kakadu/v7_6-01588L/apps/make/jpx.o: In function `kdu_supp::jpx_source::generate_metareq(kdu_supp::kdu_window*, int, int, int, int, bool)':
jpx.cpp:(.text+0x375d4): undefined reference to `kdu_supp::kdu_window::add_metareq(unsigned int, int, bool, int, bool, long long, int)'
jpx.cpp:(.text+0x376ef): undefined reference to `kdu_supp::kdu_window::add_metareq(unsigned int, int, bool, int, bool, long long, int)'
/home/alfresco/kakadu/v7_6-01588L/apps/make/jpx.o: In function `kdu_supp::jpx_metanode::generate_metareq(kdu_supp::kdu_window*, int, unsigned int const*, int, unsigned int const*, bool, int, int)':
jpx.cpp:(.text+0x39bff): undefined reference to `kdu_supp::kdu_window::add_metareq(unsigned int, int, bool, int, bool, long long, int)'
jpx.cpp:(.text+0x39c42): undefined reference to `kdu_supp::kdu_window::add_metareq(unsigned int, int, bool, int, bool, long long, int)'
jpx.cpp:(.text+0x39cc9): undefined reference to `kdu_supp::kdu_window::add_metareq(unsigned int, int, bool, int, bool, long long, int)'
/home/alfresco/kakadu/v7_6-01588L/apps/make/jpx.o:jpx.cpp:(.text+0x39f16): more undefined references to `kdu_supp::kdu_window::add_metareq(unsigned int, int, bool, int, bool, long long, int)' follow
collect2: error: ld returned 1 exit status
make[1]: *** [iipsrv.fcgi] Error 1
make[1]: Leaving directory `/home/alfresco/iipsrv/src'
make: *** [all-recursive] Error 1
Searching the web for anything regarding kdu_supp::kdu_window::add_metareq has turned up nothing. Any thoughts on why its not able to run kdu_window or add_metareq?
Thanks.
Expected behavior: Regardless of whether an IIIF request has a width that is larger than the image bounds, the server should respond with a cropped image. (See http://iiif.io/api/image/2.0/#region : "If the request specifies a region which extends beyond the dimensions reported in the Image Information document, then the service should return an image cropped at the image’s edge, rather than adding empty space.")
Actual behavior: IIP responds with blurry images for IIIF requests exceeding a certain region width.
Steps to reproduce: Make a request to IIPImage using the IIIF syntax with a region width equal to or greater than 2x the width of the returned image for the same region at full size (greater than 4x the width at 50% size). Behavior occurs when size is specified as pct:n, w, , or w,h.
Example request (running IIP from current master branch):
Bad response:
http://dev-diva.simssa.ca/fcgi-bin/iipsrv.fcgi?IIIF=/srv/images/beromunster/bm_005.tif/2048,3072,884,1024/full/0/color.jpg
Good response:
http://dev-diva.simssa.ca/fcgi-bin/iipsrv.fcgi?IIIF=/srv/images/beromunster/bm_005.tif/2048,3072,883,1024/full/0/color.jpg
IIP log files for the responses:
https://gist.github.com/magoni/78733c94a1934a3a3895
Using the JTL syntax, edge tiles look fine: http://dev-diva.simssa.ca/fcgi-bin/iipsrv.fcgi?FIF=/srv/images/beromunster/bm_005.tif&JTL=2,11
Hi,
We are currently upgrading our IIPImage/OpenSeaDragon setup to be IIIIF compliant.
We discovered during the process that the info.json is not been generated properly if the image name contains spaces.
Example:
http://XX.XX.XX.XX/iiif/images/81055/vdc_100000001524.0x000379/Mss%20Eur%20F126_1_0616.jp2/info.json
Returns:
{
"@context" : "http://iiif.io/api/image/2/context.json",
"@id" : "http://XX.XX.XX.XX/iiif/images/81055/vdc_100000001524.0x000379/Mss 6.953200E-310urNote: the images are been served properly using:
http://XX.XX.XX.XX/iiif/images/81055/vdc_100000001524.0x000379/Mss%20Eur%20F126_1_0616.jp2/full/,1200/0/default.jpg
Please let me know if you need more information.
iipsrv compiled on a vanilla debian wheezy
root@li141-42:/opt/iipimage# ldd iipsrv.fcgi
linux-vdso.so.1 => (0x00007fffc3bfd000)
libnsl.so.1 => /lib/x86_64-linux-gnu/libnsl.so.1 (0x00007f57d8c45000)
libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f57d8a2e000)
libjpeg.so.8 => /usr/lib/x86_64-linux-gnu/libjpeg.so.8 (0x00007f57d87f3000)
libtiff.so.5 => /usr/lib/x86_64-linux-gnu/libtiff.so.5 (0x00007f57d8580000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f57d8279000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f57d7ff6000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f57d7de0000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f57d7a54000)
liblzma.so.5 => /lib/x86_64-linux-gnu/liblzma.so.5 (0x00007f57d7830000)
libjbig.so.0 => /usr/lib/x86_64-linux-gnu/libjbig.so.0 (0x00007f57d7622000)
/lib64/ld-linux-x86-64.so.2 (0x00007f57d8e66000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f57d741e000)
start:
export VERBOSITY=6
export LOGFILE=/tmp/iip.log
export FILESYSTEM_PREFIX=/data
/opt/iipimage/iipsrv.fcgi --bind 127.0.0.1:9000
test the iiif:
http://{MY_IP}/fcgi-bin/iipsrv.fcgi?IIIF=o.tif/full/400,400/90/grey.jpg
the server segfaults:
root@li141-42:/opt/iipimage# ./iipsrv.fcgi --bind 127.0.0.1:9000
Segmentation fault
logfile:
Tue Jan 6 17:06:08 2015
IIPImage Server. Version 1.0
*** Ruven Pillay <[email protected]> ***
Verbosity level set to 6
Running in standalone mode on socket: 127.0.0.1:9000
Setting maximum image cache size to 10MB
Setting filesystem prefix to '/data'
Setting default JPEG quality to 75
Setting maximum CVT size to 5000
Setting 3D file sequence name pattern to '_pyr_'
Initialisation Complete.
<----------------------------------->
Full Request is FIF=o.tif/full/400,400/90/grey.jpg
this seems to me this same behaviour http://sourceforge.net/p/iipimage/discussion/299494/thread/087907ab/?limit=25
the tiff file i'm using for test is tiled (generated with imagemagick)
Hi,
Like my username says, I am not a smart man when it comes to getting IIPsrv to work on nginx on a x64 windows. I know there is documentation on your website, but I feel like a klutz because it just doesn't seem to work. I am just having trouble actually running iipsrv from the command line. Is there a way you can help me out?
Thanks and I apologize for my technical ineptitude.
-NL
Hello,
Thanks for the great product. When looking for IIIF support I notice mentions of a 1.0 release and using the development version. Is there a timeline for 1.0?
Thanks again!
Seems that the vcxproj file contains a few unresolved conflicts which prevent it from being opened in visual Studio.
Please compare the output of these URLs which shows the aspect ratio of the image being changed when it shouldn't be The server is using the latest build from code in github as of August 10, 2016. The server has a MAX_CVT of 1024 configured. Removing MAX_CVT resolves the problem on our test server. I would argue that the MAX_CVT enforcement should be applied in such a way as to ensure that the aspect ratio of the resulting image remains unaltered. The IIIF bounding box constraint seems to work properly so this problem seems to be limited to cases when only a single dimension is specified for the target size.
http://media.nga.gov/iiif/public/objects/7/9/79-primary-0-nativeres.ptif/full/1000,/0/default.jpg
vs.
http://media.nga.gov/iiif/public/objects/7/9/79-primary-0-nativeres.ptif/full/800,/0/default.jpg
vs.
http://media.nga.gov/iiif/public/objects/7/9/79-primary-0-nativeres.ptif/full/full/0/default.jpg
Thanks,
Dave Beaudet, NGA
I have a weird situation where RGN requests with some particular range of values on the same JP2 image will fail. I have notice this bug a while ago, just tested it today again with the latest version of iipsrv (obtained from GIT yesterday) and Kakadu 7.3.3.
The same requests will work well with iipsrv 0.9 though.
If you are interested I can send the image (25MB) and the request over to you to help you reproducing the error.
IIP doesn't seem to calculate the right height when requesting a region of an image with "w," in the {size} slot of the URI. Sometimes it retrieves an image with a wrong aspect ratio, and sometimes the image is corrupted too.
A few examples:
1024,1024,1024,1024/256,/0/default.jpg: outputs a 256x366 image (should be 256x256, like this)
...and another bug:
1024,1536,512,1024/256,/0/default.jpg : outputs a 256x366 image (should be 256x512)…
and when we check 1024,1536,512,1024/256,512/0/default.jpg the output image is scaled but still corrupted... unless you set an y value for region <= 1535 or >= 1537 (see 1024,1537,512,1024/256,512/0/default.jpg.
Weird.
Those bugs have been raised while testing the last version of IIP server (except latest commit a47a95f) with OpenSeadragon, which both support IIIF Image API 2.0: http://demos.biblissima-condorcet.fr/iip-osd/ (see)
@ruven: do you have an idea of what's going on? Could you confirm it's a problem on the server-side or not?
Hi Ruven,
trying a make dist in iipimage directory will complain some files are missing.
They are:
PNGCompressor.hPNGCompressor.ccPTL.ccI'm not linking with PNG libraries, so no problem in compiling.
They have just been forgotten in some local repository? ;)
Cheers,
Chiara
Compiling iipsrv fails on Centos 6:
[..]
libtool: link: g++ -std=gnu++0x -g -O2 -o iipsrv.fcgi IIPImage.o TPTImage.o JPEGCompressor.o TileManager.o IIPResponse.o View.o Transforms.o Task.o OBJ.o FIF.o JTL.o TIL.o ICC.o CVT.o Zoomify.o DeepZoom.o SPECTRA.o PFL.o IIIF.o Watermark.o Main.o KakaduImage.o -fopenmp /home/install/ugent-kakadu/v6_4_1-01131N/apps/make/jpx.o /home/install/ugent-kakadu/v6_4_1-01131N/apps/make/jp2.o /home/install/ugent-kakadu/v6_4_1-01131N/apps/make/kdu_stripe_decompressor.o -L/home/install/ugent-kakadu/v6_4_1-01131N/apps/make -lkdu_v64R -lpthread ../fcgi/libfcgi/libfcgi.a -ljpeg -ltiff -lm
/home/install/ugent-kakadu/v6_4_1-01131N/apps/make/libkdu_v64R.so: undefined reference to `memcpy@GLIBC_2.14'
collect2: ld returned 1 exit status
make[1]: *** [iipsrv.fcgi] Error 1
make[1]: Leaving directory `/home/install/iipsrv/src'
make: *** [all-recursive] Error 1
It complains that glibc 2.14 is required. Is this version really required, or can it be done with lower versions? Glibc 2.12 is standard on all Centos 6, and higher versions I do not find for this OS.
Compiling the libraries and binaries of kakadu themselves do not give this error, although
libkdu_v64R.so is also used there.
Steps:
$ git clone git://github.com/ruven/iipsrv.git
$ cd iipsrv
$ autoreconf -i --force
aclocal: couldn't open directory `m4': No such file or directory
autoreconf: aclocal failed with exit status: 1
Thanks
The current implementation expects the input identifier to be file path.
One can get from an identifier to a real file path with some basic url-rewriting,
when the path is logical:
archive.ugent.be:45-58.jp2 => archive/ugent/45/58.jp2
But that rewritten path is used in the "@id" of the info.json,
so the user sees the rewritten path.
So the question is:
We're having filenames that contain special characters like the +-sign. Therefore, we escape the + as %2B which works perfectly fine when opening the image with the following URL:
/fcgi-bin/iipsrv.fcgi?FIF=imageStorage/nb_vol001_issue0001_0156%2B0157.tif&cnt=1&sds=0,90&jtl=4,1
However, when I try to open the following URL, I get an "neither a file nor part of an image sequence"-Error:
/fcgi-bin/iipsrv.fcgi?IIIF=imageStorage/nb_vol001_issue0001_0156%2B0157.tif/full/512,512/0/default.jpg
When opening the log, it says the following:
Full Request is IIIF=imageStorage/nb_vol001_issue0001_0156%2B0157.tif/full/512,512/0/default.jpg
[1/1]: Command / Argument is IIIF : imageStorage/nb_vol001_issue0001_0156%2B0157.tif/full/512,512/0/default.jpg
IIIF handler reached
FIF handler reached
FIF :: Image cache miss
/media/imageStorage/nb_vol001_issue0001_0156 0157.tif is neither a file nor part of an image sequence
Sending HTTP 404 Not Found
Total Request Time: 305 microseconds
image closed and deleted
I guess the problem is, that the URL is parsed twice. The first time it is parsed to the correct filename (/media/imageStorage/nb_vol001_issue0001_0156+0157.tif) and then the + sign get's parsed as HTTP-URL again and therefore becomes a space (/media/imageStorage/nb_vol001_issue0001_0156 0157.tif).
Is there a bugfix or some way to fix this?
Thank's for your help!
Kakadu - yeah, it's probably nice, but it's non-free. We've got some free jpeg2000 libraries.
Some of them are GPU based - as iipsrv is oriented for performance ( comparing to python or java-based image servers ) It'd be very nice to support them as an option.
We've got:
CUDA: http://apps.man.poznan.pl/trac/jpeg2k/wiki
CUDA: http://cuj2k.sourceforge.net/
CPU: http://www.openjpeg.org/
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.