#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.
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.
#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.
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.
> 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.
"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.
> 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.
> 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.)
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.
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.
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
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.)
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?
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
Interestingly, if they are all* converted to ppm, only iii and ix are the same. Only part of the difference is comments. There are also differences in value encodings.
Also, if converted to bmp, only ii and vi are the same.
Edit: Converted to xpm, all are different. (When the embedded filenames are reconciled, ii and vi are again the same, the rest differ.)
31 comments
[ 4.2 ms ] story [ 74.8 ms ] threadHowever, 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.
Oh my. One should not so blithely confess that they can't see The Emperor's New Blue. Such a shame.
I chuckled.
But:
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.
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.
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.)
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
(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
Edit: https://en.wikipedia.org/wiki/Voice_of_Fire
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
Also, if converted to bmp, only ii and vi are the same.
Edit: Converted to xpm, all are different. (When the embedded filenames are reconciled, ii and vi are again the same, the rest differ.)
*Except v.gif, which is invalid.