You want more? M'kay:
1.around the boat
2.church tower + borders of the big beige house wall on the left
3.cable-time
4.around my plant - does anybody know what kind of plant this is?
5. at the right border of the yellow trashcan top
6.another leaf-less tree
7.horizont line + kite
8.license plate + at borders on hood where reflected bright sky meets darker parts
9. borders to black points of the dices
10. around the plants - especially visible on the right side of the picture
11. the red part looks awful...and in the white letters, especially the "P"robe
I hope people don't take this post the wrong way, but I'm confused here and trying to understand if we're all trying to do the same thing. I posted a pic with what I thought were clear compression artifacts (the classic sky-mountain boundary issue) and those artifacts are easily visible on all my screens with no magnification (at normal viewing size for that image). I assume everyone else can see them too. On Mike's Golden Gate Bridge picture, I can see the artifacting in the sky.
Then, in PerfectPixel's baseball picture, I can't see the artifacts at all at normal viewing size. The one Andy posted from an old thread, clearly does show the typical blue-background-against-a-high-contrast-edge artifacts.
I do see the artifacts in PerfectPixel's LOVE image, but there are artifacts visible in the original of that image too, so that's not a very fair test case either.
Sebastian posted nine images in this message and I can't see the artifacts in any of them. He even tries to describe where they are and I can't see any of them.
kwalsh posted several lightning pics in this message. I examined the first one in detail. I can clearly see posterization in the sky on my laptop screen, but I see the same posterization (thought a little less) in the original image too, so the problem appears to be more with the original than it is with smugmug.
This kwalsh picture is a great example of JPEG artifacting and not just against a high-contrast border, it's posterization in the sky. The sky in the original is completely clean, the compressed version looks bad.
So, by my count, I've got a score of:
4 of the postings with clear artifacts or posterization (jfriend, Mike Lane , Andy's posting from a previous thread and one of the kwalsh photos).
2 or 3 where there is clear artifacting in the compressed version, but the original shows artifacts too, so it's not surprising that any form of compression and resizing is going to magnify the pre-existing artifacts.
And, the other 75% of the images where I can't find the artifacts at normal viewing size.
I'm wondering if I'm just blind or are we confused about the point of this exercise? In my understanding, the point of this exercise is to identify photos with JPEG compression artifacts that are clearly visible at normal viewing size and thus seriously detract from the normal smugmug web viewing, but those artifacts are not visible in the original. What we're trying to do is help smugmug to tweak their compression algorithm so that there are no visible JPEG artifacts when the smaller images are viewed at 100% (how a web browser displays them).
It doesn't matter if an image has some compression artifacts that you can only see when you zoom in and look closer. That is actually expected. That is NOT the problem we're trying to solve.
So ... of those that I can't find the artifacts in where there are no artifacts in the original, are the posters of those images claiming that those artifacts are visible at normal web viewing size and that they detract from the image in a measurable way? It's possible I just don't see what everyone else is seeing. But, I decided to post this summary because I thought it was also possible that people are posting examples of something other than what I thought was asked for here.
i know exactly what a jpeg artifact looks like, and they are still very obvious to me w/my lcd at work (along the fence/sky transition). Now i'll say this, i've only had that monitor for a matter of a few weeks and that was the first batch of pictures i uploaded since so it may just be the monitor amplifies artifacts. For what it's worth, the other examples that i had a chance to look at on that monitor were also very obvious. I'm running a fairly high resolution (1280x1024) and i'm not sure if that makes a difference or not but on a 19" monitor i would think that's a fairly common resolution.
I'm wondering if I'm just blind or are we confused about the point of this exercise? In my understanding, the point of this exercise is to identify photos with JPEG compression artifacts that are clearly visible at normal viewing size and thus seriously detract from the normal smugmug web viewing, but those artifacts are not visible in the original. What we're trying to do is help smugmug to tweak their compression algorithm so that there are no visible JPEG artifacts when the smaller images are viewed at 100% (how a web browser displays them).
It doesn't matter if an image has some compression artifacts that you can only see when you zoom in and look closer. That is actually expected. That is NOT the problem we're trying to solve.
Thanks for putting all this together! As Baldy already said - it's very subjective and I guess the photographers are mostly the ones noticing the stuff on their own pictures what others may not see at all - without taking the technical aspect in.
In my case I did view the pictures at normal size in my browser. I've gone through my galleries of originals and viewed the pictures at large size that I thought could include some artifacts. At those I looked closely especially at areas normally know for artification like edges, but I didn't zoom in or something like that.
I admit that some pictures may be bordercases, where it's barely visible, but on most I can see it clearly.
I think the artifacts are pretty evident. The good news is that it only happens to the compressed versions and not the original posts.
In this original-sized chess image pic, I am really confused by something. When I look at the original in FireFox at 100%, it doesn't look all the great. I can see signficant posterization in the color gradation of the background. But, when I download it and load it into Photoshop, at 100% it looks a lot better. Why would this be?
Same image. It's already sRGB. What is CS2 doing to make it look better than it does in a browser? If this is something that happens to others, then there could be something else going on here that makes images on the web in smugmug look worse than in Photoshop. IE looks more like Firefox than CS2, but it's different than Firefox. Photoshop seems to be able to handle the gradient of color in the background much better than either of the other two.
What can this be? I thought decompressing a JPEG was deterministic (same result everytime). Obviously compressing a JPEG varies by algorithm, but do different programs decompress differently? Or is CS2 doing something to the video system upon display to make them look better in CS2?
Try it yourself. Take the above original-sized image and download it to your hard disk. Then view it in Firefox, IE and Photoshop all at 100%. I find the easiest point to compare is in the vicinity of x=515, y=870 (you can see the coordinates in the Photoshop info palette). The area I'm looking at is to the left and little below the top of the chess piece. The Firefox and IE images look blotchy. The Photoshop images looks a lot less blotchy.
I do see differences between Photoshop and IE or the Windows Explorer viewer. I think it has to do with what Photoshop does to maintain the calibration to the monitor. It must be using a different profile from ICM or somehow adjusting it.
I couldn't see what you were talking about with the difference...
So I took a screendump of Photoshop CS2 and IE, both at 100%, selected an area, manually pixel aligned the CS and IE versions and subtracted the two layers. Cut the subtracted area out and ran some simple statistics...
Mean difference: 4.56... OK, so that's not very much...
However, what's interesting is that the difference appears to be largely in the green channel, which has a mean difference of 7.62. Whereas the blue has a mean difference of only 1.2.
You can see this as well when you look at the subtractions, the area is a very dark green.
I think the most likely explanation is that Photoshop is using some custom clever graphics library to attempt to optimise flexibility and display in the colour profiles. Interestingly turning them off didn't seem to make that much of a difference... But I guess they're unlikely to be using the GDI+ standard libraries... Afterall, for people who design their own caching architectures on top of another OS, what's designing the odd graphics library
Either that or it's doing inference between JPEG blocks to try and extract the maximum amount of data, I guess I might have tried doing that in their position. They do also have some filter that claims to be able to reduce JPEG compression damage, but I doubt they'd be applying that without the user's permission... I hope not anyway...
However, whilst this is all interesting, IMHO I don't think it's likely to be what's causing the artifacting. The blotchyness difference is likely just to be the differences resulting in slightly amplified green-channel noise. That's what I'm guessing anyhow...
I suspect it's also fairly monitor dependent. I'm using a (badly :-)) calibrated Dell Flat Panel, and I really can't see the difference, even when I know it's there...
Interesting observation, perhaps someone who knows more than me (not hard...) about Photoshop's colour architecture could chime in?, :
Sorry to resurrect an old thread, but I'm seeing resizing artifacts in many of my photos. Example below:
The artifacts I see are around the facial area. This is the smugmug large resampling of the original 8MP file from Canon's DPP. Like others, I see much more artifacting on my (calibrated) LCD than I do on my (uncalibrated) CRT.
You should do a blind test - post several duplicate images (from each of the different sites, and the current and proposed smugmug encoding) but just number them, don't identify where each one came from. Then have people rank them.
0
Options
BaldyRegistered Users, Super ModeratorsPosts: 2,853moderator
edited January 7, 2006
We've been doing quite a number of blind tests and it's amazing how much they vary. A big factor seems to be display resolution -- the smaller the number of pixels your screen has, the more you can see artifacts.
It's a hard problem because it has to be counterbalanced by the speed blind test. Seems 99 of 100 notice speed and 1 of 100 notice artifacts.
From what I believe my clients would prefer, I like the "CURRENT SMUGMUG" one the best. At least for this photo selected. The Current setting looks sharper than the others and I don't really see the artifacts in this photo. I've seen many others (some of mine) where the current smugmug settings really cause a lot of artifacts, but it seems real hit or miss.
My monitor is calibrated and is set to 1024x768 resolution. I'll be interested to see what others prefer.
Okay, focus group time! We're converging on new algorithms and settings and want to test them on your eyes & display.
Proposed high-end new SmugMug settings (there would be a 20% performance penalty over the previous setting due to increased number of bytes):
Baldy, have you ever considered a different approach?
I myself notice JPEG artifacts on perhaps 2% of my images (usually mountain/deep blue sky boundary). But, when I do notice them, I want to do something about them. When I don't notice them, I'm perfectly fine with having faster downloads and less bandwidth usage and saving smugmug some storage.
The best of all solutions would be to be able to automatically detect which images need less compression because of their composition and ony use a lower compression on them.
But, assuming that auto-detection is not an easy problem to solve, what if you just give the customer the ability to pick selected photos from a gallery and "convert" them to lower compression. You would just regenerate the new sizes with the new algorithm. Wouldn't that give you an answer for the customers who complain about particular photos while not changing the default for the vast majority of photos that are better off loading faster and consuming less storage?
On my main display (1600x1200, 21.3" LCD, color profile from mfg) I can barely discern any difference in the sample pictures. When I switch to another display (1280x1024, old worn out 11.8" LCD) the artifacts are clearly noticable in many of the shots. (And I'll confirm what you've already noted: it seems purely to be an issue of the resolution, not the calibration... as bumping my main display down to a lower resolution makes them stand out just as well.)
For this particular image, the two new smugmug algorythms, and the dpreview alg all seem to noticably out perform the others. The photo.net had the worst compression artifacts, with the current smugmug being just a bit better. The dpreview image was only slightly better than the current smugmug setting, and the new versions of smugmug are just a bit better than it is. The low vs high bandwidth new versions aren't all that much different... I'd say they added quality of the high version is barely noticable.
I'd like to seriously echo John's idea... encode everything with the new smugmug low bandwidth settings, but allow customers to request images with artifacts be bumped to a lower compression rate. If you're concerned about folks going through and just requesting it on all their shots then I'm sure we could find enough volunteers in dgrinn to help you do some monitoring of the before after to see if it really mattered in the final image.
SmugMug Sorcerer - Engineering Team Champion for Commerce, Finance, Security, and Data Support http://wall-art.smugmug.com/
Well, I'm at work so its a LCD here at the moment. So I went through the images and carefully ranked them in order using the most obivous artifact (to me anyway) along the little tyke's left arm. And wouldn't you know it, it pretty much came out in exactly the order of file size. Guess information theory is still alive and well...
Anywho, I'd certainly say proposed "low-end" solution is in itself a big improvement over the original. And I'd say for this particular shot the "high-end" solution is artifact free.
So, are your new settings the same regardless of the image or do they vary based on file size or some other metric (this was discussed earlier in the thread I think)?
And I don't mean to degrade this thread to "please reprocess my photo too!", but if the quality setting/quatization is in fact image dependent could you put up samples of this image:
Hey, and once again major kudos for even spending time on this issue!
Hi Ken,
If you only knew... I can't believe how much time I've spent on this and how many thousands of images I've had Mark process, analyze, evaluate... It's amazing how much we've learned about how different camera manufacturers handle compression, and how that's different from Photoshop's approach.
For example, the camera manufacturer has a very tough problem: how to get images onto media fast without the need for a manly processor like your desktop has that would suck its small battery dry. So they make compromises like 2:1 chroma subsampling.
One of the toughest problems to solve is that byte size increases exponentially, not linearly, with with perceived quality once you get into the region of very high quality. On the image I posted above it's not a terrible problem because that image is realitively small, byte-wise. But when it's a photo of a jungle with lots of detail, the byte-size skyrockets.
I think we've reached a high confidence level of going live with the much-improved-over-where-we-are-now version, which should put us well ahead in quality from where Photo.net and PBase are now, and slightly ahead of Phil Askey's galleries on dpreview — without causing the forums to light up with SmugMug is slow messages.
Then we can assess what to do about the remaining few images of Red Ferraris or dark mountains against a saturated blue sky. John's suggestion is interesting and we have another possible trick up our sleeves, but we can see where we are after this improvement.
Many thanks for all your feedback and patience while we've been doing this research.
So, are your new settings the same regardless of the image or do they vary based on file size or some other metric (this was discussed earlier in the thread I think)?
And I don't mean to degrade this thread to "please reprocess my photo too!", but if the quality setting/quatization is in fact image dependent could you put up samples of this image:
That's a very interesting shot and I'd like to add it to our case studies. Can you tell me more about how it was initially captured? From what I can tell, it was saved in Photoshop JPEG 10 on September 10th and captured on September 7th. I'd love to know if it was captured RAW or JPEG, and whether the color space was sRGB if it was JPEG.
Reason I ask is the original shows significant artifacts and I'd like to understand where they came from:
(Make sure your browser displays it full-sized so you have to scroll around to view it. Look at the upper end of the bolts where they are bright.)
Here's what it would look like with our new resize algorithm:
And if we bumped it up about 33% in size to the higher-quality setting, we'd get this:
For this image, bumping it up 33% in size is not so bad because it's a small image, byte-wise, as many images that show artifacts are. But not all are that way.
Anyway, any info you can give on how the original was captured and even better yet, if you can get me a copy, I'd be very grateful.
From what I believe my clients would prefer, I like the "CURRENT SMUGMUG" one the best. At least for this photo selected. The Current setting looks sharper than the others.
Ooops, the sharpness difference is my fault. I didn't apply the unsharp mask step that SmugMug does (20% unsharp mask when we resize). When it goes live, you won't lose sharpness with the higher quality settings because we will apply it then.
I couldn't make out much differences in the photos as at medium they were to small to see a big deal of artifacts and I've recently changed my resolution from 1024 to 1280 using the same monitor.
Ooops, the sharpness difference is my fault. I didn't apply the unsharp mask step that SmugMug does (20% unsharp mask when we resize). When it goes live, you won't lose sharpness with the higher quality settings because we will apply it then.
Uh oh...then it wasn't a good comparison at all?! Often artifacts are introduced after applying USM. Hope you did forget the USM just for the show-off here and not for testing the new compression method.
That also means the new smugmug method will produce even bigger files then what you showed here. Hope this isn't too much as the unsharped new low-end file is already 14kb bigger. How much would USM add?
If you only knew... I can't believe how much time I've spent on this and how many thousands of images I've had Mark process, analyze, evaluate... It's amazing how much we've learned about how different camera manufacturers handle compression, and how that's different from Photoshop's approach.
I can only imagine having done a little bit myself. The only thing worse is something temporal that can't be compared side by side like MP3 audio compression . And yeah I made some bold assertion about what cameras did based on a sample size of two awhile back and was wrong. There are a lot of different ways to skin that cat.
For example, the camera manufacturer has a very tough problem: how to get images onto media fast without the need for a manly processor like your desktop has that would suck its small battery dry. So they make compromises like 2:1 chroma subsampling.
Yes, but keep in mind 2:1 chroma subsampling makes a whole lot of sense for 99% of the cameras out there that use Bayer mosaics since they inherently have half as much chroma resolution as luminance. Of course the one camera that doesn't, the Sigma SD-9/SD-10 actually had their first RAW converter by default output JPEGs with 2:1 chroma subsampling!!! Whoops, no one could see their much touted chroma detail!
Then we can assess what to do about the remaining few images of Red Ferraris or dark mountains against a saturated blue sky. John's suggestion is interesting and we have another possible trick up our sleeves, but we can see where we are after this improvement.
John's idea or whatever your trick is may be a good compromise if "smugmug is slow" starts to hit the wires.
That's a very interesting shot and I'd like to add it to our case studies. Can you tell me more about how it was initially captured? From what I can tell, it was saved in Photoshop JPEG 10 on September 10th and captured on September 7th. I'd love to know if it was captured RAW or JPEG, and whether the color space was sRGB if it was JPEG.
That shot was from a Canon Rebel XT, sRGB, JPEG (I'll need to check if it was fine or normal compression). It was post processed with Neat Image for a little bit of noise reduction and some light photoshoping of a few hot pixels and probably levels. It was one of the first pictures I took with the camera and I didn't spend much time playing with it. It suffers some artifacts around the lightning and some posterization in places as well, but by the time it's resized to medium most of that should disappear. When I get home tonight I'll upload the unmolested original JPEG straight from the camera and post you a link here.
Both of your new resizes are a marked improvement, again the slightly higher quality one seems pretty much artifact free and the lower one is quite an improvement as well.
And again, thanks for all the great work you guys are doing!
0
Options
BaldyRegistered Users, Super ModeratorsPosts: 2,853moderator
Yes, but keep in mind 2:1 chroma subsampling makes a whole lot of sense for 99% of the cameras out there that use Bayer mosaics since they inherently have half as much chroma resolution as luminance.
Y'know... That's the way it should be, seems to me, but it's not what I'm seeing in actual photos. Maybe it's just me but doesn't this one that went RAW => 1:1 chroma subsampling
Look better than this one, which went RAW => 2:1 using the camera superfine setting on a 20D?
(Those are original pixels you're seeing, no resizing or sharpening or anything like that on the JPEG.
BTW, we've been looking at output from lots of cameras. Sony seems to do as you said, save to a constant file size and let the compression vary.
Y'know... That's the way it should be, seems to me, but it's not what I'm seeing in actual photos.
The great thing about emperical tests is they make trite theory melt away. I got to agree the 1:1 does look obviously better than the 1:2. Good to know. You guys could probably write a small book (or maybe a large one) on all you've learned so far!
So I uploaded the original from the camera that hasn't been beat with an ugly stick. Here's the link:
It was in fact JPEG Normal. None the less shows almost no compression halos or posterization unlike the processed one. I think the processed one went through the free version of Neat Image which only outputs to JPEG and then had to have some noise pits removed in Photoshop. So three passes of JPEG, albeit at fairly high quality settings, but still it obviously added up! As expected the artifacts on the resized images appear to be about same as before.
Hope that helps. And maybe in all your copious free time when you're not implementing new features, running a business, answering all these posts on the forums, and biking you could write a blog write up about any interesting tidbits you discovered in your JPEG experiments. I recommed forgoing sleep, it really isn't that necessary .
Y'know... That's the way it should be, seems to me, but it's not what I'm seeing in actual photos. Maybe it's just me but doesn't this one that went RAW => 1:1 chroma subsampling
Hi,
I'm a little confused about those images you posted. (Took the links, converted to Original links and downloaded)
I ran them through my standard JPEG analysis toolkit and got some kind of strange results...
Both of them appear to be using 1:1 chroma subsampling....
I guess it could be that you've downsampled and then upsampled again? That might be OK, but I'd be a touch hesitant.
Futher it's always going to be a tad dangerous to compare the results of RAW and JPEG.
The only same way you could do this comparison that I can think of is take an image from RAW, save it as a PNG and JPG compress it with one version 2:1:1 and the other 1:1:1.
I wouldn't say that the images you posted are comparable as to my tired eyes they appear to have a different fixed colour (one's reddier). This wouldn't be due to subsampling as it uses the same DC bias architecture as non-subsampled images only a different sampling pattern.
I would say it's more likely due to a difference in the processing that was applied.
It's a mirky world to try and do experiments in.... :
Comments
I hope people don't take this post the wrong way, but I'm confused here and trying to understand if we're all trying to do the same thing. I posted a pic with what I thought were clear compression artifacts (the classic sky-mountain boundary issue) and those artifacts are easily visible on all my screens with no magnification (at normal viewing size for that image). I assume everyone else can see them too. On Mike's Golden Gate Bridge picture, I can see the artifacting in the sky.
In BigWebGuy's B&W child behind the fence pic, I can't see any artifacts and Baldy couldn't find them either. Then, in Scale's chair on a red background, the artifacts are obvious, but the original of that image shows serious artifacts too, so that's not really smugmug's fault. Then in MarlinSpike's basketball picture, I can't find the artifacts at normal viewing size.
Then, in PerfectPixel's baseball picture, I can't see the artifacts at all at normal viewing size. The one Andy posted from an old thread, clearly does show the typical blue-background-against-a-high-contrast-edge artifacts.
I do see the artifacts in PerfectPixel's LOVE image, but there are artifacts visible in the original of that image too, so that's not a very fair test case either.
Sebastian posted nine images in this message and I can't see the artifacts in any of them. He even tries to describe where they are and I can't see any of them.
kwalsh posted several lightning pics in this message. I examined the first one in detail. I can clearly see posterization in the sky on my laptop screen, but I see the same posterization (thought a little less) in the original image too, so the problem appears to be more with the original than it is with smugmug.
This kwalsh picture is a great example of JPEG artifacting and not just against a high-contrast border, it's posterization in the sky. The sky in the original is completely clean, the compressed version looks bad.
So, by my count, I've got a score of:
4 of the postings with clear artifacts or posterization (jfriend, Mike Lane , Andy's posting from a previous thread and one of the kwalsh photos).
2 or 3 where there is clear artifacting in the compressed version, but the original shows artifacts too, so it's not surprising that any form of compression and resizing is going to magnify the pre-existing artifacts.
And, the other 75% of the images where I can't find the artifacts at normal viewing size.
I'm wondering if I'm just blind or are we confused about the point of this exercise? In my understanding, the point of this exercise is to identify photos with JPEG compression artifacts that are clearly visible at normal viewing size and thus seriously detract from the normal smugmug web viewing, but those artifacts are not visible in the original. What we're trying to do is help smugmug to tweak their compression algorithm so that there are no visible JPEG artifacts when the smaller images are viewed at 100% (how a web browser displays them).
It doesn't matter if an image has some compression artifacts that you can only see when you zoom in and look closer. That is actually expected. That is NOT the problem we're trying to solve.
So ... of those that I can't find the artifacts in where there are no artifacts in the original, are the posters of those images claiming that those artifacts are visible at normal web viewing size and that they detract from the image in a measurable way? It's possible I just don't see what everyone else is seeing. But, I decided to post this summary because I thought it was also possible that people are posting examples of something other than what I thought was asked for here.
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
JPG2000 rescue us!
http://photos.mikelanestudios.com/
In my case I did view the pictures at normal size in my browser. I've gone through my galleries of originals and viewed the pictures at large size that I thought could include some artifacts. At those I looked closely especially at areas normally know for artification like edges, but I didn't zoom in or something like that.
I admit that some pictures may be bordercases, where it's barely visible, but on most I can see it clearly.
Sebastian
SmugMug Support Hero
Also there's no sign yet of a new format coming to the web, or is there?
Sebastian
SmugMug Support Hero
http://www.philmaland.com/
I think the artifacts are pretty evident. The good news is that it only happens to the compressed versions and not the original posts.
Here's a thread that shows an example and discussion of the problem....
http://www.dgrin.com/showthread.php?t=18949
Also, here's a recent example of what Smugmug does:
Here's what the same image looks like if I downsample with Photoshop and then post to Smugmug (original):
Here's a medium-sized thumbnail of the photo (yuk!!):
In this original-sized chess image pic, I am really confused by something. When I look at the original in FireFox at 100%, it doesn't look all the great. I can see signficant posterization in the color gradation of the background. But, when I download it and load it into Photoshop, at 100% it looks a lot better. Why would this be?
Same image. It's already sRGB. What is CS2 doing to make it look better than it does in a browser? If this is something that happens to others, then there could be something else going on here that makes images on the web in smugmug look worse than in Photoshop. IE looks more like Firefox than CS2, but it's different than Firefox. Photoshop seems to be able to handle the gradient of color in the background much better than either of the other two.
What can this be? I thought decompressing a JPEG was deterministic (same result everytime). Obviously compressing a JPEG varies by algorithm, but do different programs decompress differently? Or is CS2 doing something to the video system upon display to make them look better in CS2?
Try it yourself. Take the above original-sized image and download it to your hard disk. Then view it in Firefox, IE and Photoshop all at 100%. I find the easiest point to compare is in the vicinity of x=515, y=870 (you can see the coordinates in the Photoshop info palette). The area I'm looking at is to the left and little below the top of the chess piece. The Firefox and IE images look blotchy. The Photoshop images looks a lot less blotchy.
Anyone know what could be going on here?
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
Erich
I couldn't see what you were talking about with the difference...
So I took a screendump of Photoshop CS2 and IE, both at 100%, selected an area, manually pixel aligned the CS and IE versions and subtracted the two layers. Cut the subtracted area out and ran some simple statistics...
Mean difference: 4.56... OK, so that's not very much...
However, what's interesting is that the difference appears to be largely in the green channel, which has a mean difference of 7.62. Whereas the blue has a mean difference of only 1.2.
You can see this as well when you look at the subtractions, the area is a very dark green.
I think the most likely explanation is that Photoshop is using some custom clever graphics library to attempt to optimise flexibility and display in the colour profiles. Interestingly turning them off didn't seem to make that much of a difference... But I guess they're unlikely to be using the GDI+ standard libraries... Afterall, for people who design their own caching architectures on top of another OS, what's designing the odd graphics library
Either that or it's doing inference between JPEG blocks to try and extract the maximum amount of data, I guess I might have tried doing that in their position. They do also have some filter that claims to be able to reduce JPEG compression damage, but I doubt they'd be applying that without the user's permission... I hope not anyway...
However, whilst this is all interesting, IMHO I don't think it's likely to be what's causing the artifacting. The blotchyness difference is likely just to be the differences resulting in slightly amplified green-channel noise. That's what I'm guessing anyhow...
I suspect it's also fairly monitor dependent. I'm using a (badly :-)) calibrated Dell Flat Panel, and I really can't see the difference, even when I know it's there...
Interesting observation, perhaps someone who knows more than me (not hard...) about Photoshop's colour architecture could chime in?,
Luke
SmugSoftware: www.smugtools.com
The artifacts I see are around the facial area. This is the smugmug large resampling of the original 8MP file from Canon's DPP. Like others, I see much more artifacting on my (calibrated) LCD than I do on my (uncalibrated) CRT.
Just throwing my hat in the rink...
Swim for Them | WellmanHouse.net | AlbumFetcher | SmugShowBuilder
Sorry, I'm not seeing the picture here, all I get is the 'dead URL' is there any chance you could check the link?
Cheers,
Luke
SmugSoftware: www.smugtools.com
Sorry to switch to medium size, but they're the most commonly viewed.
Current Photo.net setting:
Current SmugMug setting:
Current dpreview setting for camera reviews:
Proposed low-end new SmugMug settings:
Proposed high-end new SmugMug settings (there would be a 20% performance penalty over the previous setting due to increased number of bytes):
Cast your vote.
It's a hard problem because it has to be counterbalanced by the speed blind test. Seems 99 of 100 notice speed and 1 of 100 notice artifacts.
i think important to point out that this will also be a 20% bandwidth increase to us as well.
My monitor is calibrated and is set to 1024x768 resolution. I'll be interested to see what others prefer.
Fred
Baldy, have you ever considered a different approach?
I myself notice JPEG artifacts on perhaps 2% of my images (usually mountain/deep blue sky boundary). But, when I do notice them, I want to do something about them. When I don't notice them, I'm perfectly fine with having faster downloads and less bandwidth usage and saving smugmug some storage.
The best of all solutions would be to be able to automatically detect which images need less compression because of their composition and ony use a lower compression on them.
But, assuming that auto-detection is not an easy problem to solve, what if you just give the customer the ability to pick selected photos from a gallery and "convert" them to lower compression. You would just regenerate the new sizes with the new algorithm. Wouldn't that give you an answer for the customers who complain about particular photos while not changing the default for the vast majority of photos that are better off loading faster and consuming less storage?
Homepage • Popular
JFriend's javascript customizations • Secrets for getting fast answers on Dgrin
Always include a link to your site when posting a question
For this particular image, the two new smugmug algorythms, and the dpreview alg all seem to noticably out perform the others. The photo.net had the worst compression artifacts, with the current smugmug being just a bit better. The dpreview image was only slightly better than the current smugmug setting, and the new versions of smugmug are just a bit better than it is. The low vs high bandwidth new versions aren't all that much different... I'd say they added quality of the high version is barely noticable.
I'd like to seriously echo John's idea... encode everything with the new smugmug low bandwidth settings, but allow customers to request images with artifacts be bumped to a lower compression rate. If you're concerned about folks going through and just requesting it on all their shots then I'm sure we could find enough volunteers in dgrinn to help you do some monitoring of the before after to see if it really mattered in the final image.
http://wall-art.smugmug.com/
Anywho, I'd certainly say proposed "low-end" solution is in itself a big improvement over the original. And I'd say for this particular shot the "high-end" solution is artifact free.
So, are your new settings the same regardless of the image or do they vary based on file size or some other metric (this was discussed earlier in the thread I think)?
And I don't mean to degrade this thread to "please reprocess my photo too!", but if the quality setting/quatization is in fact image dependent could you put up samples of this image:
http://kenandchristine.smugmug.com/photos/35525970-M.jpg
It's a really nightmare of artifacts around the bolts.
Hey, and once again major kudos for even spending time on this issue! Once again, smugmug's customer service rocks!
Ken
If you only knew...
For example, the camera manufacturer has a very tough problem: how to get images onto media fast without the need for a manly processor like your desktop has that would suck its small battery dry. So they make compromises like 2:1 chroma subsampling.
One of the toughest problems to solve is that byte size increases exponentially, not linearly, with with perceived quality once you get into the region of very high quality. On the image I posted above it's not a terrible problem because that image is realitively small, byte-wise. But when it's a photo of a jungle with lots of detail, the byte-size skyrockets.
I think we've reached a high confidence level of going live with the much-improved-over-where-we-are-now version, which should put us well ahead in quality from where Photo.net and PBase are now, and slightly ahead of Phil Askey's galleries on dpreview — without causing the forums to light up with SmugMug is slow messages.
Then we can assess what to do about the remaining few images of Red Ferraris or dark mountains against a saturated blue sky. John's suggestion is interesting and we have another possible trick up our sleeves, but we can see where we are after this improvement.
Many thanks for all your feedback and patience while we've been doing this research.
Reason I ask is the original shows significant artifacts and I'd like to understand where they came from:
http://kenandchristine.smugmug.com/photos/35525970-O.jpg
(Make sure your browser displays it full-sized so you have to scroll around to view it. Look at the upper end of the bolts where they are bright.)
Here's what it would look like with our new resize algorithm:
And if we bumped it up about 33% in size to the higher-quality setting, we'd get this:
For this image, bumping it up 33% in size is not so bad because it's a small image, byte-wise, as many images that show artifacts are. But not all are that way.
Anyway, any info you can give on how the original was captured and even better yet, if you can get me a copy, I'd be very grateful.
Uh oh...then it wasn't a good comparison at all?! Often artifacts are introduced after applying USM. Hope you did forget the USM just for the show-off here and not for testing the new compression method.
That also means the new smugmug method will produce even bigger files then what you showed here. Hope this isn't too much as the unsharped new low-end file is already 14kb bigger. How much would USM add?
Sebastian
SmugMug Support Hero
I can only imagine having done a little bit myself. The only thing worse is something temporal that can't be compared side by side like MP3 audio compression
Yes, but keep in mind 2:1 chroma subsampling makes a whole lot of sense for 99% of the cameras out there that use Bayer mosaics since they inherently have half as much chroma resolution as luminance. Of course the one camera that doesn't, the Sigma SD-9/SD-10 actually had their first RAW converter by default output JPEGs with 2:1 chroma subsampling!!! Whoops, no one could see their much touted chroma detail!
John's idea or whatever your trick is may be a good compromise if "smugmug is slow" starts to hit the wires.
That shot was from a Canon Rebel XT, sRGB, JPEG (I'll need to check if it was fine or normal compression). It was post processed with Neat Image for a little bit of noise reduction and some light photoshoping of a few hot pixels and probably levels. It was one of the first pictures I took with the camera and I didn't spend much time playing with it. It suffers some artifacts around the lightning and some posterization in places as well, but by the time it's resized to medium most of that should disappear. When I get home tonight I'll upload the unmolested original JPEG straight from the camera and post you a link here.
Both of your new resizes are a marked improvement, again the slightly higher quality one seems pretty much artifact free and the lower one is quite an improvement as well.
And again, thanks for all the great work you guys are doing!
Look better than this one, which went RAW => 2:1 using the camera superfine setting on a 20D?
(Those are original pixels you're seeing, no resizing or sharpening or anything like that on the JPEG.
BTW, we've been looking at output from lots of cameras. Sony seems to do as you said, save to a constant file size and let the compression vary.
So I uploaded the original from the camera that hasn't been beat with an ugly stick. Here's the link:
http://kenandchristine.smugmug.com/photos/51898578-O.jpg
It was in fact JPEG Normal. None the less shows almost no compression halos or posterization unlike the processed one. I think the processed one went through the free version of Neat Image which only outputs to JPEG and then had to have some noise pits removed in Photoshop. So three passes of JPEG, albeit at fairly high quality settings, but still it obviously added up! As expected the artifacts on the resized images appear to be about same as before.
Hope that helps. And maybe in all your copious free time when you're not implementing new features, running a business, answering all these posts on the forums, and biking you could write a blog write up about any interesting tidbits you discovered in your JPEG experiments. I recommed forgoing sleep, it really isn't that necessary
Ken
Hi,
I'm a little confused about those images you posted. (Took the links, converted to Original links and downloaded)
I ran them through my standard JPEG analysis toolkit and got some kind of strange results...
{ Start Of Frame
Type: Progressive DCT (Huffman)
Length: 17
Precision: 8
Height: 670
Width: 789
Component Count: 3
Component 1
Horizontal Frequency: 1
Vertical Frequency: 1
Quantization Table: 0
Component 2
Horizontal Frequency: 1
Vertical Frequency: 1
Quantization Table: 1
Component 3
Horizontal Frequency: 1
Vertical Frequency: 1
Quantization Table: 1
}
And
{ Start Of Frame
Type: Progressive DCT (Huffman)
Length: 17
Precision: 8
Height: 672
Width: 741
Component Count: 3
Component 1
Horizontal Frequency: 1
Vertical Frequency: 1
Quantization Table: 0
Component 2
Horizontal Frequency: 1
Vertical Frequency: 1
Quantization Table: 1
Component 3
Horizontal Frequency: 1
Vertical Frequency: 1
Quantization Table: 1
}
Both of them appear to be using 1:1 chroma subsampling....
I guess it could be that you've downsampled and then upsampled again? That might be OK, but I'd be a touch hesitant.
Futher it's always going to be a tad dangerous to compare the results of RAW and JPEG.
The only same way you could do this comparison that I can think of is take an image from RAW, save it as a PNG and JPG compress it with one version 2:1:1 and the other 1:1:1.
I wouldn't say that the images you posted are comparable as to my tired eyes they appear to have a different fixed colour (one's reddier). This wouldn't be due to subsampling as it uses the same DC bias architecture as non-subsampled images only a different sampling pattern.
I would say it's more likely due to a difference in the processing that was applied.
It's a mirky world to try and do experiments in....
Cheers,
Luke
SmugSoftware: www.smugtools.com