6 ms·

The Treachery of Image Files

113 points by kick 6y ago

obiefernandez 6y ago
On the first one I was like, wha... but by the second and beyond I was getting a good chuckle. Great satire.
exikyut 6y ago
am do a confuse :(
Algomancer 6y ago
#0000FF has really seen a resurgence as of late, it is brilliant to see this medium executed by a master. However, where does one go from here? Does it become old hat? I hear some Avant-garde types are beginning to explore post-blue ideas. #333333 has a romantic bleakness to it that I would love to see explored.
- 082349872349872 6y ago
  By encoding hir works in the classical #0000FF but manipulating the alpha channel, the artist subverts expectations of the chromarchy in a personal journey of inner emigration, exploring the liminal space between transparency and obscurity.
- have_faith 6y ago
  #0000ff00, zero alpha blue, or as I've taken to calling it: post-blue. You cannot see the blue, but it exists in our shared conciousness and we know it is there. The opacity only adds to the tension when imagining the hidden pigment.
  - Igelau 6y ago
    > You cannot see the blue Oh my. One should not so blithely confess that they can't see The Emperor's New Blue. Such a shame.
- timpark 6y ago
  Many years ago, I made a music video called "Rhapsody in Bluescreen", which is exactly what it sounds like. I don't think it's online anywhere, but you can just listen to "Rhapsody in Blue" (now in the public domain this year) and imagine. I only used a small portion of it though, since it was just a short joke.
andreareina 6y ago
Context (?): https://en.m.wikipedia.org/wiki/The_Treachery_of_Images https://en.m.wikipedia.org/wiki/The_Treachery_of_Images
- totetsu 6y ago
  You cannot eat the pipe in the picture.
doubleunplussed 6y ago
> Despite frequent threats by the developers to remove them, the GIMP application had (at time of composition) some obscure and infrequently-used features permitting the creation and manipulation of image files. I chuckled.
LocalH 6y ago
Ceci n'est pas une bleu
eesmith 6y ago
"Macintosh Operating System X Mach-O Gnu’s Not Unix-based assembler" and "Gnu’s Not Unix Plotter" ? But: % as --version Apple LLVM version 10.0.1 (clang-1001.0.46.4) ... and gnuplot (famously) isn't part of the GNU project. I know, missing the point, but those jarred - was that deliberate by the artist, or a mistake? In either case, it seems to distract from the overall artistic intent.
- toyg 6y ago
  > was that deliberate by the artist, or a mistake? If you have to ask this, you don't know the art world. Artists don't make mistakes. The proper way to ask is "was this an attempt to communicate X, or simply an acceptance of Y?". If the latter, or if the answer contains "I was fascinated by the results" or "I found the result even more enlightening", you have your answer.
  - eesmith 6y ago
    I have been enlightened - thanks!
saagarjha 6y ago
> Preview cannot save files in the Graphics Interchange Format (GIF). It can, actually, you just need to hold done ⌥ while clicking on the file format picker. (Perhaps Apple thinks demonstrating the true capabilities of Core Image would blow the brains of Preview’s users.)
- kinard 6y ago
  Useful to know, shame I'll forget about it again in a few days time :)
  - KarlKode 6y ago
    Glue down your Option key and you're set!
- tinus_hn 6y ago
  Or perhaps Apple realized that GIF is a very poor format which only advantage is that it can auto play animations in browsers, which is not a scenario that Preview is useful for, so they tried pushing people to better formats and left GIF as a hidden option if you really want it.
browserface 6y ago
This is so cool. I like this guy's work. I want to see this stuff in a gallery. I mean that, I'm not being flippant or facetious.
jradd 6y ago
I wonder if there are any real programmers out there who have decoded GIF by hand. The IETF is clear that the header should be 6 7bit bytes (GIF##a), and the ends with `\x00\x3b`. without LZW, it should be trivial to append a frame to an image. its so hard... instead of downvoting me, does anyone know of a good/simple example of this in C/python or anything? array2gif[1] is pretty close. 1: https://github.com/tanyaschlusser/array2gif https://github.com/tanyaschlusser/array2gif
- 082349872349872 6y ago
  Don't know a simple example: when I did trivial encoding[1], it was by reading the spec. Dim memories for keeping it simple: choose an advantageous bit depth and palette so your non-lzw'd data can trivially be written out bytewise per pixel. If you can control width to avoid line padding, even better. (Yet dimmer, possibly false, memories: by taking advantage of LZW literals, I think it's possible to unencodedly write supposedly encoded blocks?) [1] 10-50 lines of python, depending upon fanciness, IIRC
canadian_tired 6y ago
This is brilliant. In some ways, it reminds me of the musings about "Voice of Fire". Mostly over my head, but somehow made me smile. Edit: https://en.wikipedia.org/wiki/Voice_of_Fire https://en.wikipedia.org/wiki/Voice_of_Fire
b6z 6y ago
/* XPM */ static char * treachery_xpm[] = { "10 10 1 1", " c #0000FF", " ", " ", " ", " ", " ", " ", " ", " ", " ", " "}; X Pixmap format. Save as treachery.xpm. (Made using Gimp, because it was faster than writing by hand. Sorry. But I have generated large pixel files programmatically in the X Bitmap format, which is similar but only one bit color information. Easier than writing a GIF.)
basseq 6y ago
I enjoyed the writing and exploration of different image creation formats. So novice question, but are the resulting GIFs actually different (and if so, how)? Or is this just different ways to generate identical output?
- yjftsjthsd-h 6y ago
  I saved the whole page in order to grab the images all at once, then used md5sum: [images_files] 0 $ md5sum * | sort 4a93faba1d6abc2f3c0fa4a925a23a4c viii.gif 672b8ee4b7e2893f209dd66eeb368744 ix.gif 7005d06133499ca4d1e6d1b265adea83 ii.gif 784f2d5bc7cb0cdce826fb656896c034 v.gif 8e39d526b119fabfacb259d53eb89140 vi.gif 9d2e88d7588d5e22c9d51d6b005034fb vii.gif 9f55b70b1564ab62faafbf37f311c5c0 iv.png b67f99e04dc8720d5846b818e86ecd39 style.css eb42e0f64ece46753a7aeba4fe3149a6 i.png f346c6fbe6fa659b6020c75c579084de iii.gif So I'd say no, they're different for some reason. Sizes vary a lot, too. Unfortunately I don't even know where to begin telling why.
  - em-bee 6y ago
    they probably have different metadata. if you convert all of them to png, do they still differ?
    - yjftsjthsd-h 6y ago
      There are already 2 pngs in that list, and they already have different md5s
      - em-bee 6y ago
        that could be caused by different compression levels or other artifacts in the metadata. my expectation was that in the conversion, metadata and possible artifacts that stem from different tools used to create the image would be normalized. in the sister reply diggernet choose even better formats than png as conversion targets, and answers the original question in this subthread
    - 6y ago
FriendlyNormie 6y ago
Absolutely retarded. Why would you share this here. All 94 morons who upvoted this should be banned.
jasomill 6y ago
For, um, future reference, here's a minimal[1] RGB TIFF version suitable for assembly with nasm -f bin: db 'II*',0 ; header dd ifd ; offset to IFD xres: dd 72,1 ; XResolution value yres: dd 72,1 ; YResolution value bps: dw 8,8,8 ; BitsPerSample value data: times 100 db 0,0,255 ; image data ifd: dw (next-ifd)/12 ; IFD entry count dw 256,4 ; ImageWidth tag, type dd 1 ; ImageWidth count dd 10 ; ImageWidth value dw 257,4 ; ImageLength tag, type dd 1 ; ImageLength count dd 10 ; ImageLength value dw 258,3 ; BitsPerSample tag, type dd 3 ; BitsPerSample count dd bps ; BitsPerSample offset dw 259,3 ; Compression tag, type dd 1 ; Compression count dw 1,0 ; Compression value, padding dw 262,4 ; PhotometricInterpretation tag, type dd 1 ; PhotometricInterpretation count dd 2 ; PhotometricInterpretation value dw 273,4 ; StripOffsets tag, type dd 1 ; StripOffsets count dd data ; StripOffsets value dw 277,3 ; SamplesPerPixel tag, type dd 1 ; SamplesPerPixel count dw 3,0 ; SamplesPerPixel value, padding dw 278,4 ; RowsPerStrip tag, type dd 1 ; RowsPerStrip count dd 10 ; RowsPerStrip value dw 279,4 ; StripByteCounts tag, type dd 1 ; StripByteCounts count dd ifd-data ; StripByteCounts value dw 282,5 ; XResolution tag, type dd 1 ; XResolution count dd xres ; XResolution offset dw 283,5 ; YResolution tag, type dd 1 ; YResolution count dd yres ; YResolution offset dw 296,3 ; ResolutionUnit tag, type dd 1 ; ResolutionUnit count dw 1,0 ; ResolutionUnit value, padding next: dd 0 ; next IFD offset [1] Source: page 24 of https://www.adobe.io/content/dam/udp/en/open/standards/tiff/TIFF6.pdf https://www.adobe.io/content/dam/udp/en/open/standards/tiff/...

113 points by kick 6y ago

obiefernandez 6y ago

On the first one I was like, wha... but by the second and beyond I was getting a good chuckle. Great satire.

exikyut 6y ago

am do a confuse :(

Algomancer 6y ago

#0000FF has really seen a resurgence as of late, it is brilliant to see this medium executed by a master. However, where does one go from here? Does it become old hat? I hear some Avant-garde types are beginning to explore post-blue ideas. #333333 has a romantic bleakness to it that I would love to see explored.

082349872349872 6y ago
By encoding hir works in the classical #0000FF but manipulating the alpha channel, the artist subverts expectations of the chromarchy in a personal journey of inner emigration, exploring the liminal space between transparency and obscurity.
have_faith 6y ago
#0000ff00, zero alpha blue, or as I've taken to calling it: post-blue. You cannot see the blue, but it exists in our shared conciousness and we know it is there. The opacity only adds to the tension when imagining the hidden pigment.
- Igelau 6y ago
  > You cannot see the blue Oh my. One should not so blithely confess that they can't see The Emperor's New Blue. Such a shame.
timpark 6y ago
Many years ago, I made a music video called "Rhapsody in Bluescreen", which is exactly what it sounds like. I don't think it's online anywhere, but you can just listen to "Rhapsody in Blue" (now in the public domain this year) and imagine. I only used a small portion of it though, since it was just a short joke.

andreareina 6y ago

Context (?): https://en.m.wikipedia.org/wiki/The_Treachery_of_Images https://en.m.wikipedia.org/wiki/The_Treachery_of_Images

totetsu 6y ago
You cannot eat the pipe in the picture.

doubleunplussed 6y ago

> Despite frequent threats by the developers to remove them, the GIMP application had (at time of composition) some obscure and infrequently-used features permitting the creation and manipulation of image files. I chuckled.

LocalH 6y ago

Ceci n'est pas une bleu

eesmith 6y ago

"Macintosh Operating System X Mach-O Gnu’s Not Unix-based assembler" and "Gnu’s Not Unix Plotter" ? But: % as --version Apple LLVM version 10.0.1 (clang-1001.0.46.4) ... and gnuplot (famously) isn't part of the GNU project. I know, missing the point, but those jarred - was that deliberate by the artist, or a mistake? In either case, it seems to distract from the overall artistic intent.

toyg 6y ago
> was that deliberate by the artist, or a mistake? If you have to ask this, you don't know the art world. Artists don't make mistakes. The proper way to ask is "was this an attempt to communicate X, or simply an acceptance of Y?". If the latter, or if the answer contains "I was fascinated by the results" or "I found the result even more enlightening", you have your answer.
- eesmith 6y ago
  I have been enlightened - thanks!

saagarjha 6y ago

> Preview cannot save files in the Graphics Interchange Format (GIF). It can, actually, you just need to hold done ⌥ while clicking on the file format picker. (Perhaps Apple thinks demonstrating the true capabilities of Core Image would blow the brains of Preview’s users.)

kinard 6y ago
Useful to know, shame I'll forget about it again in a few days time :)
- KarlKode 6y ago
  Glue down your Option key and you're set!
tinus_hn 6y ago
Or perhaps Apple realized that GIF is a very poor format which only advantage is that it can auto play animations in browsers, which is not a scenario that Preview is useful for, so they tried pushing people to better formats and left GIF as a hidden option if you really want it.

browserface 6y ago

This is so cool. I like this guy's work. I want to see this stuff in a gallery. I mean that, I'm not being flippant or facetious.

jradd 6y ago

I wonder if there are any real programmers out there who have decoded GIF by hand. The IETF is clear that the header should be 6 7bit bytes (GIF##a), and the ends with `\x00\x3b`. without LZW, it should be trivial to append a frame to an image. its so hard... instead of downvoting me, does anyone know of a good/simple example of this in C/python or anything? array2gif[1] is pretty close. 1: https://github.com/tanyaschlusser/array2gif https://github.com/tanyaschlusser/array2gif

082349872349872 6y ago
Don't know a simple example: when I did trivial encoding[1], it was by reading the spec. Dim memories for keeping it simple: choose an advantageous bit depth and palette so your non-lzw'd data can trivially be written out bytewise per pixel. If you can control width to avoid line padding, even better. (Yet dimmer, possibly false, memories: by taking advantage of LZW literals, I think it's possible to unencodedly write supposedly encoded blocks?) [1] 10-50 lines of python, depending upon fanciness, IIRC

canadian_tired 6y ago

This is brilliant. In some ways, it reminds me of the musings about "Voice of Fire". Mostly over my head, but somehow made me smile. Edit: https://en.wikipedia.org/wiki/Voice_of_Fire https://en.wikipedia.org/wiki/Voice_of_Fire

b6z 6y ago

/* XPM */ static char * treachery_xpm[] = { "10 10 1 1", " c #0000FF", " ", " ", " ", " ", " ", " ", " ", " ", " ", " "}; X Pixmap format. Save as treachery.xpm. (Made using Gimp, because it was faster than writing by hand. Sorry. But I have generated large pixel files programmatically in the X Bitmap format, which is similar but only one bit color information. Easier than writing a GIF.)

basseq 6y ago

I enjoyed the writing and exploration of different image creation formats. So novice question, but are the resulting GIFs actually different (and if so, how)? Or is this just different ways to generate identical output?

yjftsjthsd-h 6y ago
I saved the whole page in order to grab the images all at once, then used md5sum: [images_files] 0 $ md5sum * | sort 4a93faba1d6abc2f3c0fa4a925a23a4c viii.gif 672b8ee4b7e2893f209dd66eeb368744 ix.gif 7005d06133499ca4d1e6d1b265adea83 ii.gif 784f2d5bc7cb0cdce826fb656896c034 v.gif 8e39d526b119fabfacb259d53eb89140 vi.gif 9d2e88d7588d5e22c9d51d6b005034fb vii.gif 9f55b70b1564ab62faafbf37f311c5c0 iv.png b67f99e04dc8720d5846b818e86ecd39 style.css eb42e0f64ece46753a7aeba4fe3149a6 i.png f346c6fbe6fa659b6020c75c579084de iii.gif So I'd say no, they're different for some reason. Sizes vary a lot, too. Unfortunately I don't even know where to begin telling why.
- em-bee 6y ago
  they probably have different metadata. if you convert all of them to png, do they still differ?
  - yjftsjthsd-h 6y ago
    There are already 2 pngs in that list, and they already have different md5s
    - em-bee 6y ago
      that could be caused by different compression levels or other artifacts in the metadata. my expectation was that in the conversion, metadata and possible artifacts that stem from different tools used to create the image would be normalized. in the sister reply diggernet choose even better formats than png as conversion targets, and answers the original question in this subthread
  - 6y ago

FriendlyNormie 6y ago

Absolutely retarded. Why would you share this here. All 94 morons who upvoted this should be banned.

jasomill 6y ago

For, um, future reference, here's a minimal[1] RGB TIFF version suitable for assembly with nasm -f bin: db 'II*',0 ; header dd ifd ; offset to IFD xres: dd 72,1 ; XResolution value yres: dd 72,1 ; YResolution value bps: dw 8,8,8 ; BitsPerSample value data: times 100 db 0,0,255 ; image data ifd: dw (next-ifd)/12 ; IFD entry count dw 256,4 ; ImageWidth tag, type dd 1 ; ImageWidth count dd 10 ; ImageWidth value dw 257,4 ; ImageLength tag, type dd 1 ; ImageLength count dd 10 ; ImageLength value dw 258,3 ; BitsPerSample tag, type dd 3 ; BitsPerSample count dd bps ; BitsPerSample offset dw 259,3 ; Compression tag, type dd 1 ; Compression count dw 1,0 ; Compression value, padding dw 262,4 ; PhotometricInterpretation tag, type dd 1 ; PhotometricInterpretation count dd 2 ; PhotometricInterpretation value dw 273,4 ; StripOffsets tag, type dd 1 ; StripOffsets count dd data ; StripOffsets value dw 277,3 ; SamplesPerPixel tag, type dd 1 ; SamplesPerPixel count dw 3,0 ; SamplesPerPixel value, padding dw 278,4 ; RowsPerStrip tag, type dd 1 ; RowsPerStrip count dd 10 ; RowsPerStrip value dw 279,4 ; StripByteCounts tag, type dd 1 ; StripByteCounts count dd ifd-data ; StripByteCounts value dw 282,5 ; XResolution tag, type dd 1 ; XResolution count dd xres ; XResolution offset dw 283,5 ; YResolution tag, type dd 1 ; YResolution count dd yres ; YResolution offset dw 296,3 ; ResolutionUnit tag, type dd 1 ; ResolutionUnit count dw 1,0 ; ResolutionUnit value, padding next: dd 0 ; next IFD offset [1] Source: page 24 of https://www.adobe.io/content/dam/udp/en/open/standards/tiff/TIFF6.pdf https://www.adobe.io/content/dam/udp/en/open/standards/tiff/...