I have got an img element in my HTML document, and its width is about 100px.
The outputs when I set the source to images of different widths that I change every time:
17000 px:
2000 px:
500 px:
100 px:
As you can see, the quality of the image reduces even though the img element's width is at a constant 100px. Is there any reason behind this? If so, what are the practises to be followed to ensure the quality isn't bad?
Are you taking these as screenshots? I'm thinking that the image looks less clear because you have a low resolution when you display them. As in, the area you are showing the image in on your monitor is of a lower resolution than the image itself. So, by making the area displayed larger your monitor can more accurately display the image.
Think of it like this: Displaying a 4K wallpaper on a 720p display won't look as good because the monitor has to scale it down.
Slightly related reading to browser image resizing: https://petapixel.com/2009/11/12/why-you-should-never-let-browsers-resize-your-photos/
An image is broken down in picture elements (pixels) which means that when I check the attributes of an e.g. JPEG image stored on disk I can see e.g. 532 × 1051 pixels which means the width is 532 the height is 1051.
It also says in the attributes of the file that the color model is RGB which would mean 1 byte for each channel = 3 bytes to describe the color.
So I would assume that the actual size of the image is:
532x1051x3= 1.67MB
But what I see is that the actual file size reported is 45KB.
So does this mean that the 1.67MB is the size of the image in memory?
Also I see as part of the meta data: Image DPI: 96 pixels/inch.
What exactly is this information used for?
But what I see is that the actual file size reported is 45KB
That's because JPEG images are compressed in multiple ways to save up space, sometimes up to a factor of ten so this is not unusual. You can just search for "jpeg compression" and read how it is done in detail if you're interested.
Also I see as part of the meta data: Image DPI: 96 pixels/inch. What
exactly is this information used for?
Generally, as long as you are only interested in the image stored digitally you do not use it at all, because the image is not stored in inches. You could change the DPI and the image itself would not change, just the image header.
DPI only makes sense once you display/print the image. Then you could take it as a general recommendation on which resolution you should print this image. If you want to print a huge landscape with only 50 pixels per inch, it will not look good. If you however want to print a small logo with low DPI it might still look fine. So it really depends highly on the context of the image.
We're currently using apache fop to render a bunch of images in PDF format, but we've notice that the quality of just about any image is complete garbage and anything with text in it is incredibly unreadable.
I have looked through the documentation about source and target resolutions here.
And I thought that maybe I could force fit some good image quality in by assuming a default (source) resolution of 72 pixels per inch for all bitmaps/pngs/etc and desiring a target resolution of 300 pixels per inch. I figured this would theoretically cause FOP to cram way more image into a smaller space netting me an increase in quality with less of a need to smash my images into such a small space. Also I did the math and before where things were 72 72 it seemed like we were getting 5 * 72 = 375 pixel Nokia phone screen resolutions so I was like no wonder they are terrible quality.
Well, it seems like even with a target PPI of 300 instead of netting me a generous space of about 1500 pixels, I'm still getting the same crappy Nokia phone quality. I tried many combinations of source and target PPI 300/300 72/300 and 300/72 respectively, but nothing seems to cause any form or resampling or better image output. In the end I'm always left with this.
This is an actual screenshot of my PDF at almost full screen size. It may be worth noting that we are using the org.apache.commons.codec.binary.Base64 encoder to take images from memory and turn them into strings to embed into PDF. I don't know what kind of compression if any is being done through this encoder, but I hope to dump a string to the filesystem soon to take a look and make sure that isn't the issue.
In the meantime, does anyone know what PPI settings I might have messed up or what better options I may have to render clear cleaner images out to PDF with FOP?
After reading posts on this site and others, I am uncertain what pixel width I should make for a background cover image. For retina devices it is recommended to create a background image x2 the size if for a non-retina device.
I want to create a background image that will cover the entire screen but this would make a retina device image 2560 x 1760 and non-retina 1920 x 1200 if accommodating large monitors.
Is this too big?
I can't keep the jpeg image file size down to 276KB and that is with the most compression I can apply without destroying the image quality
Well your question is very interesting. To address your comment about what pixel width you should design your background image for. The size of a screen for a laptop, or desktop can vary. So you'll never exactly be able to make a single "universal" image for all backgrounds. Generally diagonal display in inches decides the amount of pixels. My screen is quite large, roughly the biggest size commercially purchased by public. Which is of course 1600 x 900 pixel, 17.3" diagonal display. I wouldn't recommend designing images for any display larger because those displays are custom and more for people who do things like graphic design themselves. Visit http://nodejs.org/logos/ If you scroll down to the computer display, you can see a list of pixel ratios that nodejs designs its logos for. These are very mainstream and popular display sizes. I would recommend you do the same and use those. Hope this answer helped.
Edit: nodejs builds for quality up to 2560 x 1440. If the size of the files doesn't matter. You should easily be able to build for sizes this large. Hope this helped.
I have a page with many large fluid images. http://altarjewelry.com/gallery
I want to get a smooth 60fps webapp feel while scrolling. The Chrome DevTools tell me my paint times are the biggest problem (which you can check for yourself while scrolling). I'm assuming this is due to my many large fluid images.
I've read every article on HTML5Rocks about performance. I found many good tips on JS performance but no help optimizing large image paint times other then using small fixed size images, which is not an option for me as I'm building a responsive site.
I'm already serving up responsive images depending on the client.
Thank you for your help.
Not really sure about how your gallery looks because it never loaded from the URL in your post, and I don't know if that's a javascript issue or what--but I'll take a stab at helping you come up with a solution. Image optimization is image optimization, regardless of whether or not you're building a responsive site.
Approach and Design Considerations
Do you really need one large, high resolution image for each item, at the same DPI/PPI and compression, that should be responsive?
Or, should you serve appropriately sized images at differing DPI/PPI and compression, to different displays, all of which are still used in a responsive application?
Popular Convention
You're showing a gallery, and typically, you want smaller representations of the actual image--thumbnails or placeholders, generally of lower resolution, which link to the actual image at a higher resolution. This is an accepted design approach, and if you're going to vary from it, be sure it's with good reason.
The Lowest Common Denominator
If you're building a responsive site, some users will obviously be on mobile devices which may have resolutions as small as 320 pixels wide. Consider things like that, and this: even if someone shows up on a desktop, are you going to have huge, full width images loading? They will take forever to load, and visitors will never see your gallery. How is your gallery to look on a wide screen desktop? If your intention is to have one image full width across the entire page, and load the same image regardless of the device accessing your site, you may be using responsive design, but you'll find that's far away from best or even good practice.
The Flip-Side, Large/Wide Screens
Why not have four gallery images going across a desktop? Or more? And if that's the case, they're likely to have a maximum size in any case. I honestly don't know because I've tried to load your site a few times and get nothing. But consider that if there's a maximum size practically for your gallery images in an initial display, say 6 images at 200 pixels each across a 1200 pixel max layout width (Or, are you using a % based framework and using 100% of the display width? Even responsive sites often limit the max width of the content area, and these things all would help determining a more appropriate answer) solutions begin to emerge.
Since no image needs to be larger than 200 pixels in that case, and on a phone where your columns might be displaying only one image that you want full width, you can work with a maximum initial width of 480px wide images.
Higher Quality, Smaller Files
We'll assume you want them high quality. That's fine. You still need to reduce files size, and you do that with compression. Now, you may feel compressing a photo to 50% or even more makes it blurry, and it certainly will at low ppi (pixels per inch) settings.
The Secret To Better Compression
What you need to do is change default image editor settings from traditional defaults like 72 or 90 ppi, and crank them up to 300, 400, 500, or more--and THEN apply compression. If that image is 480px wide, and you've only got 72ppi, compression will quickly erode quality. However, having several hundred extra pixels per inch will allow more information to be stored. Then, you can apply much higher compression rates, and shrink file sizes down quite a bit more.
The Oversized Image Approach
Another trick is to do the same thing, and slightly oversize the image. If 480px is the max size for your thumbnails/small pics, make them actually 540-600 px wide, with 400-500ppi and compress them at really high settings. The browser will resize to the max width of 480 px...but then you have a performance hit there. Everything is a trade off. You can blur backgrounds in images as well, allowing the foreground/main focus of the photo to be of higher quality while the background requires less information, yielding smaller file sizes.
Not Suitable For Batch Processing
This should be done individually for each image, batch editing does not generally get the most out of this technique, because the color information is so different in each photo. One photo might be best quality and smallest size for your purposes at 300ppi and 50% quality, another at 500ppi and 35% quality. You'll want to do this not just for your gallery thumbnails, but multiple images. No point in serving up a 1400px wide full size desktop to someone who's browsing your site with 480px wide/resolution display after all. Use media queries to serve up the appropriate ballpark sized image, and have a small, medium and large variant. Done right, you don't even need to be serving larger images to those browsing with phones...the gallery images they are viewing are good enough.
The compression setting is not so heavily determinate of the final image quality as the number of pixels you have to compress goes up. More pixels to work with, the better quality at higher compression settings.
Design Considerations and Smart Image Loading
Break It Up Into Smaller Content Chunks
Also, consider the process/design of your gallery. Do you have 20 items? 100? 400? Are you trying to show them all on one page? Break it up into small numbers...12-20 per page. Smaller and fewer images will load faster, and can remain responsive, with links for those who want a larger or higher quality image. No need to show a huge, high quality image to someone browsing with their phone.
Pre-fetching and Loading
Server side scripting, and even some javascript solutions can help with this. You might do things like limiting each gallery page to four rows of four images, and then after page load, have a javascript that pre-fetches the first four images that will display on page 2. If your visitor goes to page two after scrolling through page one, the first four images are loaded in cache, and display quickly while the others load normally, giving the experience of a faster page load.
If the visitor goes to another page in the site, you didn't waste bandwidth on 12 images and only cost you the bandwidth of four. Smart design might be to use those first four images on page two of the gallery elsewhere on the site...so that first gallery page visit actually sped up page load elsewhere and does not in fact give up bandwidth for loading 4 unnecessary images. Think the process through, and solutions will suggest themselves.
Resources
Anyway, here are relevant articles/posts/links you may find helpful in understanding all of this:
Are Compressive Images A Good Solution For High Resolution Displays?
http://www.vanseodesign.com/web-design/compressive-image-tests/
Reducing image sizes (ResponsiveDesign.is)
https://responsivedesign.is/articles/reducing-image-sizes
Search benfrain dot com for this post:
How to serve high-resolution website images for retina displays
And a tool you might find useful...
adaptive-images dot com