Automation? Managing Image Assets for iOS and Android - 1.5x, 2x, 3x

Discussion in 'Web Design and Development' started by CrashX, Mar 14, 2017.

  1. CrashX, Mar 14, 2017
    Last edited: Mar 14, 2017

    CrashX macrumors 6502

    Apr 13, 2012
    I'm a bit confused as to how to best automate the management of image assets for the web, for optimal presentation on both iOS and Android devices?

    From what I've gathered, Android devices require a folder structure containing the various resolutions, whereas iOS devices use the @2 and @3 naming conventions.

    Beyond that, I've seen posts showing images that were prepared only for the original retina displays (2x) - showing that compressions up to 30% (greatly reducing file size) looked just as sharp as 75%. I have a retina MacBook Pro and I couldn't see any difference, so the logic seemed very sound. And the high compression worked with both photos and rasterized vectors (icons, etc.)

    I know someone has released an action for Photoshop CC exporting images for iOS - but I don't think it uses the higher compression rate, which would greatly reduce file size and load times. And it doesn't output the folder structure for Android.

    Also, as I'm just dipping into JavaScript and JQuery - if using JavaScript to create an image gallery - does the iOS or Android device itself simply "search" for the appropriate @2, @3, or image within a folder structure to present the highest quality image.

    I'd also like to use Adobe Edge to create animations - so the same question applies there, though I believe it outputs to JavaScript and CSS.

    Thanks VERY MUCH for ANY advice.

    I'd very much like to just focus on design and not be so worried about dealing with all of the myriad of asset sizes that need to be created.
  2. olup macrumors 6502

    Oct 11, 2011
    Nowadays icons are done in svg either as actual svgs in your html or background images, so that's one less thing to worry about.
    As far as images are concerned it's a bit complicated as far as syntax is concerned and that syntax is quite messy.
    There's a new property called srcset that can figure out, which image resolution should be downloaded, depending on the width of the viewport/size of the device.
    More on that here:

    As far as image compression is concerned, imageoptim can greatly reduce your file sizes:
  3. CrashX, Mar 14, 2017
    Last edited: Mar 14, 2017

    CrashX thread starter macrumors 6502

    Apr 13, 2012
    Thanks, olup. But that still doesn't seem to address HOW to effectively manage automating the production and addition of image assets?

    Maybe I'm just thoroughly confused - is it just "app development" that uses the @2, @3 or Android-specific folder structures? But then how does my rMBP know to look for and display higher resolution images on websites?

    As for the cropping issues mentioned in the article, I think this might be a (possibly?) better, seemingly less complicated solution than Mozilla's?

    And here's the article showing that much higher compression can be used when dealing with retina and higher displays, resulting in (visibly) the same image quality:

    I know Adobe Photoshop CC allows me to use their "Generate" to specify different sizes and names - but it doesn't allow me to set varying compressions related to each size. It also fails to allow me to deal with the Android folder structure naming either.

    And sorry for the tangent with the icons - I just found it peculiar that the higher compression ration also seemed to have no visible degradation even on rasterized icons.

    Mainly, just dealing with photos - clients are always wishing to add new photos - I'd like to be able to quickly automate the production of all the assets for the new photo or set of photos. As it stands, it seems like I'd be spending a tremendous amount of time dealing with (what I call) this madness ;)

    We have 1x, 1.5x (Android), 2x, 3x - and for photographs, it would be easy enough to just use Generate starting with the 3x and "retina-down", only if the "Retina Revolution" article is proven true, then I'd be creative assets of un-necessarily massive size with no automated control of the compression ratio.

    But everyone is currently managing this with massive amounts of extra code and photos, etc - as outlined on the Mozilla link? That really seems like madness?

    It just doesn't seem the least bit future-proof, which is my greatest concern even beyond the workload required to deal with these higher resolution displays.

    Thanks very much for any additional advice!

Share This Page