It aims to do the same thing...serve big JP2s (and other images) over
the web, so from that perspective, yes. But, beyond that, time will
tell. One nice thing about coding against a well-thought-out spec is
that are lots of implementations from which you can choose[1]--though as
far as I know Loris is the only one that supports the IIIF syntax
natively (maybe IIP?). We still have Djatoka floating around in a few
places here, but, as many people have noted over the years, it takes a
lot of shimming to scale it up, and, as far as I know, the project has
more or less been abandoned.
I haven't done too much in the way of benchmarking, but to date don't
have any reason to think Loris can't perform just as well. The demo I
sent earlier is working against a very large jp2 with small tiles[1]
which means a lot of rapid hits on the server, and between that, (a
little bit of) JMeter and ab testing, and a fair bit of concurrent use
from the c4l community this afternoon, I feel fairly confident about it
being able to perform as well as Djatoka in a production environment.
By the way, you can page through some other images here:
http://libimages.princeton.edu/osd-demo/
Not much of an answer, I realize, but, as I said, time and usage will tell.
-Js
1. http://iiif.io/apps-demos.html
2.
http://libimages.princeton.edu/loris/pudl0052%2F6131707%2F00000001.jp2/info.json
On 11/8/13 8:07 PM, Peter Murray wrote:
> A clarifying question: is Loris effectively a Python-based replacement for the Java-based djatoka [1] server?
>
>
> Peter
>
> [1] http://sourceforge.net/apps/mediawiki/djatoka/index.php?title=Main_Page
>
>
> On Nov 8, 2013, at 3:05 PM, Jon Stroop <[log in to unmask]> wrote:
>
>> c4l,
>> I was reminded earlier this week at DLF (and a few minutes ago by Tom
>> and Simeon) that I hadn't ever announced a project I've been working for
>> the least year or so to this list. I showed an early version in a
>> lightning talk at code4libcon last year.
>>
>> Meet Loris: https://github.com/pulibrary/loris
>>
>> Loris is a Python based image server that implements the IIIF Image API
>> version 1.1 level 2[1].
>>
>> http://www-sul.stanford.edu/iiif/image-api/1.1/
>>
>> It can take JP2 (if you make Kakadu available to it), TIFF, or JPEG
>> source images, and hand back JPEG, PNG, TIF, and GIF (why not...).
>>
>> Here's a demo of the server directly: http://goo.gl/8XEmjp
>>
>> And here's a sample of the server backing OpenSeadragon[2]:
>> http://goo.gl/Gks6lR
>>
>> -Js
>>
>> 1. http://www-sul.stanford.edu/iiif/image-api/1.1/
>> 2. http://openseadragon.github.io/
>>
>> --
>> Jon Stroop
>> Digital Initiatives Programmer/Analyst
>> Princeton University Library
>> [log in to unmask]
> --
> Peter Murray
> Assistant Director, Technology Services Development
> LYRASIS
> [log in to unmask]
> +1 678-235-2955
> 800.999.8558 x2955
|