Coder Social home page Coder Social logo

ruven / iipsrv Goto Github PK

View Code? Open in Web Editor NEW
280.0 43.0 114.0 4.19 MB

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

Shell 5.74% Makefile 1.17% C 25.19% C++ 60.54% M4 7.16% Dockerfile 0.20%
high-resolution image-processing image-server jpeg2000 tiff multispectral iiif

iipsrv's Introduction

IIPImage - High Resolution Streaming Image Server

GPLv3 Licensed Build Status Build Status CodeQL Coverity Scan CodeFactor

ABOUT

IIPImage is an advanced high-performance feature-rich image server system for web-based streamed viewing and zooming of ultra high-resolution images. It is designed to be fast and bandwidth-efficient with low processor and memory requirements. The system can comfortably handle gigapixel size images as well as advanced image features such as 8, 16 and 32 bits per channel, CIELAB colorimetric images and scientific imagery such as multispectral images, image sequences and 3D surface topologies.

FEATURES

  • Fast lightweight FastCGI server
  • High performance with inbuilt configurable cache
  • Support for extremely large images: tera-pixel and multi gigapixel support
  • TIFF and JPEG2000 input support
  • JPEG, PNG and WebP output support: export of whole or regions of images at any size
  • Supports IIP, Zoomify, DeepZoom and IIIF API's
  • 1, 8, 16 and 32 bit image support including 32 bit floating point support
  • CIELAB support with automatic CIELAB->sRGB color space conversion
  • Multispectral and hyperspectral image support
  • Image stacks and image sequence support
  • Dynamic hillshading of 3D surface topologies
  • Dynamic watermarking
  • Memcached support

LICENCE

iipsrv is released under the GNU General Public License (GPL). See the copyright notice COPYING in this directory for licensing details or go to http://www.gnu.org/licenses/gpl.html for more details.

If you use IIPImage on a public site and remove the IIP link logo from the client, you must provide a link on your site back to the IIPImage site - https://iipimage.sourceforge.io

BUILDING

Building iipsrv requires a C++ compiler and several development libraries.

Dependencies

Required Libraries:

  • libtiff development files
  • libjpeg compatible JPEG development files such as libjpeg or libjpeg-turbo
  • libfcgi - the latest version of the FCGI development library is bundled with the iipsrv distribution. If no system FCGI library is detected, the bundled version will be used. See fcgi/COPYING.FCGI for licensing information for these libraries.

Optional Libraries:

  • Kakadu for JPEG2000 input support. Note, however, that this is not open source and you will need to purchase a license for the source code. In order to use, first build the Kakadu SDK as per the instructions supplied with the SDK. Then, supply the following parameters to the ./configure command: --with-kakadu=/path/to/kakadu/distribution
  • OpenJPEG for JPEG2000 input support. OpenJPEG will be disabled if Kakadu support has been enabled. Use the --with-openjpeg=<path> configure option if this library is installed in a non-standard location
  • libpng for PNG output support
  • libwebp for WebP output support
  • libmemcached for Memcached, a high-performance, distributed memory object caching system. If enabled, IIPImage will cache results using this distributed cache, giving IIPImage added speed and scalability

Building on UNIX / Linux / Mac OSX

On UNIX, Linux and Mac OS X based systems, iipsrv can be built using the standard autoconf configure / make build process.

First download iipsrv, then unpack it and change your working directory to be the iipsrv source code location. For example:

tar jxvf iipsrv-<version>.tar.bz2
cd iipsrv-<version>

If you are building from a git clone rather than from a release package, you must first generate the configure script and autoconf build environment using the provided autogen.sh script. This step is not necessary for release versions.

./autogen.sh

Now run the configure script:

./configure

Optional libraries are activated by default if found by configure. To manually disable, use the --disable-<option> flag. For example --disable-openjpeg will disable OpenJPEG support.

To see the full list of available configuration options:

./configure --help

Now compile using make:

make

The resulting executable is iipsrv.fcgi in the src/ sub-directory.

To install iipsrv to a system folder:

make install

