Editing Talk:2671: Rotation

<!--Please sign your posts with ~~~~ and don't delete this text. New comments should be added at the bottom.-->

For extra credit: Waht is the resolution of the phone screen? [[Special:Contributions/172.71.94.135|172.71.94.135]] 18:59, 12 September 2022 (UTC)

:IMHO 400px. Note SMALLER. -- [[User:Hkmaly|Hkmaly]] ([[User talk:Hkmaly|talk]]) 19:53, 12 September 2022 (UTC)

:From the image you can assume an 9/20 aspect ratio. Assuming each rotation reduces the image dimensions by that fraction after 9 rotations the dimensions would be reduced 1322 times so the resolution would be something between 1322x595 pixels (anything less than that would made it require 8 rotations or less) to 2935x1321 pixels (anything beyond that would require 10 rotations or more). 1600x720 or 2400x1080 maybe? Applying the same formula for the phone width and assuming atoms are typically around 100 picometers across then the phone width is close to 4.67 cm, too small, but maybe that's because rounding. In the other hand that formula does not work with Planck length at all: using it the phone width would be 1.69 meters. If you assume a width of 7 cm and 97 rotations you get pretty close to Planck length, but the comic says 101, not 97. Something is wrong with my calculations, I don't know what. [[Special:Contributions/162.158.63.160|162.158.63.160]] 21:03, 12 September 2022 (UTC)

