Click for larger...
I always felt that I left out one crucial experiment in my original post [riemannscut] on the matter of rotating and saving jpegs, and that was to have a control subject, to test against. With a little bit of coding in Processing, I was able to create both, in one environment, and in parallel.
To load images and use the standard rotate/transform methods in Processing is resource heavy, and I could only get to about 1300 saves before the whole thing blew up. There might better ways to do it that are already built-in, but 1200 operations were enough for my purposes. For the 180 degree comparison I just reordered the pixle array instead, which didn't have any such limitations.
As you can see, now more clearly, it is the process of rotating, that really does the damage. Straight saves just dull the red values a little, even after 25,000 saves. As Bill P. Godfrey [billpg.me.uk] commented on my original post, image degradation from rotating won't happen if the image dimensions are a multiple of 16. This is because jpeg sampling blocks are 16 pixels by 16 pixels, thus unaffected by re-orientation. The problem arises when you rotate an image and the new 16x16 sample block overlaps and truncates the earlier block, creating a new transition information. This is actually clearer to see along the edges of the "180 degree" version.
No comments:
Post a Comment