I'm using a transparent 1x1 image with a background image, to be able to use sprites and still provide alternative text for some icons.
I want to use a data URI for the image to reduce the number of HTTP requests, but what would be the smallest possible string to produce a transparent image?
I realize I could use data URI:s for the actual images instead of sprites, but it's easier to maintain when everything is kept in the CSS instead of scattered around.
After playing around with different transparent GIFs, some are unstable and cause CSS glitches. For example, if you have an <img> and you use the tiniest transparent GIF possible, it works fine, however, if you then want your transparent GIF to have a background-image, then this is impossible. For some reason, some GIFs such as the following prevent CSS backgrounds (in some browsers).
Shorter (but unstable - 74 bytes)
data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==
I would advise using the slightly longer and more stable version as follows:
⇊ Stable ⇊ (but slightly longer - 78 bytes)
data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7
As another tip, don't omit image/gif as one comment suggests. This will break in several browsers.
data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg'/%3E
The final length depends on what it's gzipped with.
Smallest PNG - 114 bytes:
data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAEAAAABCAQAAAC1HAwCAAAAC0lEQVQYV2NgYAAAAAMAAWgmWQ0AAAAASUVORK5CYII=
I think it must be a compressed transparent 1x1 GIF file (82 bytes):
data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACH5BAEAAAAALAAAAAABAAEAAAICRAEAOw==
Generated with dopiaza.org data:URI generator.
You can try the following SVG data (60 bytes):
data:image/svg+xml,<svg xmlns="http://www.w3.org/2000/svg"/>
Standalone svg file would look like (62 bytes):
<?xml version="1.0"?><svg xmlns="http://www.w3.org/2000/svg"/>
See also:
Optimizing SVGs in data URIs
Url encoder for SVG (GitHub) / SVG CSS URI — Optimized replacer
This guy breaks down the problem via the GIF spec. His solution for the transparent.gif would be 37 bytes:
data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==
He goes even smaller by first removing the transparency, then the color table...
GIF89a specification
Header (6 bytes)
Consists of the bytes “GIF” and the version number, which is usually 89a.
Logical Screen Descriptor (7 bytes)
Without going into too much detail, this section of the file indicates the following:
The file is 1x1 pixels in size.
There is a global color table.
There are 2 colors in the global color table, the second one should be used as the background color.
Global Color Table (6 bytes)
Consists of 3 bytes per color, a byte for red, green, and blue, respectively. In our file, the first color is white an the second color is black.
Graphic Control Extension (8 bytes)
Used to indicate that the second color in the color table should be treated as transparent (can also be used for animation parameters, but isn’t in this file).
Image Descriptor (10 bytes)
A GIF file can actually contain multiple “images” within it, which keeps you from having to specify image data for parts of the image which have the same color as the background color. Each image block has a position and size within the overall image size. In the above file, the position is 0,0 and the size is 1x1.
Image Data (5 bytes)
One LZW-encoded block of image data. It takes 5 bytes to represent the single pixel the image has in it. The compression algorithm wasn’t designed to compress a single byte very well.
GIF Trailer (1 byte)
A single byte with a hex value of 3B (; in ASCII) indicates the end of the GIF.
Based on the required structures for a transparent GIF, it turns out that 43 bytes is pretty close to as small as you can get.
But, I managed to figure out one trick to make it a bit smaller. It’s mentioned in the standard that it is optional to have a global color table. Of course, it’s undefined as to what happens when you make a GIF without a color table at all.
When you have a color table index defined as transparent, however, GIF decoders don’t seem to care that there isn’t actually a color table.
So I changed the logical screen descriptor to indicate there was no global color table and removed the table itself, saving a total of six bytes, bringing the file size down to a mere 37 bytes.
Interestingly enough, Wordpress gave me a lovely list of error messages of GD complaining that this isn’t a valid GIF file, despite the fact that Firefox and the GIMP both open and display (is it “displayed” when it’s transparent?) the file just fine.
To make it even smaller, I looked to the biggest remaining “optional” block in the image, the graphic control extension. If you don’t need transparency, this block is no longer needed, and that’s another 8 bytes you can take away.
Source: The Tiniest GIF Ever.
I'm using following data uri to get an empty image: //:0
This is the smallest I found (26 bytes):
data:image/gif;base64,R0lGODlhAQABAAD/ACwAAAAAAQABAAACADs=
For empty image :
data:null
(it will translate into src=(unknown) )
BMP - 1x1 RGBA (transparent) - based on this - 194 bytes
data:image/bmp;base64,Qk1xAAAAAAAAAHsAAABsAAAAAQAAAAEAAAABACAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAD/AAD/AAD/AAAAAAAA/wAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAQ==
inside java-script it can be compressed to 106 bytes
"data:image/bmp;base64,Qk1x"+"9Hs3Bs5Q4E4B1C3w9995D/2D/2D/8/w999999993Q==".replace(/\d/g,c=>"A".repeat(c))
let s = "data:image/bmp;base64,Qk1x"+"9Hs3Bs5Q4E4B1C3w9995D/2D/2D/8/w999999993Q==".replace(/\d/g,c=>"A".repeat(c))
console.log(s);
You can use
data:null;,
<img src="data:null;," alt="My null image">
<img src="data:null;," alt="My null image" style="width: 100px;height: 10px;background: red;padding: 25px 16px;margin: 5px 15px;z-index: 5000;display: block ruby;">
or
<img src="data:image/png;base64, iVBORw0KGgoAAAANSUhEUgAAAAUA
AAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO
9TXL0Y4OHwAAAABJRU5ErkJggg==" alt="Red dot" />
Related
I have a sprite sheet that i use as div background . The dimensions are :
Width: 105920
Height: 240 .
It's a monochrome png file with size of 620kb , so i assume size is not the problem here .
When i try to use it as a background-image: url("spritesheet.png"); Firefox throws an error saying "Image corrupt or truncated" . Chrome does not show any error message , but the image is not shown .
If i resize the width of the image with gimp to 10,000 , everything is ok . but obviously i cannot use it as intended any more .
Are there any restrictions for maximum allowed image size in CSS ? Am i doing something wrong ?
According to the answer to this question, your image is too big for Safari/iOS to handle. Other browsers probably have similar limitations, as you have found with Firefox. The file-size of 620kb is acceptable, but the dimensions of the image (over 25million pixels) is a little too much to handle.
That said, even if browsers could show your image, I would very strongly advise against using an image of those dimensions. One uses sprites for performance reasons, but an image that size will incur a massive performance penalty... you'd be shooting yourself in the foot.
Not a solution to your problem, merely a comment. The advantages of using sprite-sheets may be lost or much reduced when you orient them horizontally. This causes a problem with cache-misses.
Imagine you had a 10x10 pix sprite. To load the portion of the your image that contains it, you need to load (numPixels = sprite_height * src_width).
In your case, this would be 10 x 105920 pixels = 1,059,200 pixels! - Just to cache 100 pixels worth of image.
The best way to orient a sprite sheet is vertically. You use the same equation to determine the number of pixels that must be loaded, but get a very different result. A result that is now small enough to fit in the small(est), fast(est) cache.
In this case: 10 x 240 pixels = 2400 pixels. - Again, overkill for just 100 pixels, but a superior solution than the previous example gives.
Changing the orientation of the sheet from horizontal to vertical results in a reduction of the size of the memory needed to cache this sprite of 441 times. Not exactly something I would characterize as insignificant.
The effect of making this change will be most apparent when repeatedly drawing the same sprite or sprites that are located near to one another in the sprite-sheet.
Given that the browser works with tru-colour images on the screen, it doesn't seem unreasonable to think that for performance reasons, the browser would convert your monochrome image to one compatible with the remainder of the display - one that has 24 bits/pixel, albeit with (relatively) little variation in value.
If indeed the image was converted to 24bit, well, the memory requirements would be huge
105920 * 240 * 3 = 76262400bytes. Yes!! That's 72.73 megabytes!! Add another 1/3 if its converted to an rgba(32 bit) image.
So, I've got two suggestions.
Orient your images vertically
Use several sprite sheets.
I have an 40px by 20px image with 72 Pixels / Inch.
I would like to create a Retina display version.
What should I do? Double the size? Change the resolution?
And in which format should I save it? PNG? JPG? ...
I am using this image on a web site ...
In your image editor, double the size of your image to 80px by 40px.
In your markup set the width to 40 and height to 20.
<img src="example.png" width="40" height="20" />
You should save as png if you need transparency or the image is line art. Save photographs as jpg.
My answer is convert your image into SVG
Do you have Illustrator? If so save your image as SVG (and have a png as a fallback if you want).
<img src="images/logo.svg" alt="" />
<img src="images/logo.png" alt="" />
As long as you use Modernzr which can work to get svg friendly in most browsers.
You can see it here how it's done:
http://toddmotto.com/mastering-svg-use-for-a-retina-web-fallbacks-with-png-script/
Hope it helps :)
A retina display image (or high-density display image) is double the pixel size of a standard image - its scaling factor is 2.0. This means that yes, for your 40x20 pixel image, you will need to make an 80x40 pixel version (that is then displayed at double pixel density on screen). The format doesn't matter as much, both PNG and JPG will work fine (PNG will not degrade in quality with compression, but the file size will be larger than JPG).
However, the problem with high-density display images is that they take up more bandwidth, and are unnecessary for devices that don't have the high resolution or Retina displays. This means more data transferred over the network, inconveniencing mobile users and those with limited data transfer caps.
One solution is to use something like Retina.js. It's an open-source javascript client script that will automatically load the retina-sized image from your server and swap it in-place for the low-density version, if it exists. It follows Apple's standard for naming high-resolution images - #2x, so you can have HTML code like this:
<img src="/images/my_image.jpg" />
and the script will search your server also for /images/my_image#2x.jpg. If it exists, it will load it and swap it in-place without having to worry about messing with CSS.
Generally as of this writing there are two types of retina displays, hence you should create an image for each type.
For a 2× device, you would need to produce twice the logical pixels' width and height with a resolution of 144 pixels per inch (72 ppi ✕ 2).
For a 3× device, you would need three times the logical pixels with a resolution of 216 pixels per inch (72 ppi ✕ 3).
Examples of 2× devices are the MacBook Pro (released in 2012-2019) and most iPhone since the iPhone 4. Examples of 3×
devices are the iPhone 6 Plus, and the iPhone X. However the iPhone Xr is a 2× device.
Hence for your case you would need images in 80 px ✕ 40 px and 120 px ✕ 60 px for 2× and 3× devices respectively.
Retina displays are not dependent on the specific bitmap image format. You can use the original image format. For websites, you should use JPG for photographs and PNG for line-art graphics saved as bitmaps.
You should not just blindly enlarge images otherwise this would create a blurred results – it would no better than if you don't include any high-resolution versions in the first place. Either obtain the original higher-resolution version of the images (typically from vector graphic source) and downscale them or use a machine-learning based image enhancement solution such as Bigger Picture to "convert" your image into a higher resolution.
Photoshop gives you a couple options for resizing an image. For instance if the image is iPhone size you can increase the image size by 200%. Photoshop gives you a couple options for resampling of the image. Bicubic, bilinear and etc. This will remake the image at a higher resolution and interpolate the missing pixels. Hope this helps.
This is a really interesting article showing a nice option for dealing with high res images:
http://blog.netvlies.nl/design-interactie/retina-revolution/
Basically, it's saying that, if you make the image quite large (width and height) but then save it at quite low quality, it still comes out very sharp on retina displays. It means that you can use the one same image on all devices, and that the file size is very low, too, which is an extra bonus. You can set the width and height of the image in your CSS and/or HTML to set it to the visual dimensions you desire.
This article blew me away, and is my go-to approach for dealing with both retina-friendly and bandwidth-friendly images. Win, win.
You can use CSS opacity option.
This will give you an transparent look of your image based upon the value you set to opacity.
Try learning opacity: http://www.w3schools.com/css/css_image_transparency.asp
I have an image that I use many times. In several cases I want to shrink its size, but obviously it loses sharpness when I do this in HTML.
Is there a way to fix this? The image is located elsewhere and I can’t save it locally.
Thanks
As dheerosaur states, SVG graphics can be used when you need to have the same image in multiple sizes but don't want to compromise quality.
Another thing to do is use an online service, such as Resize.co. You pass them the URL for your image file, the attributes and they take care of everything else.
You cannot control the way the browser renders images when they are resized. Images will look better when being passed through Photoshop's filters (or those in another tool) upon resize.
There is three way that I know to reduce an image file size in bytes :
Convert the file into a format using lossy compression algorithm such as JPG. Obviously the image will lose sharpness
Convert the file into a format using lossless compression algorithm, like PNG. Only works if the image contains lots of region with flat colors
Resize/resample the image using Photoshop or GIMP. If the new image dimension (width x height) is exactly the same as the displayed image's dimension in HTML, then web users will still see a sharp image
Firefox and Internet Explorer actually do have CSS properties that adjust the way images are rendered when resized via HTML attributes or CSS properties:
Firefox: image-rendering
Internet Explorer: -ms-interpolation-mode
These won’t work in other browsers, and may not work great in all (or any) versions of IE and Firefox.
But it might be worth experimenting with them as a fallback in case resizer.co causes any issues.
I'm making a sprite and its reaching about 4000px in height. Is there a general size for maximum sprite height that is used within the graphics design community?
Browsers will have to decompress (and keep in memory) the whole image even if you only use very few sprites in it, and even if most of the image is blank/white.
For a desktop client you've only missed an occasion to be a good citizen by using too much memory (and browser are already sucking a lot of memory).
For some mobile client (eg. IPhone for files over 25k after degzipping), it can be more problematic, the image won't be cached at all, thus it may be better to have 2 files <25k and two HTTP request than one >25k file and a single request never cached.
Last problem, PNG compression is line-based, there is less overhead in having wide images than tall ones (though too wide could be theoretically bad in some case, since you can have only one prediction filter type per line).
Oh and also, with too much spriting, you may end with way too much different colors in the same image, and miss the opportunity for decent paletted image. Testing all combinations of this is tedious, but if you can, grouping your sprites by main colors of gradients is a good heuristic (since gradients/blur needs many different colors).
I don't think the focus should be on how big the sprite is physically (width x height) but rather how big the sprite file size is and ask yourself the question if it would be worth splitting the sprite into multiple sprites.
Quite often we split our sprites based on color so have sprites that are predominantly blue or red or yellow. That way we get smoother gradients and overall image quality while keeping image file sizes down
Is the only benefit of using css image sprites that there is less http requests?
Or is there other benefits?
Also is there an easy way of detiming which area of a sprite to show?
Like you said, one of the main advantage is to reduce the number of requests to the server, improving the response time (especially if you're loading a large amount of small images). But this is not the only reasons people use sprites.
If you don't use sprites for a "mouse over" display, the user will see the image disappear for a second... and it looks really bad. This is because if you change the image instead of just moving the sprite around it will load a new image and the loading time can be visible to the end user.
.bad{
background:url(abc.jpg);
}
.bad:hover{
background:url(abcHover.jpg);
}
.good{
background:url(abc.jpg) 0px 0px;
}
.good:hover{
background-position:15px 0px;
}
Another advantage of sprites is that you can keep all your images in one location and in some cases it makes more sense (for menus and so on).
To determine which area of a sprite to show, just use photoshop or any other image editing software.
The primary benefit is your pages load faster, mainly because of reduced HTTP requests.
You could generate your sprite using a tool.
Disclaimer - I wrote this tool.
It is much easier to get image placement (especially next to text) the same cross-browser. You can adjust images up/down/left/right with out using vertical-align and padding.
I find it easier to keep track of all the images if they are in a single file. Especially since I usually have a transparent png images and and then use gif images for ie6. I save my png sprite map as a gif and add one line with background-image in my ie6 css and my images are switched.
I use photoshop or gimp to get approximate locations in the sprite map and then use firefox to fine-tune the placement.
Yes, there is another benefit. Every image file has his own headers, describing image type, colors etc. So when you combine images to a single sprite, you win some kb.
But as you said before, mostly you win by reducing HTTP requests count.
In terms of determining the area to show, I will typically place my elements on pixels that are multiples of 100. So if there's a sprite with a bunch of 64x64 pixel icons, I'll typically have them at (0, 100), (0, 200), (0, 300), etc.
This way, I don't have to type in an exact measurement (or any other developer for that matter) and save keystrokes when setting all my background-position properties.