Print

[ksala]

I will try once again to get some help with this problem about Photo Gallery’s inability to ‘batch add files’ for photographs above a certain size in portrait orientation while the same sized photos in landscape orientation work perfectly well.  I am very wary of using the ‘b-word’ but I feel confident that this anomaly is either a bug, a glitch, or an "undocumented feature".

I have a collection of photos in Kodak PhotoCD format (.pcd).  Upon opening such a format, one is presented with a choice of image resolutions, in this case, ranging from 96x64 pixels all the way up to 3072x2048 pixels (each level doubles both the width and height in pixels of the photo).  I am working with the 3072 x 2048 pixel size as well as the 1536 x 1024 pixel size.

I ‘extract’ the set of photos as 3072x2048 jpeg files and place them into two folders.  The first folder consists of  22 images, ALL of them landscape orientation (3072 pixels wide and 2048 pixels high).  The second folder consists of 32 images, 19 of them in landscape mode and the remaining 13 in portrait mode (2048 pixels wide and 3072 pixels high).

I upload all of these photos via FTP (I use WS_FTP Home) to 2 separate folders on my website.  These two sets of images are destined to go into two separate folders called “Group” and “Banquet” (22 in Group and the other 32 in Banquet).

As admin, I run “Batch add files” and select the Group folder.  All 22 images are processed and a thumbnail is visible for all.  I select the “Group” album and then click on “Insert selected files”.  Everything runs perfectly, I get “OK” for all 22 photos, and, sure enough, the album works perfectly when viewed.  Note that the usual admonitions about permissions, etc. are not relevant here – the processes ARE working (in truth, this is not really a ‘upload’ or ‘permissions’ problem but there is no specific category in the forum to deal with this one).
When I go through the same steps for the other set of 32 images, the “Batch add files” process only partially works in that thumbnails are seen ONLY for the 19 landscape orientated images and NOT for the 13 portrait images.  The latter produce a grey box icon with a small cross in it.  Clicking on this produces a ‘page not available’ display but no error name or information.  If one plows ahead and runs the “Insert selected files” for all the 32 photos (all checked), the “OK” button appears ONLY for the 19 landscape photos.  The other 13 portrait photos show only a grey box with the cross.  Clicking on any of these simply brings up the ‘page not available’ display but, again, no error code or message.  Looking directly into the folder on the website, it is noted that the ‘normal’ and ‘thumbnail’ files are produced only for the 19 landscape photos.
So the process of adding FTP uploaded files of images which are 3072x2048 pixels works perfectly while the same process for images which are 2048x3072 pixels fails completely!  Very odd.
In the config, have set the max dimension to 3600 and the max size to 2048 KB (actual jpeg files range from 400 KB to 900 KB).

In one attempt to get around this annoying problem, I returned to the set of images with mixed orientations and rotated all of the portrait photos to a landscape orientation.  Then upload these 32 photos and run through the ‘batch add files’ process as above.  All 32 images are correctly processed and placed into the album.  However, when I then attempt to rotate the 13 images which are truly meant to be portrait, I consistently get an error and Photo Gallery will not rotate these images using the admin panel functions.  I have GD2 selected – ImageMagik is apparently not installed on my server.  This observation has me wondering whether the above “anomaly” is due to Photo Gallery or possibly a quirk of GD2?


However, these is one way to get around this limitation.  I produce a separate set of 32 images (for the Banquet folder) at 1536x1024 resolution with  the SAME filenames as the higher 3072x2048 images.  I upload these lower resolution images and run the ‘batch add files’ and ‘insert selected files’ routines to create the album on the website.  This all runs perfectly for the lower resolution images and the album contains all 32 photos in the two orientations.
I then upload the higher resolution images into the same website folder and thereby OVERWRITING the files there with the same filenames.  Then, as admin, I run the “Reload file dimensions and size information” from the admin tools on this album.  This, of course, finds that all of the files need to be updated in the database which it then does.  Now the album works and displays correctly with the higher resolution images (but, however, the ‘normal’ and ‘thumbnail’ images correspond to the first used lower resolution image set – the file names are identical so everything works fine with the mySQL database).

The above procedure works perfectly for all of the albums and photos used so far.  I would prefer to not have to do this, of course, since it does slow me down.  It is important for my purposes that visitors to this Gallery can download the highest resolution photos possible hence the lower resolution albums need to be ‘upgraded’ by this back door approach defined immediately above.

Can anyone help me on this?  Why is photo gallery not processing the portrait 2048x3072 images at all while processing and posting the landscape 3072x2048 images perfectly correctly in all cases?  Note that by using the procedure above, I do end up with these high resolution albums with the correct orientations so Photo Gallery is certainly able to handle these albums and images.

The albums can be viewed at www.montessoriconference.ca/fotos

[Nibbler]

Works for me, you are probably hitting server side resource limitations. The 2 files I tested from your site required around 32 MB of memory to process. If your memory limit is set to exactly 32MB then the portrait images might be large enough to exceed the limit while the landscape ones are slightly smaller. Due to the way JPEG compression works the orientation of the image affects the image's size.

[ksala]

You may be correct although it seems to me that your explanation can not account for the "numbers".  There are 3 albums at the site (Banquet, Sessions, and Delegates) with different mixtures of portrait/landscape photos.  In each case, if you work with the high resolution images (3072x2048), then 100% of the portrait images DO NOT get processed by the 'batch add files' while 100% of the landscape images DO get correctly processed.  If you examine the file sizes, you can see that several of the portrait image files are much smaller than some of the landscape images.  If this were some server side limitation on size, then one would have to expect that the occasional landscape image would fail to process (never happens) and the occasional portrait image would get processed (also, never happens).  As I said in the original post, I believe this 'quirk' is stranger than your explanation would allow.  After all, the portrait image file would just seem to Photo Gallery or GD to be an 'odd' shaped lanscape image 2048 pixels wide and 3072 pixels high.  But there is something in the php code which is treating the two orientations differently or is somehow giving 'preference' to the significance of the image width versus its height.