Ultimate Slideshow Transparency in Firefox

Script: Ultimate Fade-in Slideshow v1.5
http://www.dynamicdrive.com/dynamici...nslideshow.htm

Hi there. I recently installed the script on a new page and I love it. The only issue is that when I have an image with a large field of color, and the image after it has a lot of detail, those details appear faintly on the preceeding image (perhaps a very low opacity). Very strange indeed. You can see the behavior at the following test URL:

http://iconic-design.net/temp/slideshow.html

You can distincly see the details of the first photo in the last one.

Any ideas?

-Peter

Sorry.. looks ok to me.... I cannot see an issue.. the pictures fade out nicely via my old eyes :)

Hrm. It occurs to me on WinXP, latest firefox, no special plugins. The "leaf" shows a faint echo of the "house". Maybe I'm just crazy. ;-)

I'll take two of what he's having. :rolleyes:

It could just be an after image on your retina or something to do with your monitor but, I can't see it here either:

WinXP FF1.5.0

I'm not crazy! ;-)

I think it has something to do with a very low opacity being set for the temporary or preloaded next image. That, or my flat panel monitor is just set to a very high contrast. I'll test it on a CRT.

-Peter

Nope i dont see it either looks fine to me and im on XP, ive never seen problems with this script

I just cranked up the brightness on my laptop and I did see it! I actually saw two 'opacity bleeds'. The first one appeared to occur as the 'leaf' image was loading the first time, as if it wasn't cached by the browser yet. This made the image before it linger longer than it should. That should be able to be reduced on most and eliminated on all high speed connections by optimizing that virtually monochromatic image and/or perhaps converting it to a .gif. The second bleed occurred while the 'leaf' image was showing and occurs all the time. In this bleed, the lamp post from the next image is faintly visible in the lower right. This is no doubt due to the opacity of the top image not being one. This script was set up to account for an old Mozilla bug that renders a flash if opacity were dynamically changed from anything less than one up to full opacity. FF1.5.0 no longer has this bug. But, the script was written before that and many older Mozilla based (NS and older FF, perhaps others) browsers still have this bug. As you can tell from this thread though, it is barely noticeable.

Well, good to know I wasn't high. Is there any way you can think of to tweak the script for newish browsers?

I also noticed a lack of "fade" on the newest Safari (I'm fond of testing my sites at the local Apple store.)

-Peter

I already told you how to prevent the previous image from bleeding[1]. There is no test (as far as I know) to determine what version of the Mozilla browser engine you are dealing with so, the only way to fix the second type of bleed would be to use code that will cause flashing on older FF and NS (and perhaps other) browsers. But, what the heck, folks are always trading up so, perhaps that isn't such a bad idea. The way to fix that is to find the two spots in the script that have:

/101

Make them:

/100

OK, on to Safari. I have been after DD to update the script for Safari, my version is here.

It has 4 occurrences of /101 that should be changed to /100 if the small amount of type 2 bleeding is of great concern to you.

Quote:

---

[1]
The first one appeared to occur as the 'leaf' image was loading the first time, as if it wasn't cached by the browser yet. This made the image before it linger longer than it should. That should be able to be reduced on most and eliminated on all high speed connections by optimizing that virtually monochromatic image and/or perhaps converting it to a .gif.

---

It also occurs to me that preventing previous image bleed on the first run through of the show would also be enhanced if ALL the images were optimized. This and my previous suggestions on this for the leaf image are all geared to reducing the load/cache time of the images. Cached images are the best defense against this type of bleeding.

Thanks very much for the fix and suggestions.

I've tried to increase the JPG compression ratio as much as possible while keeping artifacts to a minimum. GIF and PNG don't work so well with the kind of detail in the paintings. I've changed the "leaf" image to a PNG, about 10KB, not bad at all.

I noticed that the script does preload, but most of the images are in the 80-100KB range. I wonder if there's a simple way to hold off on progressing to the next slide until the image is fully loaded?

By the way, I've used DynamicDrive for about five years now, and I never thought to click on the "forum" link. What a surprise to find an active community.

Sometimes a few artifacts aren't the worst thing in the world. Also a graphics artist on the web really should investigate a high quality image optimizing program like xat.com's Optimizer Pro, Here is one of your images compressed using that program:

http://home.comcast.net/~jscheuer1/side/delwebs_o_2.jpg

32,507 bytes (down from 88,938 bytes)

The program allows you to work with individual areas of an image as well (I didn't bother with that here) to reduce artifacts in one area while having the majority of the image at a high compression ratio and to take advantage of any large area of little detail, to compress that section even more. Also, you can crop and/or resize to reduce further.