confused about iipimage jpeg2000 support

Help
DGSL
2009-12-29
2013-06-14
1 2 > >> (Page 1 of 2)
  • DGSL

    DGSL - 2009-12-29

    I am glad to see that a new version has been released but I am really confused
    about it:

    • Is this an "official release"? I am so surprised that the download page is at googlecode, instead of sourceforge. Also, there are no new versions at svn.

    • Installation: as I have not clear the origin of this release, and I already have a previously installed iipimage 0.9.8 that works well with my apache/fastcgi ... should I follow the steps provided here?:

    My doubts about the command line installation procedure shown at oldmapsonline
    is that it says:

    *3. A prepared Lighttpd configuration file is packaged with IIPImage* (but I already use Apache!)

    *4. Link the default IIPMooViewer into the webserver root directory* (it seems to install a bundled copy of iipmooviewer, but I already have one!).

    • source code ... where is it ??? I can't see a link and couldn't find at googlecode, so I don't know how to compile like I used to do with svn releases at

    Well ... I long for trying this new release but I wonder if I should wait for
    jp2 support to be announced in sourceforge project page (instead of
    googlecode). IIPimage developers: are you planning to migrate from
    sourceforge to googlecode?

    Or are these 2 different approaches to jp2 support? (I mean, 2 different branches of iipimage that are developed by different people, like djatoka server)

    (btw, all this somehow answered part of a question I had submited here
    regarding .deb package installation, but I still think the deb file at sf.net
    is corrupted -it has a very small filesize-: )

    : http://help.oldmapsonline.org/jpeg2000/installation
    : http://iipimage.svn.sourceforge.net/
    : https://sourceforge.net/projects/iipimage/forums/forum/299494/topic/1876273
    ?message=7830486

     
  • Ruven

    Ruven - 2009-12-29

    No, it's not yet officially released. We will do it in January.

    No, it's not a fork nor do we plan to migrate to googlecode. The JPEG2000 work
    has been done in conjunction with oldmapsonline.org and they will host the
    binaries for it. The source code will be uploaded to sourceforge soon and will
    be part of the main IIP server.

     
  • DGSL

    DGSL - 2009-12-29

    Thanks for your prompt reply.

    Would you also provide .deb files at sf.net? (for installing just iipimage
    server) I am still wondering about howto install the one currenly available

     
  • DGSL

    DGSL - 2009-12-30

    Hi again. To test it safely, I used a VirtualBox machine to follow the
    oldmapsonline installation steps on Ubuntu 9.04. I found a couple of known
    bugs:

    (1). This bug was almost corrected for pyramidal tiffs in version 0.9.8, but
    appears again in 0.9.9 when serving jpeg 2000 files: IIPimage server returns a
    JPEG with a "wrong" size (nearest available resolution?) when using CVT=JPEG
    and WID or HEI, and FIF is a JP2 file.

    For pyramidal tiff sources, the returned jpeg still has about one pixel error
    (reported for 0.9.8, due to rounding in the resizing).

    (2). WID and HEI values keep being altered by the 3rd and 4th parameters
    passed to RGN (already reported for 0.9.8):

    HEI=900&RGN=0.25,0.25,0.5,0.333&CVT=JPG

    the jpeg returned is 299 pixels high (which is almost 1/3 of the requested
    height). 299 = 900 * 0.333 - 1

    WID=900&RGN=0.25,0.25,0.5,0.333&CVT=JPG

    the jpeg returned is 449 pixels wide (which is almost 1/2 of the requested
    width). 449 = 900 * 0.5 - 1

    This happens to pyramidal tiffs (I suspect also to jp2, but the first error
    prevents me to test the 2nd).


    In my opinion, the 2nd bug is specially important (hopefully will be solved in
    the svn release).

    Well, if it is a bug, which I still have not clear (perhaps I misunderstood
    the RGN parameters).

     
  • Ruven

    Ruven - 2009-12-31

    In fact, the RGN command in iipsrv has always worked in this way. The 3rd and
    4th parameters, which are the width and height (requested as a ratio) act
    applied to the requested WID or HEI. So, the total pixel width = WID*w (where
    w is the RGN width parameter). I'm not sure this is the best way to do it, but
    it seems to me the most logical.

    Yes, for JPEG2000, there is no exact scaling at the moment. I will try to fix
    this before the official release.

    The order you put these should not make any difference, although the CVT=JPEG
    command must appear at the end of the request.

     
  • DGSL

    DGSL - 2010-01-02

    RGN command in iipsrv has always worked in this way. The 3rd and 4th
    parameters, which are the width and height (requested as a ratio) act applied
    to the requested WID or HEI. So, the total pixel width = WID*w (where w is the
    RGN width parameter). I'm not sure this is the best way to do it, but it seems
    to me the most logical.

    Thanks for your reply. My interpretation (derived from your dynamic JPEG
    generation
    examples) was completely different. The IIP protocol should
    clarify this, so I have been reading it carefully (it seems clear enough that
    everyone can understand it).

    I think IIPimage produces a WRONG server response to a combination of those
    request parameters; WID and HEI are absolute FINAL sizes (desired width/height
    in pixels). Some extracts of the protocol (the key words are order and
    after):

    page 29 (2nd step to produce a composed image):
    The file result image is mapped through the IIP specified transforms,
    producing the IIP transformed result image. The IIP transforms must be applied
    in the following order:
    - ...
    - RGN after all modifiers except RFM, WID, and HEI
    - WID, HEI, after RGN
    - ...


    PAGE 30: The following commands precede the CVT command and are used to modify
    the behavior of CVT: (...) RGN, WID, HEI, (...). Unlike the other commands in
    this document which are applied as they appear, these command modifiers have a
    pre-defined processing order as defined above.

    • In other words: you shouldn't multiply WID (or HEI) by anything that comes from RGN. Just select the appropiate source tiles (defined by RGN), to finally produce a composed image of certain dimensions (defined exactly by WID/HEI).

    ... I find this logical: from the point of view of a client, I should have
    clear what part of the image I want (specified by RGN), and what size
    do I want it (specified by WID/HEI). But currently, IIPimage implementation of
    this makes the client have to divide the WID/HEI sizes by the 3rd and 4th
    parameter of RGN (because IIPimage is gonna ¿wrongly? multiply them before
    producing its response). I hope you see logical this interpretation. Regarding
    yours, I just cant imagine the scenario you were thinking about when decided
    to mix up both parameters. Perhaps anyone knows of a public URL of another IIP
    compatible server, so we can see how it is implementing this?

    I think the above subject is the most important, but reading the protocol I
    also found some other perhaps (imho) wrongly implemented things in iipimage.

    • First of all, RGN does also accept numbers higher than 1 (that would imply server returning black filled zones):

    PAGE 32 (RGN):
    Example: RGN=0,0,1.3,0.2
    Notes: If the RGN command is not specified, the entire image at its maximum
    resolution is returned. Values outside the bounds of the image are valid.
    Transparent areas of the result image are assumed to be black.
    RGN specifies what portion of the output coordinate space is to be returned.
    This allows clients to fetch a desired region of the image. RGN does not
    specify the result image, just which portion of the result coordinate space to
    return.
    If WID and HEI specify a size which does not match the aspect ratio, RGN is
    scaled anamorphically.
    PAGE 37: If WID is used without an HEI modifier, the height of the image is
    determined by the aspect ratio

    PAGE 38: If HEI is used without a WID modifier, the width of the image is
    determined by the aspect ratio.


    • The above also implies that, if I serve a square image (lets say 1000 x 1000 pixels, pyramidal tiff), iipsrv should return it as a distorted image that is double high than wide, in response to this request:
      WID=300&HEI=600&CVT=JPEG (but it should not return a square image)

    Or the opposite way: if I the original image that is not square, when I
    request the same WID/HEI values, the returned image should be distorted, but
    square.

    And in both cases, those sizes should be returned independently of what parts
    of the image I am requesting (could be all of it, or just a smaller -or bigger
    and black filled- part of the image, as specified by RGN)

    Well, at least that is what I would expect when the protocol says "RGN is
    scaled anamorphically
    ". But all this is not happening. In all my tests,
    iipimage server is always preserving the original image ratio, and to do this
    it changes the sizes of the returned image (so it does not respecting
    WID/HEI).

    Perhaps these requests of mine could look destructive from the point of view
    of some already done applications based on IIPimage. But I am developing mine,
    and in fact I wanna be constructive because I think the right implementation
    of IIP protocol is a must for your wonderful server (some popular comercial
    viewers, like FSI -which is a must for some people at my work-, are not
    compatible with IIPimage and I understood the reason just today).

    I hope that you find my suggestions appropiate and you can implement them on
    the server without much trouble. Also, if you decide not to do it, I would
    like you to tell us as soon as possible, because I wanna keep on using your
    server even if it uses "its own protocol". But the key is not having to recode
    my application twice if you are gonna change what I think is a wrong behaviour
    of the server. Sorry about beginning the year giving you so much work ;)

    And again, thank you SO MUCH for that work

     
  • Ruven

    Ruven - 2010-01-04

    You're probably right about the precedence of WID over RGN. Unfortunately,
    changing it risks to break several existing applications, so I think I will
    have to keep it working in the current way for the time being.

    I'm don't think this is the reason the FSI viewer doesn't work with iipsrv as
    I doubt it uses the CVT command at all. If you can put up an example page with
    an FSI viewer pointing to iipsrv, I will have a look at the protocol being
    used. Didn't you already do this a while ago?

    On a more general point about IIP protocol compatibility, the original
    protocol has several limitations which IIPImage gets around by extending it.
    For example, the tile sizes are fixed at 64x64 in the IIP protocol. This is
    not suitable for today's monitor sizes, so I've added a Tile-size command to
    allow any size tiles to be used etc. So, I don't think we need to be too
    constrained by a strict reading of the protocol. Indeed, the IIP server
    already handles other protocols such as Zoomify and DeepZoom, so one day if
    someone creates a protocol that is much better than IIP, we could even switch
    to this.

     
  • DGSL

    DGSL - 2010-01-04

    precedence of WID over RGN. Unfortunately, changing it risks to break
    several existing applications

    Perhaps you could try it and see if they break or not? I feel this change
    shouldn't be a major problem since that applications would just need to be
    changed to stop making making the same calculation that the server is doing in
    order to mix WID with the 3rd parameter of RGN.
    So the fact is that both (server and clients) should do less calculations if
    you make server work respecting requested WID/HEI (as IIP protocol states).
    Shouldn't it be much simpler this way for everyone?

    I understand your comments about IIP limitations, but for this particular
    problem, I believe that IIP approach is much better. And also, respecting it
    avoids you having to answer future questions about "why does IIPimage return
    half sized images when I request the top left quarter of my original tiff"?
    Sincerely, current behavior does not make sense, but if you decide not to
    change it, you should better document it with examples in the clients section
    of the web (specially for people that could need to develop their own
    applications to request images of a certain size -which is one of the main
    uses of an image server-).

    This is a server (iSeemedia) that does the RGN and WID/HEI combinations
    properly, when using CVT. I think it is a good example (it even accepts
    negative and bigger than 1 values passed to RGN; the only thing is that it
    fills blank spaces in white color instead of black):

    This is a client running on the same server (so you can check the headers
    sent, if you wish):

    With respect to FSI viewer, it actually does not use the proper IIP query
    syntax (i.e., it sends 4 GET parameters width,height,left,top instead of a
    single RGN parameter with 4 values). But it still expects the server to work
    like the one above, in the sense that images returned should have the
    requested width and height. So, if servers returns the proper sizes,
    communicating with FSI viewer is only a matter of translating RGN to those 4
    parameters at client side (or even making a server side trick like you do for
    zoomify or deepzoom).

    You can see all this in action on my server (you already know the URL), using
    this path: /javascript/iipmooviewer-1.1/zoomIIPfy_.php

    There you have several clients, and you'll see the differences. The last one
    uses a kind of php server bridge I made, that resizes the RNGs sent back by
    iipsrv.fcgi (so they will have the proper size). It works, but my server has
    to work a lot to do it, so I can't use this for the public site unless you
    make iipsrv do it (as it is supposed to do). Or at least, could you tell me
    the modified lines in server source code so I can compile it to work in the
    IIP protocol way
    ?

    If IIPimage RGNs sizes are returned like in the server linked above, then it
    would probably be able to work with FSI-viewer like with other 3rd party
    clients (Zoomify, DeepZoom). I think this would make your server much more
    popular (at least among people at my work ;) ... and I suppose your
    applications would easily be changed to run in this way, since it's just a
    matter of stop multiplying/dividing a couple of parameters.

    Anyway, thanks a lot for your replies. This problem was driving me crazy
    during the last weeks.

    : http://zoom.quirinale.it/fif=zoom.fpx&obj=iip,1.0&rgn=-0.05,0,2.14,0.73&wid
    =400&hei=300&cvt=jpeg

    : http://zoom.quirinale.it/fif=zoom.fpx&obj=IIP,1.0&obj=Max-
    size

     
  • Ruven

    Ruven - 2010-01-09

    I don't understand why FSI use CVT for their requests. It's potentially very
    slow and inefficient. This command is designed for exporting JPEG views, not
    for quickly getting a series of tiles. The JTL or TIL command is what every
    other IIP client I have seen uses.

    OK, I will fix the way WID and HEI work in the next version with maybe a
    config switch for people who are using the old method.

     
  • DGSL

    DGSL - 2010-01-11

    OK, I will fix the way WID and HEI work in the next version with maybe a
    config switch for people who are using the old method.

    When you say "next", do you mean the 0.9.9 you are about to release, or we
    have to wait until the next one?

    It also surprised me when I saw the wy FSI viewer works. But think about this
    not just as a FSI need, but a closer approach of iipimage to the protocol
    which will ease things to people trying to request accurate sized image parts
    for whatever purposes.

    Thanks a lot.

     
  • DGSL

    DGSL - 2010-01-12

    by the way, Ruven: when I tried send you URL of my server with examples, I got
    message returned ... it seems that your forward email address is not properly
    configured at sourceforge. Just tell me if you still need to see the example
    and you couldn't find it

    thanks

     
  • Ruven

    Ruven - 2010-01-12

    Yes, I managed to see the examples. Thanks.

     
  • DGSL

    DGSL - 2010-01-13

    Hi again. I tried to compile 0.9.9 from svn source, as usual. But when I try
    to use jp2 files it doesn't work.

    It's strange since usually iipsrv.fcgi returns an error (one of those
    IIPisamadwhatever ... when something fails). But in this case when I use CVT
    or I just request some info like with OBJ=Max-size for a .jp2 file, the
    web browser returns a "file doesn't exist" error, which is a bit odd. I
    suppose I should have previously installed whatever libraries required by
    iipsrv to open jpeg2000, but assumed them to be included already, since I was
    not warned of this when I compiled. Any clues?

    Thanks in advance

     
  • Ruven

    Ruven - 2010-01-13

    For more information on JPEG2000 please see this blog post and the
    OldMapsOnline site.

     
  • DGSL

    DGSL - 2010-01-13

    Thanks, that post explains all. If I got it, the point is that for non
    commercial use you can redistribute kakadu in a binary package, but you cant
    redistribute kakadu sources. Right?

    But this situation takes me back to the original post of this topic: I want to
    make non commercial use of IIPimage with jp2 support, but I already have a
    running Apache server with fastcgi installed. When I installed it, I remember
    we tried several flavours of fastcgi libraries until we got it running
    properly. Moreover, Apache 2 configuration links fastcgi iipsrv executable to
    a certain path of the server.

    In this situation, is not risky to install the IIPsrv.0.9.9. debian package?
    Couldnt it make my Apache and/or fastcgi stop running because of
    overinstalling lighttpd (which would use the same port as Apache) and fastcgi?

    Another idea: is it not possible to just install some sort of kakadu.deb (if
    it exists somewhere) instead of insalling an iipsrv.0.9.9-jp2.deb? That way I
    could avoid installing lighttpd and reinstalling fastcgi. But perhaps this is
    not that easy

    Well, I am not a Linux expert, what is the safest way to accomplish this?
    Thanks in advance

     
  • Ruven

    Ruven - 2010-01-13

    The deb does not install lighttpd or libfcgi, but just includes a lighttpd
    configuration file, so installing it will not damage your Apache environment
    in any way.

     
  • DGSL

    DGSL - 2010-01-14

    Sorry, I was pretty sure that the deb file at oldmapsonline.org included
    lighttpd and iipmooviewer installations by default. Perhaps they changed the
    contents of deb file from the original release?? Or could be I am just crazy
    :(

    Whatever. I reinstalled it from deb and it works over my Apache server (to be
    safe, I am still testing on a VirtualBox). But now I have some questions:

    • I just copied the /usr/lib/cgi-bin/iipsrv.fcgi to the path of my previous installation at /var/www/fcgi-bin/iipsrv.fcgi ... so now, I assume my previous configuration lines at apache2.conf file are now being used by this new installation. Is this correct?

    • As I mentioned in the 4th post of this topic, the deb installation is still returning the "nearest available resolution" when I request a .jp2 of a certain WID. You mentioned you would correct it when releasing source code. But as I can't use the source code release to generate a jp2 compatible iipsrv.fcgi ... how can I solve this? Once that I have installed the deb file containing kakadu libraries, may I keep on compiling your future svn updates without losing the current jp2-kakadu functionality?

     
  • Ruven

    Ruven - 2010-01-14

    Or could be I am just crazy :(

    No comment ;-)

    • I just copied the /usr/lib/cgi-bin/iipsrv.fcgi to the path of my previous
      installation at /var/www/fcgi-bin/iipsrv.fcgi ... so now, I assume my previous
      configuration lines at apache2.conf file are now being used by this new
      installation. Is this correct?

    Yes, that's correct. The configuration directives for JPEG2000 handling are
    the same.

    • As I mentioned in the 4th post of this topic, the deb installation is
      still returning the "nearest available resolution" when I request a .jp2 of a
      certain WID. You mentioned you would correct it when releasing source code.
      But as I can't use the source code release to generate a jp2 compatible
      iipsrv.fcgi ... how can I solve this?

    Yes, for JPEG2000 it only resizes to the nearest resolution. I will fix this
    for the final release of version 0.9.9. There will be updated binaries when
    this happens. I've no idea when this will be. A few months at least.

    may I keep on compiling your future svn updates without losing the current
    jp2-kakadu functionality?

    No, to compile, you will need the kakadu library source. If you don't have
    this, iipsrv will continue to compile and work with only TIFF support.

     
  • DGSL

    DGSL - 2010-01-14

    Thanks a lot. Despite I would like if you can tell me a bit more on your last
    answer:

    to compile, you will need the kakadu library source. If you don't have this,
    iipsrv will continue to compile and work with only TIFF support

    Kakadu libraries can be downloaded and installed for non commercial use. So,
    wouldn't it be theoretically possible that iipsrv used them as preinstalled
    shared libraries (if available), instead of needing to compile their sources?

    I don't know, perhaps that woul make it slower. Just wanna know a bit more on
    how the stuff works.

    For example, it is required that I have a previous installation of a web
    server, and fastcgi ... I don't have to get their sources in order to be
    compiled together with iipimage server source code. Well, perhaps it's not a
    good example but you got the idea: wouldn't it be possible to do the same for
    kakadu software? If it is preinstalled, iipsrv uses it (so it can read jp2
    files). But if it is not, then it doesn't.

     
  • Ruven

    Ruven - 2010-01-14

    No, to compile iipsrv with even things like libtiff or libjpeg requires you to
    install the source code or at least development header files for those
    libraries.

     
  • DGSL

    DGSL - 2010-01-15

    Thanks a lot for your explanations, Ruven. So oldmapsonline payed kakadu
    sources to compile and redistribute a binary for the non-commercial users.
    Right? Thanks a lot to them also. I'll stop using subversion right now

    But with respect to the new jpeg2000 functionality, I have a thing to solve:

    • When using WID/HEI+CVT on pyramidal tiffs, I know the server returns a bit smaller image (just one pixels rounding or so). Not a big problem.
    • When using WID/HEI+RGN(1,2,3,4)+CVT on pyramidal tiffs, I know the server returns a WID3 (or HEI4) image. So, to avoid having to resize the images, I will try to correct my request in advance to be WID/3 (or HEI/4).

    As iipsrv will not work this way with jpeg2000 files before a few months then
    I have to face an additional workaround in the meantime, including image
    resizing using PHP. To not lose quality, I will have to resize from bigger to
    smaller images, so I will have to request a bigger image to iipsrv.

    For jpeg2000 iipsrv is serving the "nearest" available resolution, and I guess
    it tends to be a bigger version of the image but I am not sure if this always
    happens (if you request WID=200, you'll never get a 199 even if it is "nearer"
    than 300, is this correct?).
    Specially, what would happen if the Max-width is not a power of 2? You will
    always find a non integer width if you go further dividing /2
    So, If there is file which is 9999 pixels wide, the next smaller resolution
    would be 5000 or 4999? How can I calculate this?

    Then, I still need to apply the WID/3 correction if I am also requesting a
    certain RGN. So it's essential for me to know exactly which resolution is
    gonna be used by iipsrv for a certain WID request.

    Thanks a lot in advance again

     
  • DGSL

    DGSL - 2010-01-15

    Well, as they are numerical parameters, when I said RGN(1234) in my last post
    I should have used letters: RGN(abcd), WIDc, WID/c, HEId and so on ... I
    hope you've all understood what I meant

     
  • Ruven

    Ruven - 2010-01-15

    For jpeg2000 iipsrv is serving the "nearest" available resolution, and I
    guess it tends to be a bigger version of the image but I am not sure if this
    always happens

    It should give you the nearest resolution that is equal to or larger than what
    you request.

     
  • Eoghan O Carragain

    Hi,
    I just wanted to check whether exact scaling for Jpeg 2000 files made it into
    the 0.9.9 relase in the end.

    I've tried the following, but the jpeg returned is 243 pixels in width: /fcgi-
    bin/iipsrv.fcgi?FIF=/jp2s/test.jp2&WID=150&CVT=JPG

    Am I missing a parameter or has this not yet been implemented for jp2?

    Many thanks,
    Eoghan

     
1 2 > >> (Page 1 of 2)


Anonymous

Cancel  Add attachments