This will install iipsrv (note without the .fcgi suffix) in the system sbin directory for use, for example, with a service script. By default, this is /usr/local/sbin/iipsrv. Use configure's --prefix parameter to change the destination directory. For example:

./configure --prefix=/usr
make
sudo make install

Building on Windows

For building on Windows, Visual Studio build files are available in the windows/ sub-directory. These use vcpkg for dependency management.

To install all required and optional dependencies using vcpkg:

.\vcpkg.exe install tiff openjpeg fastcgi libpng libwebp --triplet x64-windows

Make these available to Visual Studio:

.\vcpkg.exe integrate install

Now open the provided iipsrv project with Visual Studio and build. See https://iipimage.sourceforge.io/documentation/server/windows for full details.

DEVELOPMENT DOCUMENTATION

Detailed class descriptions (generated using doxygen) are available in the doc sub-directory

RUNNING IIPSRV

The IIPImage server can be started in a number of ways.

  • Directly on the command line or through an FCGI process manager such as spawn-fcgi
  • Through a Linux/UNIX system startup service, such as an init.d script, systemd or supervisor service
  • Started and managed by the web server itself (only Apache and Lighttpd can start iipsrv)

Both the command line / process manager and system startup script options will start an iipsrv process, which will listen on the specified port or socket for FCGI requests. iipsrv currently does not handle HTTP requests and so, you will need an FCGI-aware web server front-end in order to handle HTTP and communicate using FCGI to iipsrv.

Most HTTP web servers are FCGI-compatible and are able to connect to a running iipsrv instance. The following web servers have been successfully tested with iipsrv:

Apache, Lighttpd and IIS can additionally start and manage the iipsrv process.

Starting iipsrv on the Command Line

iipsrv can be started directly on the command line using the --bind parameter in order to listen on the specified port or socket. For example:

export VERBOSITY=5
iipsrv.fcgi --bind 0.0.0.0:9000

where the argument given to bind is the socket on which to listen to FCGI requests. The socket can be a network (IP address and port) or UNIX file socket. Note that configuration parameters need to be exported as environment variables. See the CONFIGURATION section for more details.

There is additionally a --backlog parameter that is optional and sets the socket backlog value. The backlog value specifies the number of requests can be queued and, therefore, increases the number of concurrent connections that iipsrv can handle and is set to 2048 by default. For example:

iipsrv.fcgi --bind 192.168.0.1:9000 --backlog 1024

Note that the backlog parameter must be specified after the bind parameter and argument. Note also that this value may be limited by the operating system. On Linux kernels < 2.4.25 and Mac OS X, the backlog limit is hard-coded to 128, so any value above this will be limited to 128 by the OS. If you do provide a backlog value, verify whether the setting /proc/sys/net/core/somaxconn should be updated.

iipsrv can also be started using lighttpd's spawn-fcgi. The process can be bound to an IP address and port for backend load-balancing configurations and multiple processes can be forked. For example:

spawn-fcgi -f iipsrv.fcgi -a 0.0.0.0 -p 9000

Starting iipsrv using an Init Script or Service

OpenRC and Systemd scripts and configuration files for Linux are provided in the script/ sub-directory. To use these, copy and rename the iipsrv.fcgi executable to just iipsrv and place in /usr/sbin/. See the accompanying README files for more details.

Starting and Managing iipsrv through a Web Server

Apache and Lighttpd are able to start and manage the iipsrv process themselves. First install the iipsrv.fcgi executable in a suitable location. For example: /var/www/fcgi-bin/iipsrv.fcgi.

Apache

There are 2 Apache modules available that are able to start and manage an FCGI executable: mod_fcgid and mod_fastcgi

Apache - mod_fcgid

Make sure the module is installed and loaded:

LoadModule fcgid_module /path/to/apachemodules/mod_fcgid.so

Example configuration. Note that there is no need to explicitly start the server:

# Create a directory for the iipsrv binary
ScriptAlias /fcgi-bin/ "/var/www/fcgi-bin/"

# Set the options on that directory
<Directory "/var/www/fcgi-bin/">
   AllowOverride None
   Options None

# Syntax for access is different in Apache 2.4 - uncomment appropriate version
# Apache 2.2
#   Order allow,deny
#   Allow from all

