Eager to view the goodness that is ZP 1.1.4, I recently upgraded my site. I'm glad that you can now (again) click the image to view its full-sized version. I can now do this with images I had previously uploaded via sftp, but I get an error when trying to do so with recently uploaded images --i.e., images I had uploaded via the web admin UI. (Fwiw, uploaded when my site was running Zenphoto 1.1.3.)

For example, clicking on the image in http://zenphoto.iwaruna.com/food/cupcakes.png.html results in a nearly empty page with the following text:

`http://zenphoto.iwaruna.com/food/cupcakes.png.html?p=*full-image`

I've tried clearing/refreshing the cache ("pre-cache images") and refreshing the database, but those tasks didn't help. Is there anything else I ought to try? Or perhaps I'm running into a bug?

Are the newer images larger than the older ones? You may be running into a memory limit. Also, please check your CGI error log to see if there have been any error messages.

I downloaded your cupcake image, put it on my site, and viewed it full image size with no problems.

Unfortunately, I don't have access to my PHP error log for that site (it's on Dreamhost). That probably means I won't have access to making a custom php.ini (if it's due to hitting a memory limit) --but if other Dreamhost users have workarounds for this, I'd be happy to hear 'em.

However, I do have a local test installation using MAMP, and I experienced the same issue there. My PHP error log displayed a couple of warnings:

`[01-Feb-2008 14:47:05] PHP Warning: imagepng() [function.imagepng]: gd-png: fatal libpng error: zlib failed to initialize compressor in /Applications/MAMP/htdocs/zenphoto/zp-core/full-image.php on line 54

[01-Feb-2008 14:47:05] PHP Warning: imagepng() [function.imagepng]: gd-png error: setjmp returns error condition in /Applications/MAMP/htdocs/zenphoto/zp-core/full-image.php on line 54`

Not sure if those messages are relevant. I'll also test with a smaller image sizes, since those new ones are larger than previous files. (It's odd, they're only about 1MB .png's...)

Well, those errors may well be the problem. I don't know what would cause them, though. If you don't care if the images are watermarked or password protected then tonights nightly build will probably resolve the problem for you. There will be a new option in the admin image display optons for "protect_full_image". If you reset that option the image will load directly from your albums folders and not go through the full-image.php filtering.

I converted the photos to .jpg, and this problem no longer occurs. I tried smaller versions of the .png file (started at 1200 pixels for longest side (~1MB in size), then tested with 800 (<600KB) and 400 pixel (<200KB) resized pngs), but none of them worked. How odd! Fwiw, I used Preview.app (on Mac OS X 10.5.1) for the file resize and file type conversions.

It's strange that the original 1200 pixel (~1MB) png loaded fine, full-sized on your ZP site. Wonder why my sites won't handle displaying the full-sized png format. (At least using another file type works around my issue.)

Strange, I am using MAMP (on OS X 10.4.11) too, but I never tested PNGs, but always JPGs and never had any problem. I will see if I can reproduced that PNG problem.

I asked Google about the first gd-png error, and found a helpful page where they encountered this problem after upgrading from PHP 4 to PHP 5. Indeed, both MAMP and Dreamhost are running version 5 for me (eg, 5.2.3 in MAMP 1.7).

There's a partial workaround. Go to Admin Options > Image Display and change "Full image quality" from a value between 1 and 100 to a value between 1 and 10, eg, 8. After that, full-sized png's load fine. This disadvantage, though, is that full-sized jpg's look horrible. Guess the value for png needs to be divided by 10 in the source?

As an experiment, I changed line 54 in `full-image.php` to

` case 'png':

imagepng($newim, NULL, ($quality/10));

`

Viewing both jpg and png at full size now works so far. Not sure if this is ideal (my programming skillz are a bit rough'n'ready, I'm afraid), as it would likely break on PHP 4 installations.

According to the PHP manual, 0 is best quality and 9 is worst quality. So, I think we have to invert the value as well as scale it down to 0-9. Nice that they made this "consistent" with imagejpg--it uses 0 as worst quality and 100 [sic] as best quality.

Also, as best as I can tell from the documents, this parameter is ignored on PHP 4 for imagepng.

We will update the code to deal with this.

Oops, right, 0-9, not 1-10. SBillard and Acrylian, thanks for looking into this!

try the following:

` case 'png':

if ($quality = 100) {

$quality = 0;

} else {

$quality = round((99 - $quality)/10);

}

imagepng($newim, NULL, $quality);

break;`

Looks good. Tested with PHP 5.2.3 and 4.4.7 on MAMP, and PHP 5.2.3 on Dreamhost.

Thanks. It will be released. (I don't have php 5 to test on.)

i have the same problem with small (~640x480) .jpg files since i upgraded to 1.1.4

**edit:
i just solved it. i have a custom watermark. i disabled watermark in the options menu in admin, clicked 'ok', then enabled it again, clicked ok and now it works.

Glad it works. Must have been a problem with the cached image. The steps you took essentially cleared out the cache.