When loading Marketplace, a lot of time is spent downloading and displaying app icons. It could be useful to serve dithered icons to some devices we know don't have a lot of memory/are slow to improve performance for them. pngquant or pngnq can generate those automatically. See bug 983426 for the lossless version of this idea. I don't think we should make this the default though, it needs to be a separate icon.

Homepage screenshot with regular icons (mobile view)

Homepage screenshot with regular icons (desktop view)

Homepage screenshot with 256 colors icons (mobile view)

Homepage screenshot with 256 colors icons (desktop view)

I have uploaded 4 screenshots of the current homepage in restofworld to give us an idea of the quality we'd get (Please ignore the missing images & wrong font in the 256 colors screenshots to concentrate on the icons) mobile view, before and after: https://bugzilla.mozilla.org/attachment.cgi?id=8400612 https://bugzilla.mozilla.org/attachment.cgi?id=8400614 desktop view, before and after: https://bugzilla.mozilla.org/attachment.cgi?id=8400613 https://bugzilla.mozilla.org/attachment.cgi?id=8400615 The tool I used was pngnq, with -s1. The original and resulting images have also been passed through pngcrush also (see bug 983426 for command line used). Total size for 36 icons (keep in mind that we don't load them all, especially on mobile, this is just to give an idea of the size savings percentages we'd get) : 584K before, 440K after.

It makes sense to not require app devs to create an additional icon for 256 colors when we can generate it from what they're already submitting. However, in some cases the 256 color version hues are noticeably different from the original -- enough that an app dev *might* care. How should we approach this?

I actually don't mind the idea of squishing the images, both physical dimensions and colors/quality. I think we should store two (or more) versions of them on the servers and load whichever we think is appropriate (or do the google thing and load one and then the other if it's still showing on the page). Netflix and Youtube have like 20 versions of every video or whatever, I see this as similar to that. ?dbialer for product input

I too notice the difference in some hues (like on Mozzle). Because of that noticeable difference, I don't like the idea of modifying appearance of content that the developer submitted. I assume we are using 128x128 icons? Can't we use the 60x60 icon and optimize these without losing color instead? Just an idea.

No, we are using 64x64 icons already.

To clarify, we're already using icons of good dimension, it's a question of color depth. Ideally, we'd generate 256-color versions of the icons at the same size -- this would be most efficient -- but *because* the hues could shift, we need to either alert the developer that this may happen or just have them upload a 256-color version of the icon themselves that they'd find acceptable. Two issues: 1) they may not do any better at the color conversion than us anyway, 2) if the screens on these devices aren't great, the hue shift we're seeing on our tests may be far less of an issue on the devices targeted for 256-color icons anyway.

#tl;dr There are a lot of potential issues we're creating by going down this route, and a lot of them lead to an erosion of developer trust when unintentionally we screw up their listing in the Marketplace. Blanket crushing of images is not something we should do to developers assets. If we are concerned about the size of these things, we need to set an upper bound on how large the files can be and let the developers choose what they're willing to do to their content to make it fit. #Long soap-boxy There are a couple things we need to keep in mind when we talk about cutting the gamut on images to 8-bit (256 colors), the main one being the color range in RGB is not an equal circular shape (as portrayed by popular graphics programs and OS color pickers, it's more like a blobby triangle), so any cuts we make will not be equivalent. In short, there are a lot more reds and yellows and oranges available than there are blues and greens and violets, and simply compressing the gamut, even with a nifty semi-inteligent compression algorithm like nearest neighbor, still leaves you at a larger deficit for cool colors than warm colors. This is compounded with the fact that most modern graphics programs are creating 24 or 32bit RGB images (or converting the CMYK values of sloppy users to these color spaces.) This is why some images you're seeing in your tests are tipping green, for example, when tasked with cutting millions of colors out of the gamut, it's nearly impossible to pick the right ones without "seeing" the image you're starting with and a more green color is the closest thing to the original that's left. This operation is very difficult for a trained professional to do while actually looking at the images, doing it algorithmically without messing up a large number of images is not a simple task. The same kind of issues will arise if we want to discuss changing compression formats (from loss-less like PNG to lossy like JPG, for example), there is simply too much room for error in not treating each image as a unique case when it comes to optimizations as drastic as these. If we are seriously concerned by the size of the icons as we move into these new markets with slower network connections, we should start imposing a max file size on the icon assets. This would leave it up to the developer what they want to do with their icon to make it fit under that limit, instead of us blindly crushing images to achieve the same goal.

(In reply to David Durst [:ddurst] from comment #6) > It makes sense to not require app devs to create an additional icon for 256 > colors when we can generate it from what they're already submitting. > However, in some cases the 256 color version hues are noticeably different > from the original -- enough that an app dev *might* care. How should we > approach this? Can this be looped into the Conversation for larger icons as well? We need to have a full understanding of what's needed today and anticipate what we may need over the next 12-24 months. At this point, we cannot go to our developers prior to the Tarako launch and REQUIRE any changes to their icons. We must clearly define what's needed to support both the upcoming lo-res and hi-res devices prior to implementing any RECOMMENDED changes in the submission process for icons. For this reason alone I support auto-magically crushing icons if there is no other option to reduce Marketplace friction. To provide some context; Mozilla has made a habit of going to our app developer community with a constant stream of required changes since launch. With the latest project around IARC we've noticed a serious amount of developer fatigue and a lagging response rate. Not only would we not get this turned around in time for launch but we would also burn a significant amount of relationship capital in the process.

Didn't do this for Tarako. Don't want to ask developers for additional things. Don't want to make potential aesthetic decisions without asking the developers. Therefore, wontfix. If we find ourselves working on the icons in general and needing to talk to developers, we should reopen this opportunity.