# Apache 2.4
   Require all granted

   # Set the module handler
   AddHandler fcgid-script .fcgi
</Directory>

# Set our environment variables for the IIP server
FcgidInitialEnv VERBOSITY "5"
FcgidInitialEnv LOGFILE "/tmp/iipsrv.log"
FcgidInitialEnv MAX_IMAGE_CACHE_SIZE "10"
FcgidInitialEnv JPEG_QUALITY "50"
FcgidInitialEnv MAX_CVT "3000"

# Define the idle timeout as unlimited and the number of
# processes we want
FcgidIdleTimeout 0
FcgidMaxProcessesPerClass 1

Note that on CentOS, FcgidIPCDir is configured by default to /var/log/httpd/fcgidsock, which may not be writable by Apache. If this is the case, specify another location for FcgidIPCDir, which is writable, such as /tmp/fcgidsock

Apache - mod_fastcgi

Example configuration if using the mod_fastcgi module:

# Create a directory for the iipsrv binary
ScriptAlias /fcgi-bin/ "/var/www/fcgi-bin/"

# Set the options on that directory
<Directory "/var/www/fcgi-bin">
   AllowOverride None
   Options None

# Syntax for access is different in Apache 2.4 - uncomment appropriate version
# Apache 2.2
#   Order allow,deny
#   Allow from all

# Apache 2.4
   Require all granted

</Directory>

# Set the module handler
AddHandler fastcgi-script fcg fcgi fpl

# Initialise some variables for the FCGI server
FastCgiServer /var/www/fcgi-bin/iipsrv.fcgi \
-initial-env LOGFILE=/tmp/iipsrv.log \
-initial-env VERBOSITY=2 \
-initial-env MAX_IMAGE_CACHE_SIZE=10 \
-initial-env FILENAME_PATTERN=_pyr_ \
-initial-env JPEG_QUALITY=50 \
-initial-env MAX_CVT=3000 \
-listen-queue-depth 2048 \
-processes 1

Lighttpd

Lighttpd example extract:

fastcgi.server = ( "/fcgi-bin/iipsrv.fcgi" =>
  (( "host" => "0.0.0.0",
     "port" => 9000,
     "check-local" => "disable",
     "min-procs" => 1,
     "max-procs" => 1,
     "bin-path" => "/var/www/fcgi-bin/iipsrv.fcgi",
     "bin-environment" => (
        "LOGFILE" => "/tmp/iipsrv.log",
        "VERBOSITY" => "5",
        "MAX_IMAGE_CACHE_SIZE" => "10",
        "JPEG_QUALITY" => "50",
        "MAX_CVT" => "3000"
      )
  ))
)

CONNECTING A WEB SERVER TO A RUNNING IIPSRV INSTANCE

Apache

As seen in the previous section, Apache can start and manage an iipsrv process. But if you want to start iipsrv using an system service or have run iipsrv on a remote machine, Apache can be configured to connect to an already running instance.

To do this, make sure mod_proxy and mod_proxy_fcgi are loaded and add the following lines to Apache's configuration (change the IP address to that of the remote machine if iipsrv is hosted on a different server):

ProxyPass "/fcgi-bin/iipsrv.fcgi" "fcgi://0.0.0.0:9000/"
ProxyPass "/iiif" "fcgi://0.0.0.0:9000/"

