XPost: misc.phone.mobile.iphone, alt.comp.os.windows-10   
   From: mariasophia@comprehension.com   
      
   Herbert Kleebauer wrote:   
   >> That is why the 1x1 PPM -> PNG method is still a more precise and   
   >> platform-neutral way to generate a true solid-color wallpaper. It produces   
   >> a file that contains literally three bytes of color data and nothing else.   
   >   
   > You can also use the web browser to generate the 1 pixel file.   
   >   
   >    
   > width=100% border=0>   
   >   
   > Open the html file and save the picture. You can change the rgb   
   > value at the end of the line (%FF%80%40). There must be no line   
   > wrap in the long second line (or use: https://onlib.de/temp/2.html )   
      
   Hi Herbert,   
      
   Now *that* is clever!   
   It even solves that iOS can't easily run ImageMagick on the command line.   
      
   I smiled when I saw your value-added brilliant suggestion above, because   
   you're doing something "very Herbert", given you've solved many issues on   
   this newsgroup using clever tricks that most people have no clue about.   
      
   Least of all me!   
      
   What I love is you have the attitude of solving all problems, much like I   
   do, and Paul does, and Andy, and a few others, where we all have confidence   
   without insecurity, knowledge without ego as we're purposefully helpful.   
    A. You always find a workaround.   
    B. You generally prefers minimal tools.   
    C. You use brilliantly clever hacks (like embedding a BMP in a data URL).   
    D. You solve problems by hand-crafting binary structures.   
    E. You avoid dependencies when possible.   
    F. And, you write compact, technical examples.   
   Your problem-solving purposefully helpful additive style is distinctive.   
      
   Specifically, you're solving the problem that, for example,   
   1. ImageMagick is the most precise way to generate a solid-color PNG.   
   2. But it may not be installed (& platforms like iOS can't run it).   
      
   I appreciate that you added value in proposing two unique methods:   
    Method 1: The HTML-screenshot trick   
    Method 2: The embedded 1-pixel BMP trick   
      
   The HTML-screenshot trick:   
    a. Make an HTML file with .   
    b. Open it in a browser.   
    c. Take a screenshot.   
    d. Crop/zoom so only the color fills the screen.   
    e. Take another screenshot.   
   This results in a wallpaper-sized image that is visually a solid color.   
   Which   
    A. Works on any device (Android, iOS, Windows, Linux, macOS).   
    B. Requires no imaging tools.   
    C. Requires no command line.   
   Hence, it bypasses the ImageMagick limitation (e.g., on iOS).   
   However, a screenshot isn't as mathematically pure as a 1x1 pixel is.   
      
   You thought about the mathematical purity of the first method above,   
   and then you solved that with the mathematical purity of method 2.   
      
   The embedded-BMP trick is completely different in terms of craftsmanship.   
    a. Embed a 1x1 BMP file directly inside an HTML tag   
       
    b. Where the %EF%CD%AB at the end is the RGB value.   
    And the trailing %00 is the BMP padding byte Herbert included.   
      
   When you open the HTML file in a browser:   
    a. The browser decodes the BMP.   
    b. We can right-click > Save Image As.   
    c. We get a real 1×1 BMP file with the exact RGB values.   
      
   This does produce a mathematically pure 1x1 image (iF the browser saves it   
   without modification). Hence, this is more fingerprint resistant in that   
    A. It avoids ImageMagick.   
    B. It works on any device with a browser.   
    C. It produces a true 1x1 pixel file (not a screenshot).   
    D. It allows you to change the RGB value manually.   
      
   I haven't tested this for entropy, as it could be that browsers might   
    i. Convert BMP -> PNG on save   
    ii. Add metadata   
   iii. Change color space   
    iv. Re-encode the image   
    v. Upscale the image   
   So we'd need to check if the result is identical across platforms.   
      
   BTW, I test most solutions, where at first it confused me why Herbert   
   changed the order from RGB to BGR and why he padded with extra bytes.   
      
   It turns out Herbert's BMP trick works that way because BMP stores pixels   
   in BGR order (which is a legacy of Intel's little-endian byte layout)   
   and pads each row to a 4-byte boundary. Once I reversed ABCDEF to EF CD AB   
   and kept the padding byte, the color came out exactly as I had expected.   
      
   I study every poster to this newsgroup, where I respect that you are   
   offering alternative methods which don't require any image editors!   
      
   Thanks again for contributing as the more options we give people, the   
   better the reference becomes a useful source for solving the problem.   
   --   
   I'm never afraid to say what I don't know or what I do know as my ego isn't   
   tied to pretending otherwise, unlike most people, who are always afraid   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|