#1775 Image Gallery: Turning on image scaling breaks "next image"

v1.8.4
open
nobody
6
2004-12-06
2004-12-06
Scott Fuhrman
No

Running TW 1.8.4 (Polaris)

When using the image gallery, I have found a problem
when using the image scaling.

When I turn image scaling on for a specific gallery,
then go to browse that gallery, the links created for
the "next image" button, and possible others are not
working correctly. I have been able to reproduce this
bug. When I turn scaling on, things are broken. For
instance, when I browse the gallery and click on the
next image button, the next image that loads is from a
completley different gallery. It appears that the
"imageId=" is incorrect in the link.

Examples:

This gallery has scaling turned off, and is working fine:
http://www.scottandjenn.com/tiki/tiki/tiki-browse_gallery.php?galleryId=16

This gallery has scaling turned on, and when you browse
the gallery by clicking the "next image" button, it
randomly screws up the next image, showing images from
another gallery:

http://www.scottandjenn.com/tiki/tiki/tiki-browse_gallery.php?galleryId=5

Things I have tried:
-Switched from GD to Imagick, made no difference.
-On a gallery that has scaling enabled, if I remove the
"&scaled&xsize=800&ysize=600" from the end of the URL,
the image loads fine.
-Turning scaling off makes the gallery work fine.

I can be reached at scott at scottandjenn dot com if
further information is needed. The scaling was an
important feature because I like to keep the images in
their original hi-res format in case I want to print
them or something later on, but I like them scaled down
when people are just browsing the gallery, to eliminate
all the side-scrolling.

Discussion

