XPost: misc.phone.mobile.iphone, alt.comp.os.windows-10   
   From: mariasophia@comprehension.com   
      
   Herbert Kleebauer wrote:   
   >>   D. You solve problems by hand-crafting binary structures.   
   >   
   > Surely not. I used Irfanview to generate the 1 pixel picture and   
   > then copy&pasted the hex values of the file into the html file   
   > (adding the % by a global substitute in notepad).   
   >   
   >   
   >> The HTML-screenshot trick:   
   >   
   >> However, a screenshot isn't as mathematically pure as a 1x1 pixel is.   
   >   
   > If you zoom into a monochrome picture, it stays monochrome, anything   
   > else would be a software bug. Open the final picture in Irfanview,   
   > and replace the chosen rgb color by a different color. If all pixel   
   > changes the color, then there was only this one rgb color in the picture.   
      
   Hi Herbert,   
      
   Thanks for the clarification. Your kind advice helps me understand exactly   
   what you were demonstrating. I believe your point is that if the *source*   
   image is truly monochrome, then any screenshot of it will also be   
   monochrome, and zooming into it should never introduce new colors. In other   
   words, the pixel data remains uniform even if the file format around it   
   changes. That's a fair and important distinction.   
      
   What I was trying to highlight earlier is that there are two different   
   layers to "purity":   
      
   1. Pixel-level purity   
      As you said, if the original image contains only one RGB value, then   
      every pixel in the screenshot will also contain that same RGB value.   
      Zooming in won't reveal anything else. That part is guaranteed.   
      
   2. File-level purity   
      Even though the pixels remain uniform, the *saved file* may still   
      contain extra metadata, color-space tags, or compression artifacts   
      depending on the platform. That doesn't affect the color itself, but it   
      does mean the4re is a chance that the file is no longer the minimal   
      three-byte representation that a 1x1 BMP or PPM provides.   
      
   I'm happy you suggested these improvements because your method works on all   
   the platforms, as it doesn't require a tool such as ImageMagick to exist.   
      
   Your embedded-BMP trick neatly sidesteps that second issue, because the   
   browser is decoding a literal 1x1 BMP structure. As long as the browser   
   saves it without modification, the result is a mathematically exact   
   single-pixel file with only the BGR value and the required padding byte.   
      
   So your method is absolutely valid, and it's a clever way to generate a   
   pure 1x1 image on any device, including iOS, without needing ImageMagick   
   or any external tools. It's a great addition to the set of solutions.   
   --   
   The nice thing about Usenet is you get good ideas from everyone on it.   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)