19-05-2021, 11:35 AM
Hi Mike,
I see from the email notification that your original reply was somewhat different to the edited version that we all see now. That's fair enough - we're all allowed to change our posts within the 20 minute edit window. But, just in case, I did just want to clarify that I did not misunderstand what you said originally in post #20, and that you were perfectly clear. It's just that - as I said - you were making a much wider point than mine. And please note that I agreed with your wider point.
Of course I understand that if you crop unwanted parts of the picture, what remains will make better use of the prevailing file size and/or pixel count limits. I have been putting images online since the 1990s when we all had to struggle with dial-up connections, and have some experience in optimising images to get the best results for the fewest bytes. I am frequently complimented about the quality of the images on my website, and for a while I had some basic advice about image creation on my website because I was asked so many questions about it:
https://web.archive.org/web/200410100103.../about.htm
(Ironically given this topic, they've cached an older logo that is being stretched to the size of the new one!)
There's no point going over it all again - it's all here in the thread - but just to clarify a couple of points:
1. "Resize" means change pixel size.
2. This is not the same as file size - which depends on pixel count, and how much compression the file format uses. For a BMP file with no compression, then yes, there is a simple relationship between pixel count and file size. But for a JPG, it is a product of the pixel count and compression ratio. You can change the compression ratio in most decent graphics programs.
(For simplicity I've ignored colour depth - bits per pixel)
These 4 images all have the same pixel size (2000 by 1500), but the file sizes are 987KB, 389KB, 223KB and 96KB.
It's worth saying that the same image saved as an uncompressed BMP is 8.58MB! As has been said, JPEG is impressive!
This version of the image has fewer pixels (1000 by 750), but the file size is 288KB. That's bigger than image 3 and 4 above! It uses the same JPEG compression ratio as the first image above. So for anyone who is still in doubt, this clearly demonstrates that pixel size and file size are not the same thing.
Jeffrey did make this point in his penultimate paragraph of post #15. Despite picking him up on the "crop before resize" point, I've never doubted his knowledge in this area - we all know the work he's done with video. Video compression, of course, is the classic example of needing to reduce file sizes (or bit rates) while keeping the pixel count the same.
Purely out of interest, I tried reducing the colour depth of the original 2000 by 1500 image to 256 colours, then saved as a GIF. This uses much less sophisticated compression technology, so despite the saving from only using 8 bits per pixel, the final file was 2.25MB - too much to upload here. So I went back to the original and resized it to 1000 by 750, and reduced the colour depth and saved another .GIF. This was just shy of 600KB. The artefacts from the colour reduction are there, but it's not too bad overall. But definitely best to use JPEG for photos, both in terms of image quality and file size. But as we know, JPEG is a no-no for line diagrams.
A final work about resizing. When you change the number of pixels, it's not a straightforward process - just have a look at the Wikipedia article to get an idea of what's involved. And back in the 1990s, some graphics programs didn't do a brilliant job. Indeed, nor did web browsers until some time after this, which is why it was important to make sure that the size properties in the IMG tags matched the actual pixel size of the image (much less of an issue today). So given that implementations of image resizing algorithms were once necessarily less than perfect, that might have fed into workflow decisions like "crop before resize" back in the day, and that's where I thought Jeffrey was coming from in post #15. But that's not been an issue in the last 2 decades, which is why I said it doesn't matter. But obviously, "crop before JPEG encode" is what I'd hope anyone would do by default. Get all the manipulation done on the uncompressed image held in RAM, then only save as a JPEG file right at the end.
Although image resizing is a mature science, it's interesting to note the difference in quality in HD to SD downscalers - that's one of the practical exercises we get people to do at work. Of course, they're having to work in real time, unlike Paint Shop Pro
I see from the email notification that your original reply was somewhat different to the edited version that we all see now. That's fair enough - we're all allowed to change our posts within the 20 minute edit window. But, just in case, I did just want to clarify that I did not misunderstand what you said originally in post #20, and that you were perfectly clear. It's just that - as I said - you were making a much wider point than mine. And please note that I agreed with your wider point.
Of course I understand that if you crop unwanted parts of the picture, what remains will make better use of the prevailing file size and/or pixel count limits. I have been putting images online since the 1990s when we all had to struggle with dial-up connections, and have some experience in optimising images to get the best results for the fewest bytes. I am frequently complimented about the quality of the images on my website, and for a while I had some basic advice about image creation on my website because I was asked so many questions about it:
https://web.archive.org/web/200410100103.../about.htm
(Ironically given this topic, they've cached an older logo that is being stretched to the size of the new one!)
There's no point going over it all again - it's all here in the thread - but just to clarify a couple of points:
1. "Resize" means change pixel size.
2. This is not the same as file size - which depends on pixel count, and how much compression the file format uses. For a BMP file with no compression, then yes, there is a simple relationship between pixel count and file size. But for a JPG, it is a product of the pixel count and compression ratio. You can change the compression ratio in most decent graphics programs.
(For simplicity I've ignored colour depth - bits per pixel)
These 4 images all have the same pixel size (2000 by 1500), but the file sizes are 987KB, 389KB, 223KB and 96KB.
It's worth saying that the same image saved as an uncompressed BMP is 8.58MB! As has been said, JPEG is impressive!
This version of the image has fewer pixels (1000 by 750), but the file size is 288KB. That's bigger than image 3 and 4 above! It uses the same JPEG compression ratio as the first image above. So for anyone who is still in doubt, this clearly demonstrates that pixel size and file size are not the same thing.
Jeffrey did make this point in his penultimate paragraph of post #15. Despite picking him up on the "crop before resize" point, I've never doubted his knowledge in this area - we all know the work he's done with video. Video compression, of course, is the classic example of needing to reduce file sizes (or bit rates) while keeping the pixel count the same.
Purely out of interest, I tried reducing the colour depth of the original 2000 by 1500 image to 256 colours, then saved as a GIF. This uses much less sophisticated compression technology, so despite the saving from only using 8 bits per pixel, the final file was 2.25MB - too much to upload here. So I went back to the original and resized it to 1000 by 750, and reduced the colour depth and saved another .GIF. This was just shy of 600KB. The artefacts from the colour reduction are there, but it's not too bad overall. But definitely best to use JPEG for photos, both in terms of image quality and file size. But as we know, JPEG is a no-no for line diagrams.
A final work about resizing. When you change the number of pixels, it's not a straightforward process - just have a look at the Wikipedia article to get an idea of what's involved. And back in the 1990s, some graphics programs didn't do a brilliant job. Indeed, nor did web browsers until some time after this, which is why it was important to make sure that the size properties in the IMG tags matched the actual pixel size of the image (much less of an issue today). So given that implementations of image resizing algorithms were once necessarily less than perfect, that might have fed into workflow decisions like "crop before resize" back in the day, and that's where I thought Jeffrey was coming from in post #15. But that's not been an issue in the last 2 decades, which is why I said it doesn't matter. But obviously, "crop before JPEG encode" is what I'd hope anyone would do by default. Get all the manipulation done on the uncompressed image held in RAM, then only save as a JPEG file right at the end.
Although image resizing is a mature science, it's interesting to note the difference in quality in HD to SD downscalers - that's one of the practical exercises we get people to do at work. Of course, they're having to work in real time, unlike Paint Shop Pro
