experiment results

posted: may 21, 2005.

from an experiment originally posted to my blog on may 13. different applications operating in different environments will interpret the exact same databent image file in vastly different ways. the experiment was conducted to collect data on how much the appearance of bent files might vary across applications & environments, as well as which enviroments create which variations. a control image was posted, a bent JPG of a bollywood vanilla coke ad, along with comparison images captured from various environemnts; users were invited to compare the control image to the captured images and submit a screenshot if it looked different on their system.

these files are presented in a somewhat different order than in the blog entry/experiment, to highlight similarities between some submitted images.

to see an animation rapidly shifting through all nine of these variations (about 350KB), click here.


bent image:

this is the actual bent JPG file; all others are screengrabs or unbent copies. this file does not open in Internet Explorer or Photoshop on Windows platforms, or in the following applications on Mac OS X platform: Adobe Photoshop CS, iPhoto, AppleWorks, Apple Final Cut Pro 4.5, Troikatronix Isadora, QuickTime Player v7, RealPlayer.


bollybend4.jpg:

bollybend4.jpg was originally captured using MSPaint on my computer at work (running Win2000; i don't know exact hardware specs), and looked the same using MSPaint on my old computer at home (800mhz athlon, WinXP SP1 upgraded from Win98). i didn't expect many people to report either this or the next image, but it actually did appear a few times.

actual results (number in parentheses is number of responses; if there's no number, that equals 1):


bollybend3b.jpg:

bollybend3b.jpg was captured using MSPaint on my new home computer (Athlon 64, WinXP SP1). like with the previous image, since i captured it in Paint, i didn't expect it to be a very common response, but it turned out to be somewhat common, even appearing in browsers a couple times.


bollybend3xp.jpg:

bollybend3xp was captured using Mozilla Firefox 1.0.3 on my new computer (Athlon 64, WinXP SP1). but oddly, this same application on the same computer later rendered to look like bollybend3-syn.jpg... and now looks it like this again. i cannot think of any significant changes that might have occurred to my system to cause this flip. maybe when system resources are low(er), it renders without the black or green bars at the bottom? this result was fairly common for users of Windows XP, but did not appear in any other OS.


bollybend3-syn.jpg:

bollybend3-syn.jpg was submitted by syntax, using Windows XP SP1 and Firefox 1.0.4. as i noted earlier, my new computer originally rendered like bollybend3xp, then it looked like bollybend3-syn, and now looks like bollybend3xp again. if i had to hypothesize here, i would guess that systems with lower resources (either because of older hardware or because memory is low for whatever reason) render like this, and systems with higher resources render like 3xp. if you compare this image to bollybend3xp, you see they are much the same, except this one is blocky where the 3xp is smooth, and 3xp has black and green bars at the bottom that are missing here.


bollybend3c.jpg:

this image was submitted by ken goudswaard. if you compare it to the two previous images (bollybend3xp and bollybend3-syn), you'll see that it looks pretty much like 3-syn, but it has a black-and-white bar at the bottom which is similar (but not identical) to the black bar at the bottom of 3xp. it does not have a green bar at the bottom like 3xp has. i cannot explain the difference between this version and the previous two: i don't have nearly enough data to even hypothesize.


bollybend3a.jpg:

bollybend3a.jpg was captured on my old home computer (800MHz Athlon, running WinXP SP1, upgraded from Win98). this variation (and the next two, which are pretty similar) was fairly common among older Windows systems a systems. this is in contrast to the previous three variations (the "pink" variations), which seem to be exclusive to Windows XP.


bollybend3mac3.jpg:

submitted by jack smiley. as you can guess from the filename, this was actually the third variation i received from a Mac OS X user, but i'm placing it here because it is most similar to the previous image (bollybend3a). this variation looks pretty much like bollybend3a except it lacks the green bar and the little blue & cyan dots at the bottom.


bollybend3mac2.jpg:

submitted by Anthony Simone, using Safari on Mac OS X 10.3.9. structurally, it seems to be identical to the previous image (bollybend3mac3), but the magenta and purple parts are darker, duller in hue.


bollybend3mac.jpg:

just when i thought all the submissions were going to be subtle variations on one or two general themes (as in the previous six images, which can be easily broken into two batches that look pretty much the same), i got this submission from Ian Page-Echols. it looks gloriously, wonderfully different, consisting of lots of cyans and green where the others were pink, magenta, and red (though those colors still appear here in limited quantities).


analysis

i went into this experiment with a lot of questions, and unfortunately i still can't answer most of them. as i said in my original blog entry:

you never really working directly with data; you work with the data as interpreted by the editing environment you use to access that data. there is at least one built-in layer of abstraction present at all times. with image-bending, you could say that the "real" bending happens not when you edit the data, but when that data is reinterpreted back into its original format. the same exact file will bend differently when opened in different applications on the same computer/OS, and will also look different when viewed in the same application but on a different computer/OS. this raises some fundamental questions: just how important is the "computer" part of the equation? will two machines running the same OS and application versions interpret a file in the same way? or do hardware variations, etc factor in? could it be that a bent volatile file will render differently on every computer you open it in? or does OS even factor in at all?

this question i can answer with a definite no: "could it be that a bent volatile file will render differently on every computer you open it in?" clearly, many computers will interpret the image in the same way. the result set suggests that there will be a few (or maybe several) basic variations on an image, though each major variation might also have a few subtle sub-variations. still, there is clearly a finite number of variations and most computers will fall into one of the basic ones. computers with similar setups will often (but not necessarily always) interpret the image similarly if not identically.

i can also clearly answer "no" to this question: "will two machines running the same OS and application versions interpret a file in the same way?" using MS Paint on two WinXP SP1 computers gave two different results. Firefox on WinXP delivers at least four different results. Firefox on Mac OS X delivers at least two results, and Safari delivers at least three. and it's even possible for the same application on the same computer to deliver more than one different result. to be sure, operating system and application are not the only two factors that determine how a bent image will look when it is opened.

so what is/are the other factors? i can think of a few possibilities, but actually determining the answer would require much further study, and probably a more extensive, far more controlled experiment than this one: an experiment with a large number of computers with known computer configurations and a broad set of operating systems and applications. such an experiemnt is well beyond my means.

possible factors include (and it's entirely possible i haven't thought of something important)

the last two might need some clarification, both for less-technical inclined readers and for especially-technical people (because i might not be using the jargon they would):

physical location of image data in memory/virtual memory or on hard drive hangs on the way data is physically stored and processed in computer systems (related to the previous item, filesystem configuration). computers tend to break data into "blocks" of various sizes (though those sizes are always a power of 2), and when the end of a file is reached, there might be some "empty" or "dead" space at the end of the final block. this dead space is generally not overwritten, and there could be old data still there, which could then be read into the application or otherwise work its way into the file. for more on this concept, you would do well to read up on the concept of buffer overflows.

as for differences in application set/OS compilation differences, etc, while some applications only need to be saved and/or decompressed for installation, some lower-level programs (and especially operating systems) need to be compiled into a machine-readable form that is customized for the hardward configuration of that particular computer. it is possible that differences in this compiled code (rather than or in addition to differences in the actual hardware of the computers themselves) could account for why some computers running what seem to be the same exact operating system and application version can still render the file differently.

while hardware configuration is the most obvious and (indeed) likely of these possible factors, it is definitely not the only factor. i can say this with certainty because i know it is possible for the same exact computer running the same applications can render (at least) two different results (see bollybend3xp and bollybend3-syn for details). while i have only documented this happening once so far (or twice depending how you look at it, as it has now "changed back"), there were definitely no changes in my hardware configuration. in fact the only factors listed above that could possibly explain this situation relate to memory: amount of available system memory, or the physical location of the image data within memory/on the hard drive.

answering conclusively which addictional factors contribute to how an image appears when rendered will require much further study. a broader, more controlled data set is needed, and a deeper understanding of the inner workings of the file format couldn't hurt.


conclusions


hypotheses


thanks

big thanks to everyone who responded!

and super extra big thanks to those who sent in screenshots (even if i didn't post them) and/or tried to open the file in applications other than their web browser. (if you sent me a screenshot and i didn't post it, it's because i considered it to be identical to one of the other screenshots above. it's not personal; it's just whoever submits that variation first.) for this, the biggest of all ups go out to:


comments

although this experiment is "finished" enough for me to have written up the results on this page, it's not necessarily closed. i welcome any comments or feedback, especially your screenshots if the bent file looks different than any of the above. if you want to continue the experiment, email me your results and screenshots. if you have comments or hypotheses, you're welcome to post comments on my blog here, but emailing me would probably be fastest. i can post your emailed comments and hypotheses here. also, if you already responded but i misinterpreted your results, please let me know so i can correct that.