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.
Related
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
Let me start off by stating that I realize the arguments against doing CSS Sprites for large images. I even asked a question about why that could be considered a bad idea (and added an answer of my own). Now that we've had that talk...
I'm going to be making a large CSS Sprite-map. For the process of making this sprite-map, it behooves me to know what (if any) limit exists for the height and/or width of a sprite image in order for browsers to properly process it.
The ultimate reason behind this question is a debate over whether to lay out the sprite images in a grid or in a single row/column. For example: is it necessary or beneficial to do 4000 x 3000 instead of 400 x 30000?
Edit: The sticking point here isn't about what size images can be, but rather what size browsers can process for sprites. Given the lack of detail thus far, I'm moving forward with generating the single-large-column sprite. I'll post details of my experiences as an answer once that is complete.
Sometimes it's more of a matter of download time. Since browsers can use multiple connections to download files, a huge image can take longer to download than a few smaller ones.
If your image is so big that it's slowing down page load maybe it's time to consider several smaller sprite images.
Direct-X 9 has a size limit if 4096 pixels, so any Internet Explorer filters applied to these elements will crop them at 4096 pixels.
See: IE display transparency bug on height > 4096px?
In practice, this seems to work with no problems in Firefox 5+, Chrome, and IE7+ for a sprite image of 400x16560.
The potential issues of IE's directx rendering engine failing on images over 4096px do not create problems in IE7 or beyond; we have no method or need to test IE6 for our current project.
The one place that we experienced problems with really large spritemaps is on mobile platforms. Android devices handle them reasonably well, but iOS devices break down pretty badly, and in a strange way: They shrink the image down to fit within the dimensions they accept. So our CSS works perfectly for a small spritemap, but with no changes except increasing the physical dimensions of the spritemap image, the sprited images begin to show four times as much of the spritemap in the same html entity, with exactly the same CSS.
There is a limit in version 1.0 that is upgraded in v1.1 But still there is a limit for dimensions:
In accord with version 1.1, the scope of the 31-bit limit on chunk
lengths and image dimensions has been extended to apply to all
four-byte unsigned integers. The value -231 is not allowed in signed
integers.
Source
A funny limit is IE6.0 fails to display PNG images of 4097 or 4098 bytes in size!
But these limits are very huge in compare to what we're using in web pages.
i have a 100x100px image and i need to show that in 3 different dimensions in html,
50x50 60x60 70x70
so my dubt is if better to save img in 3 dimensions then do not use css or html width and height or if to use same img with css rules about dimensions... which solution is faster rendered ?
It depends.
If you are using the same image, Only 1 time image cache is required by the browser. So If you are displaying more than 1 type of image in the same page then dont go for multiple images. Otherwise go for multiple images.
But honestly, 100x100 if you have, It should not be a problem to load. Only in slow connections it will be problem (<128kbps). Otherwise i dont see a considerable difference.
I wouldn't worry too much about rendering speed, the main difference you'll see is in terms of image quality. Some browsers (Chrome) perform very high quality image interpolation, while others (IE, Firefox) opt for a faster algorithm that does not give as nice of a result. So you'll get the best, most consistent image quality by having the three separate image files, one for each size.
That said, since you're only scaling from 100x100 to a minimum size of 50x50 you probably don't need to worry too much about interpolation artifacts either. So I'd recommend just doing whatever is most convenient for you to implement.
And in terms of pure rendering speed, having the separate images will be faster, because no interpolation step is required in that case. In terms of initial page-load speed, however, having a single image will be faster, because there is only 1 file to download instead of 3 (or 4). As for using CSS or HTML tag attributes to set the width and height, there will be practically no difference in speed. The expensive operation is the interpolation of the image itself, and it doesn't make much difference if you specify the interpolation through CSS or through tag attributes.
I am trying to implement a fixed background for a website like one over here. Searching around for it told me that I can use background: fixed or background-attachment properties for this.
My problem is the image which will be used as background. I am thinking about following issues:
What should be image size?
how will it repeat when browser window size is very large? for big 27" monitors out there?
Can somebody guide me on these points?
Regards
Vikram
That is not a single background image. Its mostly a bgcolor, except for the side clouds. Using a single large image as a background will dramatically slow down your load time.
There's no specific guideline. You need to make the image as large as necessary to satisfy the requirements of the design. If you want someone with a maximized browser window on a 30-inch display to see a single unbroken non-repeating background image, then yes, you'll need quite a large image. It won't perform well.
The Twitter example is a wide but short image, set to repeat along its x-axis. It's wide at 2247 pixels, but perhaps unnecessarily so: it actually appears to be a fixed pattern that repeats horizontally four times within that 2247 pixel image. Nonetheless, you get the idea: make an image that blends gracefully into itself at its edges for seamless tiling, and/or blends into a fixed background color. Position and repeat it as needed, set the background-color of the page, and you're done.
I'm trying to show image files (jpg, png, gif) that can be larger than the available display area. I've embedded an Image inside a cCanvas (to get scrolling), but the large images are not completely displayed.
Very large images (e.g. 2480 x 3507) have the top or the top and bottom of the image clipped withing the scrolling Image.
What is the largest graphic one can display using the mx.controls.Image ?
Thanks
The 2880 pixels limit is for BitmapDatas, for DisplayObjects there's a limit of 8191 pixels.
You can bypass these limits by using the BitmapDataUnlimited-class available here: http://code.google.com/p/bitmapdataunlimited/
However, if performance is important I'd recommend letting such large images consist of multiple smaller ones instead. Even if you don't reuse these smaller ones or take care of removing them from the displayList or setting their visible-property to false there will still be a performance gain as flash automatically detects that they're outside of the stage and wont have to be rendered.
Edit:
I forgot saying that the 2880px-limit only applies when manually creating BitmapDatas, images bigger than that can still be loaded in, and their BitmapDatas (which are bigger than 2880px) can be accessed and manipulated.
You could easily have a Bitmap with a bitmapData as large as the viewport, then you can set its bitmapData by doing something like:
viewportBitmapData.copyPixels(sourceBitmapData, new Rectangle(x,y,viewportWidth, viewPortHeight), new Point(0,0))
When scrolling, you could simply do the above on each frame
Or if performance is important, you can when scrolling (if scrollingDistance is less than viewportSize) use viewportBitmapData.scroll(x,y) to shift the whole bitmapData, and then copy only the new pixels.
I've read that the limit is 2880 pixels per dimension in Flash 9. In Flash 10 the limit is higher. Check to see which version you're compiling for.
You could potentially chop the image into smaller pieces and assemble them in Flex.
If makes a difference which FlashPlayer you are targetting:
versions VS maximum bitmapsize
flashplayer -9 : 2880x2880 px
flashplayer 10 : 4096x4096 px
flashplayer 11 : unlimited