Posted by David Schoen on January 2, 2017 at 2:03 PM
Despite using sRGB from start to finish ( taking the image in camera to jpg conversion for web to NPN publication), I have noticed about a 10% plus increase in saturation especially in magentas and blues when looking at the finished jpg image on my desktop and the published image on NPN. I do have an ASUS ProArt monitor and I just got a Spyder 5 pro calibration system. Some NPN members who seem to be particularly sensitive to saturation levels have left comments on my images regarding saturation. As a result, I have started dialing back the saturation on my jpgs by 5-10% before publishing in some cases. I also see differences in saturation in posted images on the site between small and large detailed images. Is this just part of the jpg conversion process or is it an NPN issue?
Posted by Keith Bauer on January 2, 2017 at 9:17 PM
David:
A couple of comments / questions:
You say you start using sRGB in the camera. The setting in the camera is meaningless if you are shooting in RAW. It only affects the appearance to the image on the back of the camera from a RAW file since that is displaying the embedded jpeg in the header of the RAW file.
The issue you are seeing between small and large images in saturation is an NPN issue that I have mentioned dozens of times. You need to create both the large and small versions an upload both. Both the small and large should be converted to the sRGB color space (do not use the Assign Profile function in Photoshop), then saved with the color profile embedded in the image. If you only upload the large version and allow the NPN software to create the smaller version, it does NOT honor the color space embedded in the image and often creates a shift in colors and/or saturation. I'd really like to see this corrected but after talking about it for a couple of years, I'm not optimistic.
What web browser are you using. Not all web browsers honor the embedded color spaces in images. IE was notoriously bad about it. I don't have a current list of browsers that behave with colors.
David, your choice of ASUS and Spyder5 are good ones. I have the same setup. I feel Keith has outlined items you need to verify to minimize any image "shift" in performance including saturation outcomes. I'm a firm believer in his point about the making of 2 separate images for upload too. Make a full size up to 1600 and then just save and scale down another to 720. Any loss in the exchange will be minimal and most really do not care too much about the 720 image, it is the full scale sized image that allows some decent viewing for follow up C&C's.
As far as browsers that Keith mentions I've used Mozilla Firefox for years and felt it does the best job in color management overall.
Keith and Paul have given some excellent advice. I also create two images: one @ 720px and the other 1000px for the large image.
In Photo Shop, my 'master files' are 16 bit in Adobe RGB. I always convert to 8 bit and sRGB, and ensure sRGB is embedded in the image for the Web.
The down-side of these conversions is that you lose image data. Add to that jpg compression and there will be differences between an image rendered in a browser and in your editing software.
Firefox, and I believe Safari, will recognize Adobe RGB, but other browsers do not, and display in whatever color space is default for that browser. The safest bet is to be sure sRGB is embedded in the image file. MS' new Edge browser appears to do a better job with color than IE ever did.
As Keith indicated, there is a mismatch between the 720px image and the large version on NPN. This is true even if one uploads two distinct images, although the differences are not extreme. This is an issue that Jim and DtP (Dave the Programmer) need to look into. Folks on slower Web connections may not view the large version because it takes too long to download and display, so it would be nice if the 720px image was more accurate in terms of color and grey scale.
I am interested to hear what others have to say about these issues.
--P
Posted by David Schoen on January 3, 2017 at 12:15 PM
I've always posted a large image and a small image but I've done it a little differently. What I noticed with respect to large and small has to do with file size. I maintain the same pixel size for both images but for the large image, I keep the file size less than 1 MB and for the small size less than 500 kB. I am not sure whether this accomplishes the same goal with the software? I still notice in general, the smaller image is more saturated than the larger image which seems to have more accurate color rendition if done this way. This is not always the case in images that have deep blues and deep magentas. Those need additional fine tuning.
The software will not let me post a large image over 999 kB or small image greater than 499 kB. The pixel dimensions are irrelevant it appears, at least with respect to posting.
I am guessing most monitors can support images at least 1400 x 1024. Perhaps, we could take a poll and find out how many people have monitors which cannot currently support those dimensions. That may be true of a few laptops and small tablets.
By the way, I am using Firefox. I used TK actions to convert the image for the web.
Posted by Lon Overacker on January 3, 2017 at 1:41 PM
I maintain the same pixel size for both images but for the large image, I keep the file size less than 1 MB and for the small size less than 500 kB.
David, Can you be more specific on this? I suspect this is a clue as to what might be causing your issues. I'm going to assume that you're using PhotoShop? And what dialog are you using to resize and save images? Image Size, Save As, Save for Web?
There are 3 variables when resizing and saving images for the web. You mention just 2, File size and dimension (pixel size I'm assuming is the same as dimension? 1000px by 800px for example.) the 3rd variable that hasn't been mentioned is jpg quality. This is expressed differently, but usually a number between 1-12, 0-100 or low, med, high, very high and max.
You don't mention what pixel size or dimensions you're using to start the process, but you did say you don't change the dimension for the large and small file uploads. If you don't change dimension, then the ONLY way to get an image to a certain file size (ie. 999kb, or 499kb) is to adjust the jpg quality of the image.
Example. Let's assume we're going to start with a jpg image that has a dimension of 1600 pixels on the long side. Below is what happens when you save at different jpg quality settings: (making these numbers up for illustration)
Max quality(100) = file size 1.5mb
Very high quality (80) = file size 980kb
high quality (60) = file size 600k
med quality (30) = file size 325k
low quality (10) = 85k
If your dimensions are original dimensions of the captured image and you're only using file size to dictate your final jpg image, the jpg quality will be very poor in order to achieve the file size. I know I'm making this more confusing than it has to be.
I can't speak for anyone else's process, but here's mine in a nutshell.
1. I create 2 separate images for the large and small views from 1 master psd file
2. I use TK's Web Sharpening action, but basically it uses Image>Image Size to select final 1200px horizontal dimension (1000px for verticals) and then repeat from master for smaller version. I use 630px (my frame takes it up close to the max 720px)
3. (Ignoring sharpening steps) Save for Web. embed sRGB profile checked. I adjust image quality to ensure I get just under the 1mb or 500kb file size limit. For the majority of my images I can save with a very high quality and for the smaller 720px version I can often save at max(100) quality.
Another way to look at it. I choose 1200px for my large image. We can choose as large as 1600px, but when doing so, that means a larger file size, which means you have to reduce jpg quality even more to get under the 1mb/500k limits.
jpg quality below 50 can explain many display issues, including one of your recent posts "Morning Fog" where I, and perhaps others, commented that the sky/clouds were "pixelated." this is likely due to a very low jpg quality setting. And from your workflow description of not changing the dimensions of the image (pixel size) that this likely explains the issues you're seeing - including issues with color/saturation.
I am guessing most monitors can support images at least 1400 x 1024. Perhaps, we could take a poll and find out how many people have monitors which cannot currently support those dimensions.
I wanted to comment on this. "Supporting" images? Any monitor can display any image regardless of it's dimensions. What happens is if the image is larger than the monitors display resolution, you just can't see the entire image without scrolling. It has nothing to do whether or not an image will work or be displayed on a monitor, it's a matter of whether or not you can see all or only part of an image. That's the reason why many choose shorter dimensions for their vertical images. You can't get a good sense of an image when you have to scroll up and down to view it.
Example. My monitor has a display resolution of 1980x1080. I can easily view horizontal images at 1600px wide. But a vertical image of 1200px, I have to scroll.
Lastly, I'll concur with Keith and others that there is a difference between the small and large versions. Even posting 2 separate images the issue is present. I posted about this way back when as well, even providing examples. So, that only complicates your issue.
All clear as mud I'm sure.....
Posted by David Schoen on January 3, 2017 at 6:39 PM
Lon:
In answer to your questions, I am using TK actions to sharpen and then save for Web in Photoshop CC 2017.
I typically use the horizontal measurement and 50% for the sharpening algorithm in TK actions. I typically set the horizontal measurement at 1400-1500 pixels and let the software figure out the vertical measurement. When I use portrait mode images, I always set the vertical measurement at 1024 pixels and let the software figure out the horizontal measurement. I then adjust the image size based upon the highest quality for the large image and lower quality image for the smaller image and post each separately. That is to say I tried to find the highest quality that lets me publish the large image under 1000 kB and the highest quality the smallest image can be published under 500 kB. It is extremely rare that I have to go below 50% quality even to publish the small image.
Remember, all images are 72 dots per inch regardless as JPEG's.
Today, I published an image in the weekly challenge of a waterfall close-up in which I set the image size at 1400 pixels in the horizontal dimension for the high quality image and then down adjusted the quality to meet the 1000 kB limit and then set the image size at 720 pixels for the smaller image and adjusted the quality to meet the 500 kB limit. I'm not sure I see a whole lot of difference between the way I had been doing it and the way I did it today. But this was the first time I had tried this and it was with an image that does not have a whole lot of saturation. I will continue to take the new approach and see if it makes a difference.
So maybe I'm wrong about this, but if you have more pixels, would you have more information? If you publish JPEG image with a horizontal dimension of 720 pixels at 100% quality and the same JPEG image at 1400 pixels 50% quality, would you have the same amount of information if the file sizes are identical and then would the images be identical? Both images are 72 dots per inch; correct?
If that theory is correct, and it may not be, then it would not make any difference using my original approach of setting the horizontal pixel dimension and adjusting the quality. But I believe that might have been my rationale for doing it that way.
Your other question had to do with the image Morning Fog. In fact this image was published with a 1400 pixel horizontal dimension and created at 100%, a 705.5 K file which was the large detailed image file. The smaller file was at 94% and created a 490 4K file. So that would not account for the pixelation. As an aside, I examined the pixelation very closely and at very high magnification those pixels are actually round and I think part of the fog. It is a very strange effect. I would be happy to send you one of the originals to see what you think because I know you like to figure out stuff like that. I was fascinated by it.
With respect to the issue about monitors supporting at least 1400 x 1024, I was hoping to find information that would not require the necessity to scroll when looking at an image. I'm aware that you can see anything on the web if you scroll but wished to avoid scrolling because it takes away from the experience of looking at a photograph.
But once again, regardless of which approach one takes in publishing an image on NPN, many members have noticed issues and differences between the smaller image and the larger image. This is an issue that has come up on multiple occasions.
I do think this is a good healthy discussion...
Posted by Lon Overacker on January 4, 2017 at 1:04 AM
David,
Thanks for you detailed response. Knowing your workflow might have eliminated the need for my response... ;-) Basically, it sounds like your workflow is the same as mine and perhaps many others. thanks for detailing it out.
And so, the mystery still remains. It seems you're using the same workflow that many are using, yet you're not getting the color/saturation results you're expecting.
Personally, I think most members here who comment on color/saturation issues are probably working on some color managed, monitory-profiled system, which further makes this all more of a mystery.
Indeed, a good discussion that currently seems to have no explanation.
"So maybe I'm wrong about this, but if you have more pixels, would you have more information? If you publish JPEG image with a horizontal dimension of 720 pixels at 100% quality and the same JPEG image at 1400 pixels 50% quality, would you have the same amount of information if the file sizes are identical and then would the images be identical? Both images are 72 dots per inch; correct?"
Short answer: No. The pixel dimensions of an image that will be displayed in a browser simply tells the browser's rendering engine to display that image at that size. For example: If you have an image 1,400px X 1,400px, and the the browser is set to view the image at 100%, the displayed image will be 1,400px X 1,400px regardless of the dpi of the image (say 72 dpi).
Additionally, whenever you compress a jpeg image, you lose image data. The compression algorithm removes image data and attempts to fill in the gaps by using the 'nearest neighbor' pixels. Therefore, if you have a large image, and compress it to much, the algorithm cannot compensate, and you wind up with a 'pixelated' rendering. This is why we need to save our images with the lowest amount of compression, i.e. at the highest quality possible in order to remain within the file size constraints imposed by NPN.
"With respect to the issue about monitors supporting at least 1400 x 1024, I was hoping to find information that would not require the necessity to scroll when looking at an image. I'm aware that you can see anything on the web if you scroll but wished to avoid scrolling because it takes away from the experience of looking at a photograph."
Assuming the browser window is 'full screen', you have to take into account not only your image size but also the other content in the Web page. For example: If you have a web page with a 100px tall header, an image 1200px in height, and a 100px tall page footer, the page has a total height of 1400px. If the monitor has a vertical resolution of 1440px, then the whole page will be displayed and no scrolling is necessary. Now, if the image is (say) 1,400px with the page header and footer being the same, you can see that you will now have to scroll.
Lon wrote: "Personally, I think most members here who comment on color/saturation issues are probably working on some color managed, monitory-profiled system, which further makes this all more of a mystery."
I agree that a goodly portion of the members here have color managed systems. The issue is that browsers, other than Firefox and Safari (and perhaps a few others), are poorly color managed in terms of RGB and grey scale rendering. Note that RGB relates to color hue and saturation, and grey scale is related to the dynamic range of the image. If the browser's rendering engine does not handle these two items well, then, even with a calibrated monitor, the color and grey scale as displayed will not be accurate. Therein lies the rub: I might comment that an image is too magenta using MS Edge, for example, but Paul, viewing the same image in Firefox does not get that impression, assuming the calibration of our monitors is accurate. Added to this is the clear difference between the small and large versions on NPN, and the mystery deepens even more. Argh!
--P
Posted by Lon Overacker on January 5, 2017 at 12:23 PM
"So maybe I'm wrong about this, but if you have more pixels, would you have more information? If you publish JPEG image with a horizontal dimension of 720 pixels at 100% quality and the same JPEG image at 1400 pixels 50% quality, would you have the same amount of information if the file sizes are identical and then would the images be identical? Both images are 72 dots per inch; correct?"
Since we're dealing with just JPG's in this discussion, by definition the JPG format compresses data; ie. data loss. I'm not completely sure, but even a jpg quality setting of 100, the image is still being compressed and data is lost.
To your example of saving the same file with two different sizes and quality, NO, you won't necessarily have the same amount of information. To set this up, it is true that a 1,000x1,000 pixel image contains exactly 1 million pixels, regardless of what you captured with your camera. Ahhh, but now enter jpg compression. If you have an image frame full of fall color leaves, or my rock wall or grasses image, there are many, many pixels of different tone and color (thinking on the pixel scale.) JPG compression is not as effective due to the algorithm's that Preston mentioned with the "nearest neighbor" algorithms. Conversely, if you have a b&w image where it's just a lot of blank sky, then the compression algorithm is much more efficient and the file size can be decreased considerably.
In a nutshell, the ending file size isn't a linear correlation to dimension and quality settings. The type of data within the image matters too. A very detailed image won't compress as efficiently resulting in a larger file, than say an image of all blue sky, which will compress to a very small file size.
Discussion
9 repliesA couple of comments / questions:
You say you start using sRGB in the camera. The setting in the camera is meaningless if you are shooting in RAW. It only affects the appearance to the image on the back of the camera from a RAW file since that is displaying the embedded jpeg in the header of the RAW file.
The issue you are seeing between small and large images in saturation is an NPN issue that I have mentioned dozens of times. You need to create both the large and small versions an upload both. Both the small and large should be converted to the sRGB color space (do not use the Assign Profile function in Photoshop), then saved with the color profile embedded in the image. If you only upload the large version and allow the NPN software to create the smaller version, it does NOT honor the color space embedded in the image and often creates a shift in colors and/or saturation. I'd really like to see this corrected but after talking about it for a couple of years, I'm not optimistic.
What web browser are you using. Not all web browsers honor the embedded color spaces in images. IE was notoriously bad about it. I don't have a current list of browsers that behave with colors.
As far as browsers that Keith mentions I've used Mozilla Firefox for years and felt it does the best job in color management overall.
Mozilla - Firefox Color Management
Keith and Paul have given some excellent advice. I also create two images: one @ 720px and the other 1000px for the large image.
In Photo Shop, my 'master files' are 16 bit in Adobe RGB. I always convert to 8 bit and sRGB, and ensure sRGB is embedded in the image for the Web.
The down-side of these conversions is that you lose image data. Add to that jpg compression and there will be differences between an image rendered in a browser and in your editing software.
Firefox, and I believe Safari, will recognize Adobe RGB, but other browsers do not, and display in whatever color space is default for that browser. The safest bet is to be sure sRGB is embedded in the image file. MS' new Edge browser appears to do a better job with color than IE ever did.
As Keith indicated, there is a mismatch between the 720px image and the large version on NPN. This is true even if one uploads two distinct images, although the differences are not extreme. This is an issue that Jim and DtP (Dave the Programmer) need to look into. Folks on slower Web connections may not view the large version because it takes too long to download and display, so it would be nice if the 720px image was more accurate in terms of color and grey scale.
I am interested to hear what others have to say about these issues.
--P
The software will not let me post a large image over 999 kB or small image greater than 499 kB. The pixel dimensions are irrelevant it appears, at least with respect to posting.
I am guessing most monitors can support images at least 1400 x 1024. Perhaps, we could take a poll and find out how many people have monitors which cannot currently support those dimensions. That may be true of a few laptops and small tablets.
By the way, I am using Firefox. I used TK actions to convert the image for the web.
There are 3 variables when resizing and saving images for the web. You mention just 2, File size and dimension (pixel size I'm assuming is the same as dimension? 1000px by 800px for example.) the 3rd variable that hasn't been mentioned is jpg quality. This is expressed differently, but usually a number between 1-12, 0-100 or low, med, high, very high and max.
You don't mention what pixel size or dimensions you're using to start the process, but you did say you don't change the dimension for the large and small file uploads. If you don't change dimension, then the ONLY way to get an image to a certain file size (ie. 999kb, or 499kb) is to adjust the jpg quality of the image.
Example. Let's assume we're going to start with a jpg image that has a dimension of 1600 pixels on the long side. Below is what happens when you save at different jpg quality settings: (making these numbers up for illustration)
Max quality(100) = file size 1.5mb
Very high quality (80) = file size 980kb
high quality (60) = file size 600k
med quality (30) = file size 325k
low quality (10) = 85k
If your dimensions are original dimensions of the captured image and you're only using file size to dictate your final jpg image, the jpg quality will be very poor in order to achieve the file size. I know I'm making this more confusing than it has to be.
I can't speak for anyone else's process, but here's mine in a nutshell.
1. I create 2 separate images for the large and small views from 1 master psd file
2. I use TK's Web Sharpening action, but basically it uses Image>Image Size to select final 1200px horizontal dimension (1000px for verticals) and then repeat from master for smaller version. I use 630px (my frame takes it up close to the max 720px)
3. (Ignoring sharpening steps) Save for Web. embed sRGB profile checked. I adjust image quality to ensure I get just under the 1mb or 500kb file size limit. For the majority of my images I can save with a very high quality and for the smaller 720px version I can often save at max(100) quality.
Another way to look at it. I choose 1200px for my large image. We can choose as large as 1600px, but when doing so, that means a larger file size, which means you have to reduce jpg quality even more to get under the 1mb/500k limits.
jpg quality below 50 can explain many display issues, including one of your recent posts "Morning Fog" where I, and perhaps others, commented that the sky/clouds were "pixelated." this is likely due to a very low jpg quality setting. And from your workflow description of not changing the dimensions of the image (pixel size) that this likely explains the issues you're seeing - including issues with color/saturation. I wanted to comment on this. "Supporting" images? Any monitor can display any image regardless of it's dimensions. What happens is if the image is larger than the monitors display resolution, you just can't see the entire image without scrolling. It has nothing to do whether or not an image will work or be displayed on a monitor, it's a matter of whether or not you can see all or only part of an image. That's the reason why many choose shorter dimensions for their vertical images. You can't get a good sense of an image when you have to scroll up and down to view it.
Example. My monitor has a display resolution of 1980x1080. I can easily view horizontal images at 1600px wide. But a vertical image of 1200px, I have to scroll.
Lastly, I'll concur with Keith and others that there is a difference between the small and large versions. Even posting 2 separate images the issue is present. I posted about this way back when as well, even providing examples. So, that only complicates your issue.
All clear as mud I'm sure.....
In answer to your questions, I am using TK actions to sharpen and then save for Web in Photoshop CC 2017.
I typically use the horizontal measurement and 50% for the sharpening algorithm in TK actions. I typically set the horizontal measurement at 1400-1500 pixels and let the software figure out the vertical measurement. When I use portrait mode images, I always set the vertical measurement at 1024 pixels and let the software figure out the horizontal measurement. I then adjust the image size based upon the highest quality for the large image and lower quality image for the smaller image and post each separately. That is to say I tried to find the highest quality that lets me publish the large image under 1000 kB and the highest quality the smallest image can be published under 500 kB. It is extremely rare that I have to go below 50% quality even to publish the small image.
Remember, all images are 72 dots per inch regardless as JPEG's.
Today, I published an image in the weekly challenge of a waterfall close-up in which I set the image size at 1400 pixels in the horizontal dimension for the high quality image and then down adjusted the quality to meet the 1000 kB limit and then set the image size at 720 pixels for the smaller image and adjusted the quality to meet the 500 kB limit. I'm not sure I see a whole lot of difference between the way I had been doing it and the way I did it today. But this was the first time I had tried this and it was with an image that does not have a whole lot of saturation. I will continue to take the new approach and see if it makes a difference.
So maybe I'm wrong about this, but if you have more pixels, would you have more information? If you publish JPEG image with a horizontal dimension of 720 pixels at 100% quality and the same JPEG image at 1400 pixels 50% quality, would you have the same amount of information if the file sizes are identical and then would the images be identical? Both images are 72 dots per inch; correct?
If that theory is correct, and it may not be, then it would not make any difference using my original approach of setting the horizontal pixel dimension and adjusting the quality. But I believe that might have been my rationale for doing it that way.
Your other question had to do with the image Morning Fog. In fact this image was published with a 1400 pixel horizontal dimension and created at 100%, a 705.5 K file which was the large detailed image file. The smaller file was at 94% and created a 490 4K file. So that would not account for the pixelation. As an aside, I examined the pixelation very closely and at very high magnification those pixels are actually round and I think part of the fog. It is a very strange effect. I would be happy to send you one of the originals to see what you think because I know you like to figure out stuff like that. I was fascinated by it.
With respect to the issue about monitors supporting at least 1400 x 1024, I was hoping to find information that would not require the necessity to scroll when looking at an image. I'm aware that you can see anything on the web if you scroll but wished to avoid scrolling because it takes away from the experience of looking at a photograph.
But once again, regardless of which approach one takes in publishing an image on NPN, many members have noticed issues and differences between the smaller image and the larger image. This is an issue that has come up on multiple occasions.
I do think this is a good healthy discussion...
Thanks for you detailed response. Knowing your workflow might have eliminated the need for my response... ;-) Basically, it sounds like your workflow is the same as mine and perhaps many others. thanks for detailing it out.
And so, the mystery still remains. It seems you're using the same workflow that many are using, yet you're not getting the color/saturation results you're expecting.
Personally, I think most members here who comment on color/saturation issues are probably working on some color managed, monitory-profiled system, which further makes this all more of a mystery.
Indeed, a good discussion that currently seems to have no explanation.
Lon
Short answer: No. The pixel dimensions of an image that will be displayed in a browser simply tells the browser's rendering engine to display that image at that size. For example: If you have an image 1,400px X 1,400px, and the the browser is set to view the image at 100%, the displayed image will be 1,400px X 1,400px regardless of the dpi of the image (say 72 dpi).
Additionally, whenever you compress a jpeg image, you lose image data. The compression algorithm removes image data and attempts to fill in the gaps by using the 'nearest neighbor' pixels. Therefore, if you have a large image, and compress it to much, the algorithm cannot compensate, and you wind up with a 'pixelated' rendering. This is why we need to save our images with the lowest amount of compression, i.e. at the highest quality possible in order to remain within the file size constraints imposed by NPN.
"With respect to the issue about monitors supporting at least 1400 x 1024, I was hoping to find information that would not require the necessity to scroll when looking at an image. I'm aware that you can see anything on the web if you scroll but wished to avoid scrolling because it takes away from the experience of looking at a photograph."
Assuming the browser window is 'full screen', you have to take into account not only your image size but also the other content in the Web page. For example: If you have a web page with a 100px tall header, an image 1200px in height, and a 100px tall page footer, the page has a total height of 1400px. If the monitor has a vertical resolution of 1440px, then the whole page will be displayed and no scrolling is necessary. Now, if the image is (say) 1,400px with the page header and footer being the same, you can see that you will now have to scroll.
Lon wrote: "Personally, I think most members here who comment on color/saturation issues are probably working on some color managed, monitory-profiled system, which further makes this all more of a mystery."
I agree that a goodly portion of the members here have color managed systems. The issue is that browsers, other than Firefox and Safari (and perhaps a few others), are poorly color managed in terms of RGB and grey scale rendering. Note that RGB relates to color hue and saturation, and grey scale is related to the dynamic range of the image. If the browser's rendering engine does not handle these two items well, then, even with a calibrated monitor, the color and grey scale as displayed will not be accurate. Therein lies the rub: I might comment that an image is too magenta using MS Edge, for example, but Paul, viewing the same image in Firefox does not get that impression, assuming the calibration of our monitors is accurate. Added to this is the clear difference between the small and large versions on NPN, and the mystery deepens even more. Argh!
--P
To your example of saving the same file with two different sizes and quality, NO, you won't necessarily have the same amount of information. To set this up, it is true that a 1,000x1,000 pixel image contains exactly 1 million pixels, regardless of what you captured with your camera. Ahhh, but now enter jpg compression. If you have an image frame full of fall color leaves, or my rock wall or grasses image, there are many, many pixels of different tone and color (thinking on the pixel scale.) JPG compression is not as effective due to the algorithm's that Preston mentioned with the "nearest neighbor" algorithms. Conversely, if you have a b&w image where it's just a lot of blank sky, then the compression algorithm is much more efficient and the file size can be decreased considerably.
In a nutshell, the ending file size isn't a linear correlation to dimension and quality settings. The type of data within the image matters too. A very detailed image won't compress as efficiently resulting in a larger file, than say an image of all blue sky, which will compress to a very small file size.
Another clear as mud explanation? ;-)