Note that this will also start a clean IIIF URL service at `/iiif'. (See the URI_MAP configuration parameter in the Configuration section for more details).

Lighttpd

fastcgi.server = (
  "/fcgi-bin/iipsrv.fcgi" => (
        ("host"=>"0.0.0.0", "port"=>9000, "check-local"=>"disable")
  ),
  "/iiif" => (
        ("host"=>"0.0.0.0", "port"=>9000, "check-local"=>"disable")
  )
)

NginX

NginX cannot start or manage iipsrv itself, but it can connect to an existing instance. To set up nginx with iipsrv add a directive such as this to your nginx configuration, which will forward requests to /fcgi-bin/iipsrv.fcgi to a running iipsrv process on port 9000. Change the IP address and port to match your installation.

location /fcgi-bin/iipsrv.fcgi {
fastcgi_pass    0.0.0.0: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;
}

Nginx can also handle load balancing to multiple iipsrv instances, which can be hosted on the same machine on multiple ports or on different hosts. For a multiple host configuration, declare the load balancing like this:

upstream iip {
server 192.168.0.1:9000;
server 192.168.0.2:9000;
server 192.168.0.3:9000;
server 192.168.0.4:9000;
}

and change the fastcgi_pass parameter in the above location configuration to point to this instead of a fixed address:

fastcgi_pass       iip;

Java Application Servers (Tomcat, Jetty, JBoss etc)

IIPImage can also be used with Java Application Servers such as Apache Tomcat, JBoss and Jetty. Simply add the JFastCGI jar file to your webapp and add the following to your web.xml configuration file in order to re-route FCGI requests to the IIPImage server on the specified port.

<!-- Gateway Servlet to IIPImage FCGI server -->

<servlet>
  <servlet-name>fcgi</servlet-name>
  <servlet-class>net.jr.fastcgi.FastCGIServlet</servlet-class>
  <init-param>>
    <param-name>server-address</param-name>
    <param-value>0.0.0.0:9000</param-value>
  </init-param>
</servlet>

<servlet-mapping>
  <servlet-name>fcgi</servlet-name>
  <url-pattern>/fcgi-bin/iipsrv.fcgi</url-pattern>
</servlet-mapping>

DOCKER

A fully configured iipsrv Docker container is available from Docker Hub. To use, simply pull the container and run it:

docker pull iipsrv/iipsrv
docker run -it -p 9000:9000 -p 8080:80 -v /home/images/:/images iipsrv/iipsrv

Images can be made available to the container by binding to a folder on the host machine, In this example, the folder /home/images/. Detailed instructions on how to build the Docker image and run the container can be found in ihe README in the docker/ sub-directory.

CONFIGURATION

There are several startup variables that can be passed to the server. These need to be passed as environment variables when starting iipsrv on the command line or through a system service script. All variables are optional:

LOGFILE: the server will log its output to the file specified, if it can. Version 1.1 and later of iipsrv also supports logging to syslog if “syslog” is given as the value.

VERBOSITY: 0 means no logging, 1 is minimal logging, 2 lots of debugging stuff, 3 even more debugging stuff and 10 a very large amount indeed ;-)

MAX_IMAGE_CACHE_SIZE: Max image cache size to be held in RAM in MB. This is a cache of the compressed JPEG image tiles requested by the client. The default is 10MB.

MAX_IMAGE_METADATA_CACHE_SIZE: Max number of items in metadata cache size. This is a cache of key image metadata (dimensions, tile size, bit depth ...) from an image file. The cache avoids the need to read image file header for each request. Default is 1000. If set to -1, the cache size is unlimited.

FILESYSTEM_PREFIX: This is a prefix automatically added by the server to the beginning of each file system path. This can be useful for security reasons to limit access to certain sub-directories. For example, with a prefix of "/home/images/" set on the server, a request by a client for "image.tif" will point to the path "/home/images/image.tif". Any reverse directory path component such as ../ is also filtered out. No default value.

FILESYSTEM_SUFFIX: This is a suffix added to the end of each file system path. It can be combined with FILESYSTEM_PREFIX. It is not used in combination with FILENAME_PATTERN. If e.g. this is set to ".tif", an image URL such as "/UUID" will look for "${FILESYSTEM_PREFIX}/UUID.tif". In the IIIF info.json document, the image @id will be set without the ".tif" suffix.

JPEG_QUALITY: The default JPEG quality factor for compression when the client does not specify one. The value should be between 1 (highest level of compression) and 100 (highest image quality). The default is 75.

PNG_QUALITY: The default PNG quality factor for compression when the client does not specify one. The value should be between 1 (highest level of compression) and 9 (highest image quality). The default is 1.

WEBP_QUALITY: The default WebP quality factor for compression when the client does not specify one. For lossy compression the value should be between 0 (highest level of compression) and 100 (highest image quality). For lossless compression, set this to -1. The default is lossy compression with a quality factor of 50.

MAX_CVT: Limits the maximum output image dimensions (in pixels) allowable for dynamic image export via the CVT command or for IIIF requests. This prevents huge requests from overloading the server. The default is 5000. If set to -1, no limit is set.

ALLOW_UPSCALING: Determines whether an image may be rendered at a size greater than that of the source image. A value of 0 will prevent upscaling. The default is 1 (upscaling is allowed).

MAX_LAYERS: The maximum number of quality layers to decode for images that support progressive quality encoding, such as JPEG2000. Ignored for other file formats. If not set, half of the available quality layers will be decoded by default. If set to -1, all the available layers will be decoded by default.

FILENAME_PATTERN: Pattern that follows the name stem for a 3D or multispectral sequence. eg: "pyr" for FZ1_pyr_000_090.tif. The default is "pyr". This is only relevant to 3D image sequences.

WATERMARK: TIFF image to use as watermark file. This image should be not be bigger the tile size used for TIFF tiling. If bigger, it will simply be cropped to the tile size. If smaller, the watermark will be positioned randomly within the available space. The image can be either color or grayscale.

WATERMARK_PROBABILITY: The probability that a particular tile will have a watermark applied to it. 0 means never, 1 means always.

WATERMARK_OPACITY: The opacity (between 0 and 1) applied to the watermark image.

MEMCACHED_SERVERS: A comma-delimited list of memcached servers with optional port numbers. For example: localhost,192.168.0.1:8888,192.168.0.2.

MEMCACHED_TIMEOUT: Time in seconds that cache remains fresh. Default is 86400 seconds (24 hours).

INTERPOLATION: Interpolation method to use for re-scaling when using image export. Integer value. 0 for fastest nearest neighbour interpolation. 1 for bilinear interpolation (better quality but about 2.5x slower). Bilinear by default.

CORS: Cross Origin Resource Sharing setting. Disabled by default. Set to * to enable for all domains or specify a single domain. See http://www.w3.org/TR/cors/ for more details on CORS.

BASE_URL: Set a base URL for use in certain protocol requests if web server rewriting has taken place and the public URL is not the same as that supplied to iipsrv.

URI_MAP: Set a mapping from a URL prefix to a supported protocol. This enables iipsrv to be able to work without requiring full CGI query strings. Map must be of the form "prefix=>protocol" where prefix can be either empty or any string prefix and protocol must be one of IIP,IIIF,DeepZoom, Zoomify. Used, for example, to map requests of the form http://server/iiif/ to the IIIF protocol handler without requiring web server rewriting.

CACHE_CONTROL: Set the HTTP Cache-Control header. See http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9 for a full list of options. If not set, header defaults to "max-age=86400" (24 hours).

EMBED_ICC: Set whether the ICC profile is embedded within the output image. 0 to strip profile, 1 to embed profile. The default is 1 (embedded profiles).

OMP_NUM_THREADS: Set the number of OpenMP threads to be used by the iipsrv image processing routines (See OpenMP specification for details). All available processor threads are used by default.

KAKADU_READMODE: Set the Kakadu JPEG2000 read-mode. 0 for 'fast' mode with minimal error checking (default), 1 for 'fussy' mode with no error recovery, 2 for 'resilient' mode with maximum recovery from codestream errors. See the Kakadu documentation for further details.

CODEC_PASSTHROUGH: Enable pre-encoded tiles to be sent directly to the client without re-encoding or processing if the requested output encoding matches the encoding used within the source image. Enabled only for tile requests that map to a single tile in the source image and that do not specify or require any image processing or manually set the encoding quality level. Only works for TIFF with either JPEG or WebP-encoded tiles. Set to 1 to activate or 0 to disactivate. Default is 1 (activated)

IIIF_VERSION: Set the major IIIF Image API version. Values should be a single digit. For example: 2 for versions 2 or 2.1 etc. 3 for IIIF version 3.x. If not set, defaults to version IIIF 3.x

IIIF_DELIMITER: Set delimiter to enable page or slice selection for a multi-page or image stack for IIIF requests. Delimiter can be a single character or an arbitrary string. Disabled by default.

IIIF_EXTRA_INFO: Add extra arbitrary field to all IIIF info.json files. Must be a string containing a valid JSON key, value line. Key and value quotes should be escaped if necessary and no trailing comma should be added. For example, to add a preferredFormats field: IIIF_EXTRA_INFO='"preferredFormats": ["webp"]'

COPYRIGHT: Specify a global copyright or rights statement if this is not available in the image metadata itself

DECODER_MODULES: Comma separated list of external modules for decoding other image formats. This is only necessary if you have activated --enable-modules for ./configure and written your own image format handler(s).

IMAGES

Image Input Formats

Input images must be in either tiled multi-resolution (pyramid) TIFF format or in JPEG2000 format. See https://iipimage.sourceforge.io/documentation/images for details on how to create appropriate images.

Image Input Paths

The images paths given to the server via the FIF command for the IIP API or in the IIIF, Deepzoom or Zoomify requests must be absolute paths on the server machine (eg. FIF=/images/test.tif) and not paths relative to the web server document root location. Images do not, therefore, need to be directly accessible through the web server. The FILESYSTEM_PREFIX configuration parameter can be used to avoid overly long image paths. Make sure the iipsrv process owner is able to access and read the images!

Output Images

iipsrv can transcode input images in TIFF or JPEG2000 to JPEG, PNG or WebP format. See the API documentation for details on how to use iipsrv: https://iipimage.sourceforge.io/documentation/protocol

DEBUGGING

Basic debugging can be carried out by simply using the server logs. Verbose logging can be obtained by increasing the VERBOSITY startup variable. Implemented levels of verbosity range from 0 (no logging) to 6 (maximum amount of logging). The pre-processor defines KAKADU_DEBUG and OPENJPEG_DEBUG can additionally be set at compile time to generate additional detailed logging from these particular decoders.

It is also possible to test iipsrv without the use of FCGI or a web server. In this case, you will need to compile iipsrv with DEBUG defined for the pre-processor. This can be done during the ./configure stage before building using make either manually by setting adding -DDEBUG to CXXFLAGS or automatically through the --enable-debug-mode option:

./configure --enable-debug-mode
make

The resulting binary can be started on the command line and will accept any supported imaging protocol requests (IIP, IIIF, Deepzoom or Zoomify) without any HTTP prefix or domain name (e.g. FIF=test.tif&WID=500&CVT=JPEG) as standard input on the command line and output the image or data to the file "iipsrv.debug" in the same directory. Successive requests will replace the contents of iipsrv.debug with the output of the new request. For example:

% ./src/iipsrv.fcgi
FIF=test.tif&WID=500&CVT=JPEG
IIIF=/test.tif/full/500,/0/default.jpg
FIF=test.tif&WID=600&ROT=90&&CVT=PNG

On Linux/Unix based systems, it's also possible to use pipes or redirection to send a list of requests within a file with iipsrv automatically terminating at the end of the list:

iipsrv.fcgi < request_list.txt

Debugging using memory testing tools, such as valgrind (https://valgrind.org/), can be performed by starting iipsrv on the command-line through the testing tool. For example:

valgrind iipsrv.fcgi --bind 0.0.0.0:9000

This can work in conjunction with debugging mode or together with a web server in normal FCGI-mode. In this case the web server must be setup to proxy forward FCGI requests to the address and port specified when starting iipsrv.


Please refer to the project site https://iipimage.sourceforge.io for further details


(c) 2000-2024 Ruven Pillay [email protected]

iipsrv's People

Contributors

ahankinson avatar alanyee avatar cmarmo avatar denics avatar dfukagaw28 avatar filak avatar fractos avatar geektortoise avatar leiblix avatar lovasoa avatar martinmikita avatar michalbecak avatar nicolasfranck avatar picturae-build avatar rouault avatar ruven avatar sbarex avatar scossu avatar sergemarkin avatar stephenn-cogapp avatar stweil avatar tgc avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

iipsrv's Issues

Error compiling code master

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

Increasing the MAX_CVT parameter results in seg faults

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.

Cannot start IIPsrv on NGINX x64

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

IIIF requests with a width arbitrarily larger than bounds of image return blurry images

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

URL is getting decoded twice

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!

Version numbers

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

IIIF info.json not been generated properly if image filename contains spaces

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-310ur

Note: 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.

IIIF problem with retrieving info.json file for images in subdirectories?

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.

IIIF: server hangs when width or height are zero

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

nginx url rewrite for IIIIF

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?

JPEG 2000 support broken in HEAD

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.

Fedora package out of date

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.

Downloaded binary for OSX points to wrong libfcgi location

We had to use install_name_tool to manually point to the libfcgi binaries included when we installed libfcgi through Homebrew.

Steps to produce problem

  1. Downloaded and unpacked http://oldmapsonline.googlecode.com/files/iipsrv-0.9.9-j2k-OSX.zip.

  2. 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)
    
  3. This was a problem because /usr/local/lib/libfcgi.0.dylib did not exist on the drive.

Solution

  1. Ran 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.
  2. Ran install_name_tool -change /usr/lib/libfcgi.0.dylib /usr/local/lib/libfcgi.0.dylib iipsrv.fcgi. This solved the problem.

Corrupt IIIF images at certain zoom levels

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:
apnau01300594

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):
screenshot-apnbp00400082

We were hoping that iipimage@fb3244d would fix this, but no joy.

Can I email you the JP2s Ruven?

Problem: --with-kakadu parameter and lib placement

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.

0.9.9 does not build on 10.9

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?

Jpeg via Intel's IPP

Have anyone tried to build iipsrv with Intel's Integrated Performance Primitives?
It could give us a major speed boost.

IIIF seemingly random tile sizes being returned, not following IIIF spec.

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:
cover_1media

What I expect to receive is this one:
default

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

Prevent defunct iipsrv

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?

Segfault when FCGI parameters are not provided

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:

  • Fix the code at (
    const string request_string = FCGX_GetParam( "QUERY_STRING", request.envp );
    ) and (
    session.headers["SERVER_PROTOCOL"] = FCGX_GetParam("SERVER_PROTOCOL", request.envp);
    ). When a FCGI parameter is not present, "FCGX_GetParam" returns NULL. Attempting to assign NULL to a "std::string" causes a segfault.
  • Improve the documentation for running IIP with Nginx ( http://iipimage.sourceforge.net/documentation/server/#nginx ) (and maybe some of the other servers, I haven't read through them all). The Nginx documentation does not mention that the lines:
        fastcgi_param   SERVER_PROTOCOL $server_protocol;
        fastcgi_param   REQUEST_URI $request_uri;

should also be present.

iipsrv segfault

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)

errors compiling on osx 10.8.5

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

1.0 build release?

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!

IIIF 2.0 Support?

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/

IIIF protocol: wrong aspect ratio

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.

0.9.9 doesn't build with kakadu v7_5-01559N

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.

glibc 2.14 required?

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.

basic resolver for IIIF?

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:

  • Should the "@id" not be derived from the header "X-Forwarded-Host" if exists? The IIPServer always is behind a proxy server, so url-rewriting is always there.
  • Should there be some basic resolver in the IIPServer, maybe url-rewriting to make these requests more transparent?

Error 25:3

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!

Add JSON response for getting server info

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 ...
}

failed display tiff file

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

Docs missing.

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

IIIF protocol: wrong aspect ratio when requesting a region with w, as the size parameter

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?

Error when fetching info for some images

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).

Some RGN requests failing.

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.

unchecked pkg-config dependency

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)'

Interrupted processing

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
<----------------------------------->

IIIF resize request resulting in changing aspect ratio of image

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

invalid and wrong tiles served

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

Build fails with Kakadu 7.5

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

Missing files for make dist?

Hi Ruven,
trying a make dist in iipimage directory will complain some files are missing.
They are:

  • PNGCompressor.h
  • PNGCompressor.cc
  • PTL.cc

I'm not linking with PNG libraries, so no problem in compiling.
They have just been forgotten in some local repository? ;)

Cheers,
Chiara

Issues building 0.9.9 with Kakadu v7_601588L

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.