::I took almost the reverse approach. Estimate phone height is 0.2 metres, Planck length is 1.6e-35 metres, ratio is 1.25e34, then take the 101th root. That would give about 2.176 as the reduction factor, which is also the screen aspect ratio. Then ask, "how far off might this be?" I assumed the 101th reduction is just barely smaller than the Planck length, it could be almost another reduction and still work. In other words, the aspect ratio is constrained to be between the 101th root and the 102nd root of the screen height in Planck units. With a 20 cm high screen, that puts the aspect ratio between 2.159 and 2.176 -- so the 9:20 aspect ratio (2.222) is completely ruled out. However <s>all the</s> [https://mediag.com/blog/popular-screen-resolutions-designing-for-all/ latest iPhone sizes] work just fine: 1792/828=2.164, <s>2436/1125=2.165, 2688/1242=2.164, 2436/1125=2.165</s>. I'll just guess that Randall has one of those. [[User:Mrob27|Mrob27]] ([[User talk:Mrob27|talk]]) 06:41, 13 September 2022 (UTC)
::Adding: I forgot to apply your method to constrain the width in pixels. 1125 and 1242 is ruled out because they are bigger than 2.159^9. In fact all the phone dimensions in that list I linked are ruled out except one: '''iPhone XR, 828x1792 pixels'''. [[User:Mrob27|Mrob27]] ([[User talk:Mrob27|talk]]) 07:01, 13 September 2022 (UTC)

This seems like it could actually be really cool. Can anyone do this and put the picture here as an example? Also, if possible, include an AI upscale of the one pixel. [[Special:Contributions/172.69.90.83|172.69.90.83]] 19:07, 12 September 2022 (UTC)

There's a '''minor''' counting error: instead of pointing to the 9th rotation, the 'nine rotations' statement points to the 8th as the first phone has no rotations.[[Special:Contributions/172.70.90.77|172.70.90.77]] 19:10, 12 September 2022 (UTC)
:That error is also on the 25 rotation, in both cases he counts the first screen with, and thus is one rotation behind. Also there are only 99 screens and thus 98 rotations so he missed the last 3 rotations, and screens, as there should have been 102 screens. --[[User:Kynde|Kynde]] ([[User talk:Kynde|talk]]) 09:06, 13 September 2022 (UTC)

Anyone getting a 404? Seems like the comic has disappeared. EDIT: ...aaaand it's back. [[Special:Contributions/172.70.100.54|172.70.100.54]] 19:34, 12 September 2022 (UTC)

Just putting https://www.codeguru.com/multimedia/rotate-a-bitmap-image/ here. [[Special:Contributions/172.69.134.131|172.69.134.131]] 20:12, 12 September 2022 (UTC)
: Microsoft C#, and not the original HAKMEM or Smalltalk 80? Please! You might as well be using C++: https://docs.microsoft.com/en-us/windows/win32/api/wingdi/nf-wingdi-plgblt [[Special:Contributions/162.158.166.173|162.158.166.173]] 20:21, 12 September 2022 (UTC)
:: I see your trivial software squabble, and raise one peer reviewed open access article citation: https://link.springer.com/article/10.1007/s10648-010-9144-5 [[Special:Contributions/172.69.22.5|172.69.22.5]] 22:03, 12 September 2022 (UTC)
:::I'll see your humorously ambiguous reference, and raise you a slightly more on-topic chapter encompassing both: https://journalspress.com/LJRHSS_Volume17/208_The-Geometric-Progression.pdf [[Special:Contributions/162.158.166.125|162.158.166.125]] 22:10, 12 September 2022 (UTC)

Tiktok [[Special:Contributions/108.162.246.68|108.162.246.68]] 20:40, 12 September 2022 (UTC)

Where would the rotated photograph bar be on [[1909: Digital Resource Lifespan]]? [[Special:Contributions/172.70.211.50|172.70.211.50]] 22:14, 12 September 2022 (UTC)

Doing this with an jpeg does the same. When rotating an image and saving it the lossy compression will lose more pixels. This makes it more blurry each step. [[Special:Contributions/162.158.203.38|162.158.203.38]] 22:41, 12 September 2022 (UTC)

:Who said it had to be something like JPEG? Since the information added at each step is known and finite, you could easily devise an iterated rotated image format that perfectly preserves the detail at every level down to the Planck length, and provide the possibility of zooming in on the screen all the way down. Of course you couldn't *display* all the detail at every level at the same time, but you could certainly store it in a hypothetical IRI (tm) format. [[Special:Contributions/172.70.162.147|172.70.162.147]] 16:00, 13 September 2022 (UTC)

I'm skeptical of "details at a sub-pixel level but that would have been significant if recorded at a greater resolution ''cannot'' emerge" -- this is subjective at a couple levels, and not as entirely impossible as opposed to just vaguely unlikely as the italics imply. [[Special:Contributions/172.69.22.119|172.69.22.119]] 00:43, 13 September 2022 (UTC)
:Well, after finding the context... Using pixel-multiplying techniques on low-res pixels (either direct, a poor imaging source, or upon previously downsampled high-res one) will either never recreate features 'lost' in the lower resolution or will ''always'' do (or at least always in a given non-zero proportion of pixel-patternations indistinguishable from the more justified one) even in situations where there was no justification for such an algorithmically-invoked artefact.
:But I suppose the most perfect fractal-compression, if it matches 'reality' well enough, could be rediscovered by the statistical pixel analysis which then extrapolates (or interpolates) all kinds of image details that were never even present even in the rawest of raw digital images but were always there to be discovered in the real-world had only the correct zoom level and framing been used.  And, if you've got something that can do that, I'll up the stakes with the Photo Enhancer/Inferrer thing that Rick Deckard used... It can even interpolate ''around corners''! [[Special:Contributions/172.71.178.65|172.71.178.65]] 02:33, 13 September 2022 (UTC)
The title text reminds me of the CSI TV show where a reflection of a faint image would be zoomed in on and the tiny text on the original could be read clearly.[[Special:Contributions/172.70.100.136|172.70.100.136]] 11:13, 13 September 2022 (UTC)
:After casually getting links to potentially follow up on 172.71.178.65, above, one of the interesting ones is: https://www.google.com/amp/s/scifiinterfaces.com/2020/04/29/deckards-photo-inspector/amp/ [[Special:Contributions/172.70.162.77|172.70.162.77]] 13:17, 13 September 2022 (UTC)
@@ Line 9: / Line 9: @@
 ::I took almost the reverse approach. Estimate phone height is 0.2 metres, Planck length is 1.6e-35 metres, ratio is 1.25e34, then take the 101th root. That would give about 2.176 as the reduction factor, which is also the screen aspect ratio. Then ask, "how far off might this be?" I assumed the 101th reduction is just barely smaller than the Planck length, it could be almost another reduction and still work. In other words, the aspect ratio is constrained to be between the 101th root and the 102nd root of the screen height in Planck units. With a 20 cm high screen, that puts the aspect ratio between 2.159 and 2.176 -- so the 9:20 aspect ratio (2.222) is completely ruled out. However <s>all the</s> [https://mediag.com/blog/popular-screen-resolutions-designing-for-all/ latest iPhone sizes] work just fine: 1792/828=2.164, <s>2436/1125=2.165, 2688/1242=2.164, 2436/1125=2.165</s>. I'll just guess that Randall has one of those. [[User:Mrob27|Mrob27]] ([[User talk:Mrob27|talk]]) 06:41, 13 September 2022 (UTC)
 ::Adding: I forgot to apply your method to constrain the width in pixels. 1125 and 1242 is ruled out because they are bigger than 2.159^9. In fact all the phone dimensions in that list I linked are ruled out except one: '''iPhone XR, 828x1792 pixels'''. [[User:Mrob27|Mrob27]] ([[User talk:Mrob27|talk]]) 07:01, 13 September 2022 (UTC)
-: This question assumes it is the same phone screen being used for every screenshot. That seems to be unlikely to me. Wouldn't the reason for taking a screenshot be to share it with others? Also, my Samsung phone saves screenshots as JPEG images, which are lossy. Does the iPhone save screenshots lossless? I would love to see the image degradation caused by so many repeated lossy saves! [[Special:Contributions/162.158.222.211|162.158.222.211]] 07:40, 15 September 2022 (UTC)
 This seems like it could actually be really cool. Can anyone do this and put the picture here as an example? Also, if possible, include an AI upscale of the one pixel. [[Special:Contributions/172.69.90.83|172.69.90.83]] 19:07, 12 September 2022 (UTC)
@@ Line 37: / Line 35: @@
 The title text reminds me of the CSI TV show where a reflection of a faint image would be zoomed in on and the tiny text on the original could be read clearly.[[Special:Contributions/172.70.100.136|172.70.100.136]] 11:13, 13 September 2022 (UTC)
 :After casually getting links to potentially follow up on 172.71.178.65, above, one of the interesting ones is: https://www.google.com/amp/s/scifiinterfaces.com/2020/04/29/deckards-photo-inspector/amp/ [[Special:Contributions/172.70.162.77|172.70.162.77]] 13:17, 13 September 2022 (UTC)
-I thought Randall was poking fun at all the dumb movies and TV programs that have the magic ability to “enhance” images and recover sub-pixel detail. It’s such an egregious plot point that you can recognize computer scientists by their groans in movie theaters. There’s even a TV Trope about it: https://tvtropes.org/pmwiki/pmwiki.php/Main/EnhanceButton — Also, the infinitely regressing image is called a ''Droste Image''. --[[User:Dúthomhas|Dúthomhas]] ([[User talk:Dúthomhas|talk]]) 08:08, 14 September 2022 (UTC)
-This comic reminds me a lot of [[1683: Digital Data]], which is also about degradation of images through re-posting screenshots. [[Special:Contributions/162.158.222.211|162.158.222.211]] 09:27, 14 September 2022 (UTC)
-: Absolutely no question, I spent half an hour looking for that one. Added; thanks! [[Special:Contributions/172.70.211.162|172.70.211.162]] 21:03, 14 September 2022 (UTC)
-" This is funny because the default resolution of contemporary camera phones can be too large to meet size requirements for e.g. mobile phone {{w|Multimedia Messaging Service}}, web file uploads, or email attachments, so one or two steps of this awkward procedure are sometimes necessary." - if true (presumedly screen-res and thus screencap-res is lower than the camera output, so after the image viewer is used to effectively downscale (maybe even pinch-zoom in and reframe the image) without using an actual image-editor/cropper app) then I don't see why two steps are necessary. The second scrcap step has the same number of pixels as the first... But, hey, it sounds like a kludge anyway. And I just thought I'd comment, don't mind me. (Can't see how "this is funny because", though. This is lacking all the humour of the almost-literal ''reductio ad absurdum'' already demonstrated and discussed. I don't think many times "This is funny because..." has been a useful thing to add to an Explanation, even if that's the intention of the site.)  [[Special:Contributions/172.71.178.65|172.71.178.65]] 10:57, 15 September 2022 (UTC)
-: What's more useful on this site than explaining the jokes? If you want to teach people how to fish, you should be on WikiHow. [[Special:Contributions/172.70.210.209|172.70.210.209]] 22:11, 16 September 2022 (UTC)
-::"This is funny because..." is redundant if true, I would say. The explanation can reveal the humour explicitly or by cluing the reader into it, but those four extra words add nothing. And subtract much when wrong. Interesting interpretations (like the above? Do people actually downscale by screenshotting?) may add to understanding, but not any humour. And then the statement is wrong, as it stands. That's without the "...or two steps", which I also think is just plain wrong, just never got around to editing out. [[Special:Contributions/172.70.90.61|172.70.90.61]] 00:30, 17 September 2022 (UTC)
-A similar case in real life: https://9gag.com/gag/aL2e3YM {{unsigned ip|198.41.231.180|13:41, 21 September 2022}}
-[https://www.explainxkcd.com/wiki/index.php?title=2671:_Rotation&oldid=315629 "(Why was '.' being used instead of '*' for multiplication?)"] – possibly because it's one of the various {{w|Multiplication#Notation and terminology|valid notations}} in use, although I might have used ''x•a'', or even just gone for ''xa'', myself. Just a matter of style choice, really, though there are indeed many different styles that some situations might (differently) stronly suggest. But it's perfectly understandable in context.  [[Special:Contributions/172.71.178.64|172.71.178.64]] 14:31, 19 June 2023 (UTC)