News:

cpg1.5.46 Security release - upgrade mandatory!The Coppermine development team is releasing a security update for Coppermine in order to counter recently discovered vulnerabilities. It is important that all users who run version cpg1.5.44 or older update to this latest version as soon as possible.[more]

When you choose to place it into the theme's tables, and force/change the upper border positively (in my case, +75), the table background goes wonky (see example). Also, when you use a set width, if it's less than the normal table, it happens on the sides as well.

Had to look up wonky in die dictionary (according to dict.leo.org, this should mean "schief, schwach, wachelig" if other germans read this hehe). I fail to reproduce what you mean; in the end, what I see is just an Imageflow effect that's moved down 75px and works as intended. The table background color of the Max OSX theme isn't that beautiful; I'd probably place it outside a table in this case.

Edit: Tried again looking for that bug. Now I can reproduce it, but only with IE and certain skins; other browsers like Firefox or Opera work just fine, same is true for other skins in IE (e. g. igames - http://www.hobert.net/gallery/index.php?theme=igames ). Is this correct? If yes, I will have a closer look at it.

BTW: Some pics in your gallery cannot be displayed in Imageflow correctly because you use special (forbidden) characters in file names like spaces. Best solution would be to use valid file names, but I'll have a look at it for future versions. I know the problem; earlier versions of Coppermine did allow these characters indeed, newer versions don't.

version 1.4 displays pics in portait format (height > width) a little bit smaller to ensure that pics even in format 2:3 don't overlap the top border of the imageflow DIV and cover menu buttons or other contents of the page. The size of pics in landscape format (width > height) is the same as in the previous versions. IMO that's quite sensible, because if pics in portait format would be displayed with the same width as pics in landscape format, there would be a huge amount of wasted space when displaying the latter. One shouldn't see it as shrinking of portrait mode pics, but rather as an enlargement of landscape mode pics to better use the given space.

Sorry, I can't make this optional, because the beautiful new algorithm to scale pic sizes exactly when using fixed pixel value as Imageflow width wouldn't work anymore. I hope you can live with it.

Highslide works perfectly together with ImageFlow, assumed that you use both latest versions (HS 3.03, Imageflow 1.4). Look at my demo gallery, where Highslide, ImageFlow and Slider live together in peace and harmony:

If i set the width to 100%, all the pictures are "verpixelt" (don't know the english word). Possible of cause the display resolution (1920x1200). Also it would be nice, to have the possibility to set a max high, because of this huge resolution, the imageflow is really big.

Hi Megachip,

thanks for your feedback.

To improve image quality in 100% mode for very big screen resolutions, first step would be to set the corresponding paramter (reflect images have % size of original image) to 100%. If this still isn't enough, open codebase.php and find the line

$imageflow_file="albums/".$imageflow_row['filepath'].$imageflow_row['filename'];This will greatly improve image quality for very high screen resolutions at the cost of greatly increased loading times - there's nothing free in this world.

Please note, that I recommend to use a fixed pixel size value for Imageflow width for best possible image quality at quickest loading times. See README.TXT.

Regarding the space the animation needs: This is not my script, see the credits section in initial post of this thread. I am not interested in creating a development branch of the original Imageflow.js, but I'll take what Finn (the developer) delivers and improve it as far as I can without too much work.

$imageflow_file=get_pic_url($imageflow_row,$IMAGEFLOWSET['imageflow_pictype']);to get the pic url, where $IMAGEFLOWSET['imageflow_pictype'] is the value you set yourself in the plugin settings (either normal or fullsize). You can find this at line 187 or 251 of codebase.php.

I am a bit shocked - up to now I didn't think that get_pic_url($pic_row,'normal') had to be checked or sanitized in any way. So what you say is that this function will only deliver the url if an intermediate size pic is generated, and if not, it will deliver nothing or a link to a non-existent intermediate pic? What do you suggest to replace it with?

is the value you set yourself in the plugin settings (either normal or fullsize). You can find this at line 187 or 251 of codebase.php.

As I said, this is not an option - you could of course pick the full-size pic to be used, but that would not be a bright idea - as I said, someone might have uploaded a file that is smaller than the intermediate dimensions; others might upload the max allowed dimensions, so the imageflow strip might be a mixture of both. Using the full-size in that setup would slow down the imageflow considerably. What I suggest is performing some if/then checking in the plugin's core if an intermediate exists and use that. Only if it doesn't exist, the full-sized should be used.