However, imagemagick, graphicsmagick, gmic, and ffmpeg can’t open or convert it. GIMP can open it and some of the other glitched .sgi files in its GUI but opening/saving sometimes takes forever or they just won’t open at all. In theory converting would be quicker in GIMP on the command line as it’d be automatic and I could just leave the computer going for an hour or however long it needs. However, I’m using a beta of 2.99/3.0 and the usual commands (e.g. conversion - Using Gimp to batch convert images to another format in Windows - Super User) don’t seem to work.
Does anyone know of any open source desktop software (other than the ones mentioned above) that works on linux that can convert image files and maybe handle glitched .sgi image files?
(btw I’m aware that broken image files are sometimes, well, broken! But that’s the challenge of glitch art )
If you randomly change bytes in an image file (eg a JPEG or PNG of GIF or TIFF file), the file will probably no longer be a valid file.
Instead, you could write the pixel values to a binary file, so (for example) that file has 3 bytes for each pixel, with no compression. Randomizing those bytes will leave the binary file with 3 bytes for each pixel, so it can be converted back to a valid JPEG or PNG or whatever.
For example, using ImageMagick:
magick toes.jpg -depth 8 RGB:mybin.bin
toes.jpg has 267x233 pixels. The file mybin.bin contains 267*233*3 = 186633 bytes.
Now we can change random bytes in mybin.bin.
Then we can read the randomized file, and convert it back to a JPEG:
Probably won’t give the kind of effect OP is looking for.
To get that kind of effect you’d have to extract the compressed data stream for a lossless compressed PNG or TIFF, mangle the data stream, and repack it without clobbering the headers.
The artifacts in that file look like the results of clobbering lossless-compressed TIFF (and PNG lossless compression is similar) - calculate the differences between adjacent pixels, then compress that byte stream. Clobbering bytes in that stream will throw off the decompressor, but might cause it to still throw an error (too long/too short after decompression)
I tried out @snibgo’s method on an sgi file and indeed it doesn’t give the same effect as glitching an sgi file. The resultant glitches are more akin to glitching a .bmp file. A good new method which I’ll remember for another time but sadly not what I’m after at this time.
The example image is just a glitched .sgi file, no other post-processing.
In the end I reinstalled gimp 2.10 and ran the conversion script mentioned before. It throws a lot of errors when converting but it still converts. I guess once Gimp 3.0 is released I can revisit that conversion script and try to get it working again.
)