View Full Version : Problems with the Gallery Demo...

May 2nd, 2005, 03:54 PM
When I attempt to view the animals demo gallery, only about the 1st 4 rows of images loads -- the rest are just placeholders. So, if I switch to view 30 images or 90, etc., I get the problem. According to the load status at the bottom of the browser, the page never finishes loading.

It seems like IE is being overrun, since after that, all graphics have trouble & I have to quit and relaunch. I would have posted this in the troubleshooting section, but I don't have access. When I try viewing the "nature" gallery, the problem doesn't happen.

Any idea what might be causing this? Could there be a corrupted image?

The browser I am using is IE5.5, plenty of available RAM & disk space.


May 2nd, 2005, 04:03 PM
Strange... They all show for me. (IE6)

May 2nd, 2005, 04:14 PM

Would you mind giving the exact link you where at when you saw the problem?


May 2nd, 2005, 04:21 PM
Sure - I know it's a little strange...but not sure why it's happening...

Here's the link:

Animal Gallery Demo (http://www.vbadvanced.com/gallery/browseimages.php?c=5)

Ah, the file it gets stuck on is /gallery/files/0/127.gif.

Errm...no attachments allowed? Why not?

OK...here it is the hard way:
Animal Gallery Screen Dump (http://www.fishindex.com/members/davey/animalhang.gif)

Hope this helps...I'll see if it's repeatable on the same image.

May 2nd, 2005, 04:23 PM
Hmm...still hung with 78 items remaining, except that this time, it was:


Attempt #3, 78 items remaining, hung at:


Attempt #4, 77 items remaining, hung at:

cat_thumb.jpg may be a culprit...didn't load this time either...

May 2nd, 2005, 04:35 PM
Hate to say it but it looks like either your internet connection or your browser is timing out.

May 2nd, 2005, 04:50 PM
works fine for me.

May 2nd, 2005, 05:05 PM
Hmmm...it doesn't seem like a timeout problem on my side. I have no trouble showing the Nature Demo Gallery (http://www.vbadvanced.com/gallery/browseimages.php?c=4) which has 12 rows of images.

I think it has to do with the thumbnails. Is it possible that there is some image format difference (or minor corruption or header info omission) which IE6 can handle that IE5.5 can't?

Also, I have no trouble with Google's thumbnail spewing on their image search.

Any other ideas? Is it possible this is a web server issue on the vbadvanced side?

May 2nd, 2005, 05:11 PM
OK...taking another approach. I tried manually downloading the cat_thumb.jpg file:

cat_thumb.jpg (http://vbadvanced.com/gallery/files/8/8/2/3/cat_thumb.jpg)

It downloaded, but it took a long time - something on the server side, not my side -- maybe a GD issue?

Anyway, after caching that image, I was able to load the whole gallery without any trouble.

There is something different or wrong with the file:

...in combination with IE5.5

Confirmed: without cat_thumb.jpg, the page load hangs, with the file cached, the page loads normally. Something is up with serving that thumbnail to IE5.5 simultaneously with others...

May 2nd, 2005, 05:17 PM
OK...taking another approach. I tried manually downloading the cat_thumb.jpg file:

cat_thumb.jpg (http://vbadvanced.com/gallery/files/8/8/2/3/cat_thumb.jpg)

Took me about 1 second to dl that image dirtectly. Took about 3 seconds to download the actual page with all images. I think it is on your side. Done with both IE 6 and Firefox.

May 2nd, 2005, 05:28 PM
It looks like it has to do with the EXIF header data in cat_thumb.jpg. It's not a problem on my side -- other than possibly and anomaly with IE5.5 and EXIF data. cat_thumb.jpg is the only image that seems to have EXIF and the only image that seems to choke the browser.

May 2nd, 2005, 05:32 PM
FishIndex, I don't *think* I have any IE 5.5 machines around here anymore but I'll see if I can find one.

May 2nd, 2005, 05:42 PM
The cat_thumb.jpg is 101x150, but the embedded EXIF data reports it as 339x505. Besides the fact that the thumbnail is not 339x505, if scaled up from 101x150, it would be 339x503. Should EXIF data be stripped when generating the thumbnails? If so, then when vbaGallery generates the thumbnails, wouldn't this be a bug?

Anyway...I don't mess around with EXIF too much. Just trying to figure out why the gallery doesn't load.

- Dave

May 2nd, 2005, 05:51 PM
OK, Mozilla 1.4.3 on Linux works..... :p Still haven't found a 5.5 box yet though.

May 2nd, 2005, 05:59 PM
This is the reason for the problem:

Photoshop 7 JPEG Files and Browser Incompatibilities (http://www.photo.net/bboard/q-and-a-fetch-msg?msg_id=003j8d)

The EXIF data in cat_thumb.jpg also indicates that it was created by Photoshop 7 (probably not with the "save for web" feature). So, that explains the problem. The symptoms of choking the browser and having to quit and relaunch is exactly how my version of IE5.5 was behaving. I do my IE6 testing on another box. I don't upgrade this one for exactly this kind of reason.

You might want to consider how to handle this issue within vbaGallery, particularly when you generate thumbnails, if you feel it impacts the robustness of the product. I don't know what other browsers this might affect or related situations where this kind of problem might occur. It's probably worth some research time on the development side to gain a better understanding of how EXIF and embedded preview data might help or hurt your product. It looks like many of the cutting-edge digital products and software are leaning this way...

Anyway...I hope this has helped.

- Dave

ps. Also, it may specifically be with the embedded preview data where the problem exists, not with the resolution info.

May 2nd, 2005, 06:18 PM
I've done a little more poking around and this definitely seems like an issue for you if you want to maintain maximum browser compatibility. The image upload process should probably go something like this:

1. Parse the EXIF/JPG header data
2. Populate db text fields
3. Strip embedded preview/EXIF data (perhaps saving it to a private db field for later reconstitution by the owner of the image)
4. Generate and store the thumbnail (no embedded data)
5. Store the full res image (no embedded data)

This would ensure that anyone viewing either the thumbnail or main image would not suffer the browser choke problem.

Also, for direct uploads, you should have a scan tool that can bulk-process gallery images/thumbnails and do the stripping after the fact.

Just some suggestions for absolutely clean browser/gallery compatibility...

May 2nd, 2005, 06:25 PM
Stripping the EXIF data from the thumbnail would be the right thing to do, stripping EXIF from the original images defeats the whole purpose of having EXIF data in the original image.

May 2nd, 2005, 06:37 PM
...probably not if you save it for later reconstruction. Someone browsing the gallery has no use for the EXIF data -- especially if you parse it and populate essential text fields. The only person who might theoretically need it is the owner if they are using vbaGallery as their main hi-res image archive with additional scaled-down versions. But...there are probably a bunch of privilege, security, (and perhaps paid) features that would need to go into place before that could happen.

Anyway, if the photo owner has the original image archived with full headers and has a lower res one for the gallery with its thumbnail, neither thumbnail nor web view needs the extra header data. I would need to have a look at the data structure and think about it a little more, however. This is just my initial reaction in trying to think practically about how people use your product based on its current capabilities.

Do you currently parse and display EXIF data, or are all the extra fields user-entered?

May 2nd, 2005, 06:51 PM
Anybody who runs a photography related website would be joining a lynch mob going after Brian if he started touching the original image, especially the EXIF information.

The EXIF info is parsed from the original file and stored in tables.

Before you go full-force into this just wait until Brian has a chance to take a look at this thread and go from there; if the EXIF info is being preserved into the artificially created thumbnail then most likely the solution is to change that as there is no need for EXIF in the thumbnail.

May 2nd, 2005, 06:55 PM
Just thinking out loud - these are really just suggestions...

I definitely agree with you about the thumbnail. The question is what happens to browsers viewing larger size images with the embedded data?

...just trying to help out while checking out the goods. :)

May 2nd, 2005, 07:01 PM
This gallery image:

The Pups (http://www.vbadvanced.com/gallery/showimage.php?i=526&c=2) would appear to have certain embedded info (but maybe not preview data) and views OK in IE5.5.

Lizard King
May 2nd, 2005, 07:21 PM
Took me about 1 second to dl that image dirtectly. Took about 3 seconds to download the actual page with all images. I think it is on your side. Done with both IE 6 and Firefox.
Sama with me :)

May 2nd, 2005, 07:34 PM
Actually, I would be willing to bet that other people have seen this problem and just ascribed it to the browser and left it at that without realizing that it potentially had another contributing root cause. Also, it may not happen when viewing an individual image, in addition to the fact that it may or may not be a legacy browser issue. It may also only happen when the file with embedded data is in a stream of other image data (such as gallery thumbnails).

Also, from a coding standpoint, a consistency check between reported EXIF/JPEG resolutions might be a good idea. They should match, right? If not, then there may be something suspicious with the file (perhaps if not a thumbnail). Some of this logic might also apply to TIFF or other formats, if/when they are supported.

May 4th, 2005, 11:29 AM
Further to my above comments about stripping EXIF data from larger gallery image views in addition to the thumbnails, it seems that is exactly what flickr.com does with its open tagged image sharing engine.

For example:
Single Gallery View Image (http://www.flickr.com/photos/tejana/12108739/)
Extracted EXIF data -- displayed under "more properties" (http://www.flickr.com/photo_exif.gne?id=12108739)

However, if you directly download the image:
falls bridge (http://photos9.flickr.com/12108739_edc68f772b.jpg)
...you will see that it has no embedded EXIF information.

There must be a reason why they do it...and it's probably for compatibility.

Also, the concepts of open tagging/keywords and shared relevance are very cool and would certainly benefit any gallery product.