There's a new graphical language- how to score it?

Question

It was pointed out on chat- and I agree- that scoring Golfical programs as 1 byte per pixel (as has been done with other graphical languages) would probably not be entirely fair.

Therefore, let's discuss how to do it. Here are some possibilities:

1 byte for each pixel
3 bytes for each pixel
3 bytes for each non-white pixel (1)
19 bits for each pixel (2)
1 byte for each pixel, excluding red values 00-09, which are 2 bytes each (3)
1 byte for each pixel, excluding red values 00-09, which are 3 bytes each (3) (4)
1 byte for each non-white pixel, excluding red values 00-09, which are 3 bytes each (1) (3)
Other (5)

(1) White is a no-op

(2) Based on the approximate number of colors that actually do something at present

(3)The reason red values 00-09 are singled out for these is that they can encode a 16-bit integer argument in their blue and green values, and therefore all blue/green combinations for those red values are functional as opposed to just a very small subset (less than 1/1000)

(4) I personally think this is the most reasonable

(5) Please specify.

Answer 1

Score the number of bytes by the number of bytes

This really seems pretty straightforward. If your program is run as

$ mylang somefile

then the score of your answer should be the output of

$ wc -c somefile

that is, the number of bytes in the file.

If your language requires a command line switch to read raw bytes (RGBRGBRGB...), count that as an extra byte, just like any other language. (Or, if you make the default "detect filetype and interpret as raw RGB if nothing else is detected," you don't need a switch so there's no penalty.)

^{apparently I was ninja'd by Peter by 16 seconds...}

Answer 2

Score by transpiling into a suitable raw binary encoding

The github repo now provides an Encoder class for doing this. To encode a program, give the letter e as the first argument, the program filename as the second, and the name of a text file as the third. To decode a program, change the first argument to a d and reverse the second and third arguments.

It assumes that the width and the height of the image are both smaller than 4096 pixels.