1 2 > >> (Page 1 of 2)
  • Scott Fuhrman
    Scott Fuhrman
    2004-12-06

    • summary: Image Gallery: Turning on image breaks "next image" --> Image Gallery: Turning on image scaling breaks "next image"
     
  • Scott Fuhrman
    Scott Fuhrman
    2004-12-06

    • priority: 5 --> 6
     
  • Damian Parker
    Damian Parker
    2004-12-07

    Logged In: YES
    user_id=458483

    scaling values should be entered as 800 x 800 and the
    longest side on the original will be scaled to 800. In 1.9
    this has changed to only allow 1x value (no more x and y).

     
  • Scott Fuhrman
    Scott Fuhrman
    2004-12-07

    Logged In: YES
    user_id=672035

    I tried using 800x800 as per the follow up, still does not
    work correctly.

     
  • tom chmara
    tom chmara
    2005-03-02

    Logged In: YES
    user_id=668092

    I have had this problem on Tiki 1.8.5 on a Libranet (Debian
    Linux variant) distribution with PHP 4.3.10 and MySQL
    3.23.49. I uploaded 16 images to a new gallery (my eighth);
    all but one were 3008x2000 pixels; the gallery (using
    imagick to do the graphics processing) is set to scale to
    640x480. (this gives me both large images for printing, and
    small images for display). I have not tried to perform this
    with a gallery without scaling set. However, perhaps the
    added detail below helps to diagnose the cause.

    When I try to view the gallery, the ">" button periodically
    has the WRONG URL (right gallery number ("8")): instead of
    (say) "55" it'll be (e.g.) "22" - and shows me a photo (that
    is actually from gallery #2). Occasionally, it will have
    the "right" value, and there appears to be some "stickiness"
    - once the right image has been displayed, I have not seen
    the "wrong" one appear on the same transition (but perhaps I
    simply haven't watched closely enough). If I choose the
    "back" button on the browser, and then re-try the ">"
    (sometimes I need to do this more than once but usually it's
    on the next try) ultimately I'll move to the "correct"
    (next) image in the gallery.

    I have also been having trouble with actual execution of the
    scaling operation: when selecting ">" the URL will sometimes
    end in "&xsize=0&ysize=0&scaled" (though sometimes it'll be
    "&scaled&xsize=640&ysize=480" - the "&scaled" will appear
    earlier or later in the string, and the scaling factor is
    always 640x480 or 0x0, but I can't a priori predict which).
    Often this will still result in display of a 640x480-scale
    image, but sometimes in a full-res (i.e. way too large!)
    image. The "^" button will sometimes give me a
    proper-resolution image in such a case, but sometimes will
    simply re-display the huge version. On occasion, I also get
    no image - just a box with the word "image" in it; if I
    click on that word the image (often the scaled image but
    sometimes the huge one) will display. Other times doing
    exactly the same thing will result in the proper scaled
    image; once the scaled image is finally properly rendered I
    can go back through the gallery and things appear to work
    properly.

     
  • tom chmara
    tom chmara
    2005-03-06

    Logged In: YES
    user_id=668092

    Just a further note - with the images where scaling is
    "broken" (i.e. I get a full-res image where I wanted the
    scaled one) - if I paste the URL
    (http://hostname.domainname.ca:8080/tiki/tiki-browse_image.php?offset=0&sort_mode=created_asc&desp=15&galleryId=8&imageId=62&xsize=0&ysize=0&scaled)
    into the location bar - and DELETE the "&xsize=0&ysize=0" -
    I get the image, properly scaled. I've also found that in
    some cases (again, this appears somewhat random in nature)
    the size params in the ">" or "<" URL are "&xsize=&ysize="
    (i.e. no numeric values) and it appears to render properly.

    From the bug report logs, there appear to have been few
    people available to work on tiki bugs over the past while.
    I've tried to do some looking at tiki-browse_image.php
    myself, but I find the code a bit opaque (validating the
    $_REQUEST value for "galleryId" on line 33, then overwriting
    it on line 90...there is I presume some reason here
    (galleryId in the database doesn't match the one offered in
    the POST?) but I can't decipher it. Are there any documents
    on the coding standard for tiki which might help me figure
    out the intent?

     
  • oudeis
    oudeis
    2005-03-18

    Logged In: YES
    user_id=1222219

    I have been looking into this problem, and have found that the
    link is only incorrect for images of which there is no scaled
    version. So every image that is scaled at runtime will have
    incorrect links to the previous and next image. If there already
    is a scaled version, the links will be correct.

     
  • oudeis
    oudeis
    2005-03-18

    Logged In: YES
    user_id=1222219

    The following change in tiki-browse_image.php provides a
    workaround.

    The important part here is that $_REQUEST['galleryId'] is not
    overwritten with the value from $info['galleryId']. Somehow
    get_image_info returns an incorrect galleryId if the image has
    just been scaled for the first time.

    --- tiki-1.8/tiki-browse_image.phpff -u 2004-05-17
    01:23:36.000000000 +0200php
    tiki/lib/imagegals/imagegallib.php
    +++ tiki/tiki-browse_image.php 2005-03-18
    11:17:26.854126460 +0100
    @@ -86,8 +86,9 @@
    $smarty->assign_by_ref('prevt', $prevt);

    $info = $imagegallib->get_image_info($_REQUEST
    ["imageId"], $itype, $sxsize, $sysize);
    -$gal_info = $imagegallib->get_gallery($info["galleryId"]);
    -$_REQUEST["galleryId"] = $info["galleryId"];
    +$gal_info = $imagegallib->get_gallery($_REQUEST
    ["galleryId"]);
    +//$gal_info = $imagegallib->get_gallery($info["galleryId"]);
    +//$_REQUEST["galleryId"] = $info["galleryId"];

    if (!isset($_REQUEST["sort_mode"])) {
    $_REQUEST["sort_mode"] = "created_desc";

     
  • oudeis
    oudeis
    2005-03-18

    Logged In: YES
    user_id=1222219

    After some more digging, I now know what the problem is. I
    don't have a solution other than the workaround I already
    posted.

    The process of displaying an image is as follows:
    1. tiki-browse_image.php is called to display an image. It
    looks up all info regarding the image, and finds the
    imageIds of the previous and next image. It does NOT
    retrieve the requested image.

    2. The template tiki-browse_image.tpl is shown. In this
    template the requested image is inserted with a regular img
    tag. The src for the image is "show_image.php?imageId=xxx".
    In show_image.php, the requested image is retrieved, and
    scaled if the scaled version is not yet available.

    In step 1, the info of the scaled image is retrieved. But if
    the image is viewed for the first time, there is no scaled
    version, and get_image_info returns nothing.
    $_REQUEST['galleryId'] is still overwritten, but the value
    is now undefined.

    A simple fix would be to call get_image($_REQUEST['imageId']
    followed by get_image_info, if get_image_info returns
    nothing. The scaled image will be created, and the correct
    information about the scaled image will be retrieved as well
    (instead of the information of the original image, as it is
    now).

    The problem with this approach is that loading a page might
    appear to take longer, because you only see the page after
    the scaled version has been created. At the moment, you see
    the page without the image, and as soon as the image has
    been scaled, it is shown.

     
  • ikenticus
    ikenticus
    2005-03-22

    Logged In: YES
    user_id=1244296

    I am new to TikiWiki (only installed it last week) and had
    come across this bug last night. I'm glad that somebody
    else had seen the same issue. The patch listed here
    *seems* to have fixed the problem with the "next image"
    randomly pulling an imageId from another gallery but I'll have
    to test it some more.

    However, not sure if you guys are having the same problem,
    but "last image" seems to be retrieving the wrong imageId as
    well whereas "first image" seems to work just fine. I noticed
    this only because when I click on "last image" the "next
    image" icon is still displayed an browsing the gallery to the
    real last image confirms that the "last image" reference was
    previously incorrect.

     
1 2 > >> (Page 1 of 2)