Hello, PNG
da.vidbuchanan.co.uk
da.vidbuchanan.co.uk
Simple formats are like certain forms of .TGA and .BMP. A simple header and then the pixel data. No CRCs, no compression. Done. You can write an entire reader in 20-30 lines of code and a writer in other 20-30 lines of code as well. Both of those formats have options that can probably make them more work but if you're storing 24bit "True color" or 32 bit "true color + alpha" then they are way easier formats.
Of course they're not common formats so you're stuck with complex formats like PNG
I imagine in a couple of decades that "built-in features" of a programming environment will include Bayesian inference, GPT-like frameworks and graph databases, just as now Python, Ruby, Go, etc. include zlib by default, and Python even includes SQLite by default.
GIMP outputs it, which means you can make much any image embeddable into a C source.
E.g. this C implementation of Deflate adds 2 kB to a binary file: https://github.com/jibsen/tinf
As ASCII they can pass through email and UUNET and clipboards without BASE64 or equivalent. With flexible line breaks they can even be laid out so the monochrome ones look like the image they describe in a text editor.
See the examples at https://en.wikipedia.org/wiki/Netpbm#
fprintf(stdout, "P6\n%d %d\n255\n", WIDTH, HEIGHT);
fwrite(image, 1, WIDTH * HEIGHT * 3, stdout);
The simplicity of the format nicely limits the image output to the last 2 lines here.
for (int y = 0; y < HEIGHT; ++y)
for (int x = 0; x < WIDTH; ++x)
{
// ... compute r, g, and b one pixel at a time
printf("%c%c%c", r, g, b);
}
./myprog | convert - foo.png
./myprog | display -As sample example, a binary format could be as simple as
struct Header {
uint32 width;
uint32 height;
}
struct Image {
Header header;
uint8* data;
}
Image* readIMG(const char* filename) {
int fd = open(filename, ...)
Image* image = new Image();
read(fd, &image->header, sizeof(image->header));
size_t size = image->header.width * image->header.height * 4;
image->data = malloc(size);
read(fd, image->data, size);
close(fd);
return image;
}
Reading a PPM file is only simple if you already have something to read buffered strings and parse numbers etc... And it's slow and large, especially for todays files.
One time, I had to split a bunch of WAV files at precise intervals. I first tried ffmpeg, but its seeking algorithm was nowhere near accurate enough. I finally wrote a bash script that did the splitting much more accurately. All I had to do to find the byte offset from a timestamp in an raw PCM audio file is multiply the timestamp (in seconds) by the sample rate (in Hz) by the bit depth (in bytes) by the number of channels. The offset was then rounded up to the nearest multiple of the bit depth (in bytes) times the number of channels (this avoids inversions of the stereo channels at cut points).
Once I had the byte offset, I could use the head and tail commands to manipulate the audio streams to get perfectly cut audio files. I had to admire the simplicity of dealing with raw data.
(And OT, but interesting, regarding their acronyms:
P -> Q
N -> O
G->->I ...so close!)
The fun thing about DEFLATE is that compression is actually optional, since it supports a non-compressed block type, and you can generate a valid stream as a one-liner* (with maybe a couple of extra lines to implement the adler32 checksum which is part of zlib)
The CRCs are entirely dead weight today, but in general I'd say PNG was right in the sweet-spot of simplicity versus practical utility (and yes, you could do better with a clean-sheet design today, but convincing other people to use it would be a challenge).
*Edit: OK, maybe more than a one-liner, but it's not that bad https://gist.github.com/DavidBuchanan314/7559825adcf96dcddf0...
Edit 2: Actual zlib deflate oneliner, just for fun:
deflate=lambda d:b"\x78\x01"+b"".join(bytes([(i+0x8000)>=len(d)])+len(d[i:i+0x8000]).to_bytes(2,"little")+(len(d[i:i+0x8000])^0xffff).to_bytes(2,"little")+d[i:i+0x8000]for i in range(0,len(d),0x8000))+(((sum(d)+1)%65521)|(((len(d)+sum((len(d)-i)*c for i,c in enumerate(d)))%65521)<<16)).to_bytes(4,"big")Why?
The usual answer is that "checksumming should be part of the FS layer".
My usual retort to such an assertion is that filesystem checksums won't save you when the data given to the FS layer is already corrupted, due to bit flips in the writer process's memory. I personally have encountered data loss due to faulty RAM (admittedly non-ECC, thanks to Intel) when copying large amounts of data from one machine to another. You need end-to-end integrity checks. Period.
If you truly care about detecting bit-flips in a writer process's memory, that's a very niche use-case - and maybe you should wrap your files in PAR2 (or even just a .zip in store mode!).
99% of in-the-wild PNGs are checksummed or cryptographically signed at a layer above the file format (e.g. as part of a signed software package, or served over SSL).
Edit: Furthermore, the PNG image data is already checksummed as part of zlib (with the slightly weaker adler32 checksum), so the second layer of checksumming is mostly redundant.
On the other hand, why not? If you are dealing with files that are usually 200kB+, putting 4 or 16 bytes towards a checksum is not a big deal and can help in some unusual situations. Even if the decoder ignores it for speed, the cost is very low.
> The above benchmarks were made before SSE adler32/crc32 functions were added to the encoder. With 24bpp images and MSVC2022 the encoder is now around 15% faster.
I can't see the total percentage cost of checksums mentioned anywhere on the page, but we can infer that it's at least 15% of the overall CPU time, on platforms without accelerated checksum implementations.
Your specific number seem to come from an (old version of) an encoder that has super-optimized encode and not (yet) optimized CRC.
I spent a bunch of time optimising the code in fpnge (https://github.com/veluca93/fpnge), which is often notably faster than fpng (https://github.com/nigeltao/qoir/blob/5671f584dcf84ddb71e28d...), yet checksum time is basically negligible.
Having said that, the double-checksum aspect of PNG does feel unnecessary.
Arguably, the real reason CRC is useless is that most people don't care about the data integrity of their PNGs. Those who do care probably already have a better system of error detection, or maybe even correction.
deflate=lambda d:b"\x78\x01"+b"".join(bytes([(i+0x8000)>=len(d)])+len(d[i:i+0x8000]).to_bytes(2,"little")+(len(d[i:i+0x8000])^0xffff).to_bytes(2,"little")+d[i:i+0x8000]for i in range(0,len(d),0x8000))+(((sum(d)+1)%65521)|(((sum((len(d)-i)*c+1 for i,c in enumerate(d)))%65521)<<16)).to_bytes(4,"big")https://learn.microsoft.com/en-us/windows/win32/gdi/jpeg-and...
I have written TIFF readers.
Hold my ginger ale.
It's dead simple to emit. The P6 binary version is just a short header, followed by RGB pixel data, one byte per channel.
If you don't have a PNG encoder handy and need a quick "I just need to dump this image to disk to view it" for debugging, PPM is a great format due to how trivial it is. But it doesn't fit a lot of use cases (e.g., files are huge, because no compression).
TIFF, on the other hand is a "highest common denominator, lowest common denominator, what the hell, let's just throw every denominator -including uncommon ones- in there" format.
For example, you can have images with four (or more) color channels, of different bit lengths, and different gammas and image characteristics (I actually saw these, in early medical imaging). You can have multiple compression schemes, tile-based, or strip-based layout, etc. A lot of what informed early TIFF, was drum scanners and frame captures.
Writing TIFF: Easy.
Reading TIFF: Not so easy. We would usually "cop out," and restrict to just the image formats our stuff wrote.
At that point you're not dealing with 'images', but instead raster datasets: gridded data. So, you can combine byte t/f results with int16 classification codes, with float32 elevation data, with 4 channels of RGB+Near Infrared imagery data in uint32, plus some arbitrary number of gridded satellite data sources.
That can all be given lossless compression and assigned geotagging headers, and the format itself is (afaik) essentially open.
https://gdal.org/drivers/raster/gtiff.html is a good resource for anyone interested.
Edit: Plus, its magic number is 42, which is clearly great:
https://www.itu.int/itudoc/itu-t/com16/tiff-fx/docs/tiff6.pd...
"Bytes 2-3 An arbitrary but carefully chosen number (42) that further identifies the file as a TIFF file"
PPM is just one format; Netpbm is like a whole family. The "P6" is sort of the identifier that we're using that format — the other identifiers can identify other formats, like greyscale, or monochrome, or the pixel data is encoded in ASCII. The header is in text and permits more flexibility than it probably should. Channels greater than a byte are supported.
Writing a parser for the whole lot would be more complex. (I think TIFF would still beat it, though.) Just dumping RGB? Easy.
My go-to graphics format in the days of MCGA was PCX. Very easy to decode even with a small assembler routine.
(these are probably better alternatives: https://github.com/BinomialLLC/basis_universal, or http://www.radgametools.com/oodletexture.htm)
Lossless WEBP is smaller than optimized/crushed PNG files.
And I'd say that's quite a feat, which may explain the complexity of the format.
So WEBP may be complicated but if my OS supports it by default, where's the problem? It's not as if I needed to write another encoder/decoder myself.
The zlib format includes uncompressed* chunks, and CRC is only non-trivial if you're also trying to do it quickly, so a faux-zlib can be much, much smaller.
(I don't recall if I've done this with PNG specifically, but consider suitably crafted palettes for byte-per-pixel writing: quick-n-dirty image writers need not be much more complex than they would've been for netpbm)
* exercise: why is this true of any reasonable compression scheme?
Any? I wouldn't say that. If you took LZ4 and made it even simpler by removing uncompressed chunks, you would only have half a percent of overhead on random data. A thousandth of a percent if you tweaked how it represents large numbers.
If you wanted to go even simpler, here's an entire compression format described in one line:
one byte literal length, one byte match length, two bytes match offset, 0-255 literal bytes, repeat
https://github.com/a-e-k/canvas_ity/blob/f32fbb37e2fe7c0fcae...
I think it is pretty pragmatic and relatively simple, even though in hindsight some features were unnecessary. The CRC was originally a big feature, because back then filesystems didn't have checksums, people used unreliable disks, and FTPs with automatic DOS/Unix/Mac line ending conversions were mangling files.
PNG could be simpler now if it didn't support 1/2/4-bit depths, keyed 1-bit alpha for opaque modes, or interlacing. But these features were needed to compete with GIF on low-memory machines and slow modems.
Today, latest image formats also do this competition of ticking every checkbox to even worse degree by adding animation that is worse than any video format in the last 20 years, support all the obsolete analog video color spaces, redundant ICC color profiles alongside better built-in color spaces, etc. By modern standards PNG is super simple.
https://en.wikipedia.org/wiki/Multiple-image_Network_Graphic...
As for color spaces that is a case where things get worse before they get better. In the 1990s I remember the horror of making images for the web with Photoshop because inevitably Photoshop would try some kind of color correction that would have been appropriate for print output but it ensured that the colors were wrong every time on the screen.
Today I am seeing my high color gamut screen as a problem rather than a solution because I like making red-cyan anaglyph images and found out that Windows makes (16,176,16) when I asked for (0,180,0) because it wants to save my eyes from the laser pointer green of the monitor by desaturating it to something that looks like sRGB green to my eyes, but looking through 3d glasses it means the right channel blends into the left channel. To get the level of control I need for this application it turns out I need to make both sRGB and high gamut images and display the right one... Which is a product of the complexity of display technology and how it gets exposed to developers.
This was mostly due to overengineering on the part of the PNG committee. Why stop at animated PNGs, when we could support sound and interactivity! MNG is not a simple format, and the spec has MNG-LC ("low complexity") and MNG-VLC ("very low complexity") subsets, because the whole thing is too complex. Did you know you can embed JPEGs in MNGs? That it has synchronization points for sound, even though sound is still "coming at a later date"? That it allows pasting other images into the movie at arbitrary 2D transforms?
MNG's complexity is self-inflicted, because they second-system effect'd their way into features nobody wanted.
APNG, by contrast, is a series of PNG chunks with a couple extra fields on top for timing and control information.
yet just seeking in any random vpX / h26x / ... format is A PITA compared to trusty old gifs. it's simple, if you cannot display any random frame N in any random order in constant (and very close to zero) time it's not a good animation format
The reason you can seek to any frame is GIFs tend to be small, so your browser caches all the frames in memory.
OTOH every video format has keyframes, is more friendly to post-90s CPUs, and recent formats are parallelizable.
You have only been able to notice how "heavy" VPx is because lengths and resolutions used with this format are way beyond GIFs capabilities.
Try encoding a mere 10-minute 30fps 1080p video in a GIF, I dare you.
I don't know, because zlib makes concessions for every imaginable platform, has special optimizations for them, plus is in C which isn't particularly logic-dense.
It really doesn’t, even on Wii’s own curated corpus qoi is often >30% larger, and on worst case scenarios it can reach 4x.
Yes, it's not as good as PNG (as the sibling comments point out), but I view it more as an alternative to PPM (and maybe a BMP subset), as something that I can semi-quickly write an encoder/decoder if needed.
IMO, PNG is in a completely different level. Case in point, in the linked article the author mentions to not worry about the CRC implementation and "just use a lib"... If that's the case, why not just use a PNG lib?
One nice aspect of PNG is it gives a reader a bunch of data to validate the file before it even starts decoding image data. For instance a decoder can check for the magic bytes, the IHDR, and then the IEND chunk and reasonably guess the file is trying to be a PNG. The chunks also give you some metadata about the chunk to validate those before you even start decoding. There's a lot of chances to bail early on a corrupt file and avoid decode errors or exploits.
A format like TGA with a simplistic header and a blob of bytes is hard to try validating before you start decoding. A file extension or a MIME header don't tell you what the bytes actually are, only what some external system thinks they are.
>zlib is 23k lines
It's not needed to make a PNG reader/writer. zlib is massive overkill for only making a PNG reader or writer. Here's a tiny deflate/inflate code [2] under 1k lines (and could be much smaller if needed).
stb[0] has single headers of ~7k lines total including all of the formats PNG, JPG, BMP,. PSD, GIF, HDR, and PIC. Here's [1] a 3k lines single file PNG version with tons if #ifdefs for all sorts of platforms. Removing those and I'd not be surprised if you could not do it in ~1k lines (which I'd consider quite simple compared to most of todays' media formats).
>Of course they're not common formats so you're stuck with complex formats like PNG
BMP is super common and easy to use anywhere.
I use flat image files all the time for quick and dirty stuff. They quickly saturate disk speeds and networking speeds (say recording a few decent speed cameras), and I've found PNG compression to alleviate those saturate CPU speeds (some libs are super slow, some are vastly faster). I've many times made custom compression formats to balance these for high performance tools when neither things like BMPs or things like PNG would suffice.
[0] https://github.com/nothings/stb
[1] https://github.com/richgel999/fpng/blob/main/src/fpng.cpp
You can find my modern Java PNG library at: https://www.nayuki.io/page/png-library , https://github.com/nayuki/PNG-library
I also made a web-based tool to dissect PNG files and show all the fields and errors: https://www.nayuki.io/page/png-file-chunk-inspector
And my own "minimum-viable PNG writer" in ~140 lines of Java back in the year 2012: https://www.nayuki.io/page/dumb-png-output-java
Intriguingly unapologetic, but I think I'll stick to the PNG libraries that are mature enough to be both reliable and fast :-)
Regarding performance, I already lost the game before it started because I'm writing Java. If I wanted to squeeze CPU time, I would be writing C/C++/asm. So I decided to aim for conciseness and reliability instead of the endless stream of vulnerabilities.
https://www.cvedetails.com/product/111843/Zlib-Zlib.html?ven...
Kind of an odd thing to say, considering the existence and prevalence of libpng, which is written in C, and which uses setjmp() and longjmp() as part of its API. It's difficult to think of a more ill-advised and bonkers but extremely C-centric thing to do.
If so, then why aren't they fundamentally quite reasonable?
It's described here: http://www.libpng.org/pub/png/libpng-manual.txt
Crazy considering how much I use the property now.
Nonsense. The only reason to avoid PNG was IE’s gamma issues: IE6 did not support progressive transparency, so at worst you had full-color gifs.
You could actually make it work with non-standard DirectX filters, but it came with its own set of drawbacks and wasn't always a viable option.
That makes absolutely no sense, because there was no other format which could do progressive transparency on IE, and short of animation palletised PNG is superior to GIF. And for non-photographic full-color, PNG is generally much better than JPEG.
So avoiding PNG just gave you larger files or worse results for no gain.
So yes, you did use PNGs in some areas (illustrations etc.), but anything that would make you think "I'd have to use PNG to do that" meant "no-go because of IE". Which generally means avoiding PNGs.
When you add gamma issues on top of that, it was pretty rare to ever use PNGs for web designs if you cared about IE6.
Always a good insight to know how the basic concepts of these work without needing hours of learning deep specific knowledge that you'd only spend if you had to work directly with the format, like if you're writing a png lib.
From what I gather, the checksum is there for two reasons: 1) a check on archival integrity, based on experience with its usefulness in ZIP files, and 2) a way to check for download errors early, before reaching the end-of-file, which was more important in the slow and noisy modem era of the 1990s.
However, it's still possible for a change in chunk type to go undetected, for example, if "zTXt" were transformed to "xTXt" - a one bit change.
(I think it's also possible to construct a chunk such that if the length changed to just the right value then it could be interpreted as two chunks (with a smaller length) or be merged with later chunks. This requires getting the CRCs to align just right, and even harder to have just a single bit change.)
My belief is that removing the per-block CRC32 and putting the checksum in the IEND at the very end of the PNG data stream, and using a stronger checksum - even MD5 - would be more effective at archival integrity.
This of course can't happen now. Still, I regard it as a small bit of 1990s cruft.
When I developed my own format, for non-image data, I started with PNG as a guideline, then found that dealing with the checksum, even just to always generate a valid value, was a nuisance, with seemingly no good reason to justify its overhead.
I decided to drop the checksum, with a hand-waving argument that people should use other tools to detect and even repair file corruption, depending on their specific requirements.
This more generic and widespread family of formats is called "FourCC" for "four-character code" (https://en.wikipedia.org/wiki/FourCC).
I think the biggest mistake is that the checksum doesn't cover the type and length. If it did then I most of your concerns would be resolved. Although it may also make sense to have a full-file checksum in the IEND, but the only thing that could really detect is if whole chunks were perfectly dropped somehow, so not much added value, but again 4 bytes seems worth it.
I strongly suspect the input checksum won't be checked against the output data. Data ingestion might/should verify the chucksum, which is then thrown away.
This is especially true if working in a language with immutable strings, or using a functional-style immutable approach, where it's easier to know the payload doesn't change.
The checksum will be recomputed in egress.
As an alternative approach, the entire chunk might be stored in a single block, and either filtered or written as a single block, with no need to change anything, so no need to recompute the checksum.
In any case, if the developer thought this was appropriate, it's easy to add any sort of checksum or hash fingerprint as part of the chunk reader API, without it being present in the file.
> doesn't cover the type and length
While it could cover type, length is harder for some use cases. If you have a seekable output file, and don't have the ability to buffer all the data in memory, you might be able to process a segment at a time, write the crc, seek to the beginning of the chunk, then write the size.
Oh! I just realized that if the CRC were in the order typecode, data, length (which is different than the presentation order in the PNG data stream) then it would be possible to include the length in the CRC.
Though I don't think including the length would improve things as I think the failure modes are identical. Maybe?
My idea is that those 4 bytes could have been added to the CRC after processing the chunk tag and data. Here's an example:
class BlockWriter:
def __init__(self, output, chunk_type):
self.output = output
self._start = output.tell()
output.write(b"\0\0\0\0")
output.write(chunk_type)
self._crc = zlib.crc32(chunk_type)
self._chunk_length = 0
def write(self, data):
self.output.write(data)
self._crc = zlib.crc32(data, self._crc)
self._chunk_length += len(data)
def finish(self):
chunk_length_bytes = self._chunk_length.to_bytes(4, "big")
self._crc = zlib.crc32(chunk_length_bytes, self._crc) # !! NEW !!
crc_bytes = self._crc.to_bytes(4, "big")
self.output.write(crc_bytes)
# Go back and update the length
end = self.output.tell()
self.output.seek(self._start)
self.output.write(chunk_length_bytes)
self.output.seek(end)
writer = BlockWriter(png_f, b"IDAT")
writer.write(b"shrdlu")
writer.write(b"etaoin")
writer.finish()
'\x00\x00\x00\x0cIDATshrdluetaoin\xed?\xa6\xa4'
|--------------| four byte length = 12
|--| four byte character code 'IDAT'
|----------| = 12 bytes of payload
|------------| = four byte CRC
>>> zlib.crc32(b"IDAT" + b"shrdluetaoin" + b"\x00\x00\x00\x0c"
).to_bytes(4, "big")
b'\xed?\xa6\xa4'> A four-byte CRC (Cyclic Redundancy Code) calculated on the preceding bytes in the chunk, including the chunk type field and chunk data fields, but not including the length field. -- https://www.w3.org/TR/2003/REC-PNG-20031110/#5Chunk-layout
It has been many years since I looked into this matter, and I seem to have forgotten that detail.
Digging through my sent box, to png-mng-misc, I see that knew that back in 2012!
I also wrote that most of the tools I checked didn't verify the CRC:
> I tried a PNG with an IDAT chunk with an invalid CRC on various software on the my Mac. Unless I messed up my testing, the desktop, email preview, OmniGraffle, and Pixen.app all used the chunk with the invalid CRC.
My thread was "I would like some insight about PNG CRC and other experience" in case someone wants to dig it up.
I was able to make an PNG with a length field which, if changed, would produce another PNG showing a different result. At least one of the PNGs had an invalid checksum, but was still displayed.
EDIT: I found a public copy of the thread at https://png-mng-misc.narkive.com/YgUoUekk/i-would-like-some-... .
http://dalkescientific.com/xo.png is a PNG for an "O" with two IDAT blocks:
'IHDR' 13 (this is the chunk data size, excluding the 4 bytes of crc)
'xtra' 0
'IDAT' 1012 <-- this one is displayed
'IDAT' 1090 <-- this one is ignored
'IEND' 0
'IHDR' 13
'xtra' 1024 <-- the extra length contains what was the first IDAT
'IDAT' 1090 <-- this one is displayed
'IEND' 0
They differ only in byte offset 35, where one has a chr(0) and the other a chr(4):
% python -c 'print(set(enumerate(open("xo.png", "rb").read()))\
.symmetric_difference(\
set(enumerate(open("xo_bad.png", "rb").read()))))'
{(35, 0), (35, 4)}
It would require brute-forcing some chunk data so the CRCs would get a match.
I have some ideas on how to make it so there's only one valid (and different) IDAT block as well, but that's more than I can do in an evening.
What is this nonsense? You mean Java, right? C has always had unsigned types.
What exactly is implied here? Silly guard against overflow?
As another commenter points out, the real reason is about practicality - some languages like Java don't natively support unsigned ints.
Good specs pre-emptively mitigate implementation bugs.
In ASCII: "[\x89]PNG\r\n[SUB]\n"
Is there any information on the origin of these bytes? Why were they chosen like that?
So what's 0x89 at the start? It's outside the ASCII range.
maybe i calculated his bits wrong but over a hundred thousand bits for a picture in 300 x XXX ?
here's a (german) comic in 12,5 kb but i think they don't like hotlnking ^^
> //i.ibb.co/TPgSkF6/10126-DER-WARME-PULLI-EIN-AKT-FINAL-Mail.png
regards...
It’s a pretty good image format if one wants to quickly make something visual with code.
[0] https://en.m.wikipedia.org/wiki/Netpbm
[1] https://git.sr.ht/~benjcal/bc_libs/tree/main/item/bc_buffer....
I've never tried that variant, nor do I think I've seen files in the wild, so IDK how widely stuff supports it. If I have need for an alpha channel, I usually reach for a PNG encoder at that point…
I use it to make images with C locally and monitor them with a quick image viewer[0] I wrote
[0] https://git.sr.ht/~benjcal/bc_tools/tree/main/item/bc_viewer...
http://public-domain.advel.cz/
It also contains a simple version without actual compression which is actually a good alternative to BMP files as I was quite confused about the specifications for BMP so I rather wrote a PNG implementation.
It seems like operations with the format would be a bit faster if the pre-compression data would just be a framebuffer dump, instead of prefixing each row with a 1-byte "filter ID", possibly breaking data alignment.
So it is probably mandatory because only a tiny minority of images wouldn't use a filter. So it is better to just require it to avoid one more condition in the decoder.
Filtering as a separate preprocessing step allowed PNG to use off-the-shelf zlib for compression without needing to modify it.
This way rotating the image doesn't affect compression performance (unlike PNG).
https://en.wikipedia.org/wiki/Haar_wavelet#Haar_transform
It also has "meta-adaptive filters", which act similarly to PNG's filters except you get to encode a custom decision-tree that defines how pixels are filtered, as a function of their neighboring pixels
If you install the figlet (or toilet) tool and clone that font repo you can do a :
figlet -d ./figlet-fonts -f Banner3-D My text
'##::::'##:'##:::'##::::'########:'########:'##::::'##:'########:
###::'###:. ##:'##:::::... ##..:: ##.....::. ##::'##::... ##..::
####'####::. ####::::::::: ##:::: ##::::::::. ##'##:::::: ##::::
## ### ##:::. ##:::::::::: ##:::: ######:::::. ###::::::: ##::::
##. #: ##:::: ##:::::::::: ##:::: ##...:::::: ## ##:::::: ##::::
##:.:: ##:::: ##:::::::::: ##:::: ##:::::::: ##:. ##::::: ##::::
##:::: ##:::: ##:::::::::: ##:::: ########: ##:::. ##:::: ##::::
..:::::..:::::..:::::::::::..:::::........::..:::::..:::::..:::::
toilet -E list
Available export formats:
"caca": native libcaca format
"ansi": ANSI
"utf8": UTF-8 with ANSI escape codes
"utf8cr": UTF-8 with ANSI escape codes and MS-DOS \r
"html": HTML
"html3": backwards-compatible HTML
"bbfr": BBCode (French)
"irc": IRC with mIRC colours
"ps": PostScript document
"svg": SVG vector image
"tga": TGA image
"troff": troff source
Edit: added image formats
god i feel ancient.
It wasn't specified in the article but IIRC the casing of each letter in the chunk type has special meaning. So AAAA and aaaa have implicit meanings such as "required", "keep when processing" and I guess two other flags.
You had to use Microsoft's DirectX filtering CSS extensions to properly handle the alpha channel of True Color PNGs.
Not exactly, palletised png supports a full alpha channel which did not work with IE.
Though you had to work to get that as usually software would limit palletised output to GIF (if you didn’t outright have to create your pngs from gifs).