# Should graphical-output challenges accept straight up image files by default?

I've often seen some questions tagged and that have some answer being image files, and they are often disagreements in the comments.

### examples:

Here's what comment section looks like (taken from the first example Swiss flag (PNG)):

### Note:

This question is not realy about SVG; while they are some disagreements, it seems like it's more accepted than bitmap files. This is probably due to the fact that it isn't binary, but XML, which is closer to code than a binary bitmap image is. So you can talk about it but this is not the main focus of the question.

I gathered the arguments for and against it from the comments and some of my research:

For Against
's description mentions a complex string, which shortest representation might be to print it literally. If a literal string is considered the "worst case solution" to a string based code-golf, a literal image file could be considered a "worst case solution" to an image based code-golf. - Sunday, in Carpet an airport PNG isn't a programming language, this isn't "drawing" anything, it's just the pre-drawn output file handed out on a platter. That makes a profoundly un-interesting submission. - Caleb, in Swiss flag (PNG)
Answering in non-programming languages is allowed on Do submissions have to be answered with a programming language? It could be compared to a compiled code (binary executable) which users seems to agree on the fact that they shouldn't be valid answers
It's kind of interesting that a generic commonly used image format like PNG can come close in size to the solutions using code tailor-made to this particular image - Anonymous, in Swiss flag (PNG) This could give an unfair advantage, especially on pictures with a small colo(u)r palette. While I haven't seen any submission that wins, most of them are pretty close to first place
• I'll write up a full answer later if someone doesn't beat me to it, but IMO, yes, this is fine. These are files that, when run through an "interpreter" (e.g. an image rending software), produces the appropriate output. I don't see how this isn't allowed. That said, I agree that it's not very interesting Feb 2 at 14:08
• Yea I agree for the most part but it can be interesting, especially if it is manually crafted. Unlike in code where you can make a procedure specific to the image, there you have to deal with general-purpose compression algorithm. Choosing the right palette/mode/features is part of the challenge (though compressors does that very well already and it's hard to do better by hands). And as for scripts, an explanation of the tools and tricks used always make the answer that much more interesting. Feb 2 at 15:14
• The link on your second against point is very old, and the community has shifted a lot. Standalone executable machine code programs (and even functions) are definitely allowed, and there is quite some activity in machine code golf - check out the search result for answers containing "machine code". Feb 4 at 8:13
• Also, handcrafting smaller zip files is (at least sometimes) an interesting area on its own (which is what Bubblegum users often do), and handcrafting images is IMO not so different. I don't see any unfair advantages with this (when a specific image format can be small, code generating it can be equally small), and code golf is mainly an intra-language competition after all. Feb 4 at 8:21
• As for the "unfair advantage" part, languages no longer (technically) compete against each other, so any concerns about it being unfair aren't relevant anymore. Feb 5 at 17:00
• These answers could easily be posted languages like /// which almost always just output the program's contents untouched, and then they'd be allowed. So banning them would seem very inconsistent (as well as, IMO, stupid) Feb 7 at 20:22