Hi Jared,

Currently there is a issue with the compression of certain images on YAP. From what I hear, we're starting to rasterize all images served through YAP as per a requirement from our security team. One of the YAP engineers is looking into the problem and whether this process is causing the problem that you are seeing (the bug # is 2699256 in case you need to reference back). So that I can provide him with more information, I just wanted to make sure that this isn't an old cached image that hasn't purged. When you were seeing this problem with the image alpha, was it the first time you linked to this image name on YAP?

Thanks,
Jon

Thanks for looking into this, Jon.

By "rasterize" do you mean sanitize? PNG and GIF are both inherently raster image formats.

Yes, I'm sure that the images that I've provided above are in exact correspondence. No versioning or caching issues. I gave the image a unique name and never reused it. That should be easy for anyone to verify -- just stick a copy of the original image into your own YAP app and see what happens to it.

Here are a couple more examples:





In the first example, my image is a red square PNG with a uniform alpha of 50%. The image Yahoo served in my app was a red square PNG with a uniform alpha of 75%.

In the second example, my image is an animated GIF. The image Yahoo served in my app was a static PNG disguised as a GIF (i.e. served with the "image/gif" mime type, even though it's a PNG image). As you can see, the animation is broken.

Is there any chance that we can disable Yahoo's image processing for our app until these issues are fixed?

Thanks,
Jared

Thanks for providing that information Jared, and I have heard more about the image issues. Let me go over everything that individuals are having issues with and all of the information I have on the types:

Extreme image compression leading to grainy images
There is a fix to this issue being pushed out to production shortly. This will most likely require users to re-cache their images by renaming them. What is happening here is that if compression or optimization is done on images when they are saved, when they run through the sanitizing process when cached, images will become very grainy. The fix for this is to save images at full quality.

Animated gif's
Support for animated gif's has been removed due to performance reasons. Instead of caching each frame of the gif and then rebuilding it into a single image, the caching process will now capture the first frame of the animated gif and display that. I know how many people may feel about this - several of my apps use this functionality and will have to be adjusted. I'll work to try to push out some initiatives to include some sort of loader functionality.

Alpha removal
This problem is currently being looked into but does not currently have a resolution.

I'll update when I have further information.
- Jon

Jon, thanks for following up. Could you be a little more specific about the performance issues related to animated GIFs?

Do you mean that displaying them requires too much CPU on some machines? If so, well, then so would Flash, and various things that can be done with JavaScript and CSS. Forbidding animated GIFs seems quite arbitrary.

Here is another example of a broken image. It's even weirder.



Yahoo's version seems to be disappearing Back-to-the-Future style.

Also, here's an image that Yahoo seems to flat-out reject. It's a simple 800x800 gray panel with rounded corners, intended to be used as a background image. It's only 3783 bytes.



Here's Yahoo's cached version.

You'll notice Yahoo serves no image, so the image ends up just missing from the app.

No telling why Yahoo rejected it, but I'm guessing dimensions. If there are maximum dimensions for Open App images, what are they?

Developers can waste a lot of time investigating missing images, wondering if they're doing something wrong, if Yahoo's having temporary outages, or what. An error message in the dev-preview window would be really helpful. (The YAP middleman layer produces the Yahoo cache image URLs, so in dev-preview mode, it could also issue HTTP HEAD requests for them just to see which, if any, return error codes.)

For this image, YAP is returning Error 400 - Bad Request

curl -v http://ic.apps.yahoo.com/v1/cache/public/I...AawgEZh6tbJBw--
* About to connect() to ic.apps.yahoo.com port 80 (#0)
* Trying 98.136.57.247... connected
* Connected to ic.apps.yahoo.com (98.136.57.247) port 80 (#0)
> GET /v1/cache/public/If1y2vmyoa7xQ1FMGwqfZW5l8eVN9iOtKHBKgepN04snE0a_KAawgEZh6tbJBw-- HTTP/1.1
> User-Agent: curl/7.19.0 (i386-apple-darwin9.5.0) libcurl/7.19.0 zlib/1.2.3
> Host: ic.apps.yahoo.com
> Accept: */*
>
< HTTP/1.1 400 Bad Request
< Date: Sat, 02 May 2009 03:02:28 GMT
< accept-ranges: bytes
< content-type: text/html; charset=iso-8859-1
< ETag: cpivDQAAuyxlAyRq
< X-Invalidate-Keys: etag
< Content-Length: 1470
< Server: YTS/1.16.2
< Age: 0
< Connection: keep-alive

Yes, I know that Yahoo returns 400 for the image. That doesn't help. There's no indication as to what's wrong with the image.

Also, returning a "text/html" response for an image request isn't very browser-friendly. Browsers ignore the response. Returning a PNG or GIF image that contains an error message would be more helpful to developers.

A bug has been filed for the 404 issue (reference #2737040)

- Jon