Talk:2671: Rotation
For extra credit: Waht is the resolution of the phone screen? 172.71.94.135 18:59, 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. 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
all thelatest iPhone sizes work just fine: 1792/828=2.164,2436/1125=2.165, 2688/1242=2.164, 2436/1125=2.165. I'll just guess that Randall has one of those. 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. Mrob27 (talk) 07:01, 13 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
- 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! 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. 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.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. --Kynde (talk) 09:06, 13 September 2022 (UTC)
Anyone getting a 404? Seems like the comic has disappeared. EDIT: ...aaaand it's back. 172.70.100.54 19:34, 12 September 2022 (UTC)
Just putting https://www.codeguru.com/multimedia/rotate-a-bitmap-image/ here. 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 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 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 162.158.166.125 22:10, 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 172.69.22.5 22:03, 12 September 2022 (UTC)
Tiktok 108.162.246.68 20:40, 12 September 2022 (UTC)
Where would the rotated photograph bar be on 1909: Digital Resource Lifespan? 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. 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. 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. 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! 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.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/ 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. --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. 162.158.222.211 09:27, 14 September 2022 (UTC)
- Absolutely no question, I spent half an hour looking for that one. Added; thanks! 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 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.) 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. 172.70.210.209 22:11, 16 September 2022 (UTC)
