quality parameter for take_screenshot

[L0laapk3]

When screenshots are taken using the take_screenshot function, and the save name ends with the jpg extension. factorio applies a default compression quality parameter to the screenshot. The default value is quite a strong compression value and is often not desired. Especially sharp contrast edges like inserters suffer.

I propose an extra 'quality' parameter that ranges from 0 to 100 like usual. This value could then be passed along to the JPG engine to set the quality treshold.
This value could also be passed to the PNG engine. PNG is a lossless format, but the value would reflect how much time the PNG engine spends to compress the image before it reaches the treshold.

Additionally, I also request a boolean 'subsampling' parameter to enable or disable JPG chroma subsampling (Im not sure if this is enabled by default in the JPG engine factorio uses but it usually is enabled by default.). This will help avoid the colors in the JPG image being much more "washed out"






Example: Both of these screenshots were taking with zoom=1 (small zoom values are also broken, but thats a topic for another day, probably nofix anyway). I have scaled them up by 800% (without interpolation) for ease of viewing.

JPG output:


PNG output:

[quyxkh]

I didn't know you could force .jpg screenshots, I take mine with the default `.png` at zoom two and run ImageMagick `convert -quality 20` on it with an inotifywait filter in background.

Code: Select all

prefix=${prefix-$HOME/.factorio}
snapsdir=${snapsdir-$prefix/script-output/snaps}
mkdir -p "$snapsdir"

inotifywait -rm "$snapsdir" -e close_write --format %w%f |
while read; do case "$REPLY" in
        *.png) convert -quality 20 "$REPLY" "${REPLY%.png}.jpg" ;;
esac; done & disown

That produces really nice screenshots—they're not noticeably distinguishable from the .png's—and gets a ~95% (that's not a typo) size reduction.

[bobingabout]

why would you even want to use a jpg for this kind of image?

[eradicator]

Yea, quality + disable chroma subsampling would definetly be nice additions .
______

why would you even want to use a jpg for this kind of image?

That produces really nice screenshots—they're not noticeably distinguishable from the .png's—and gets a ~95% (that's not a typo) size reduction.

[L0laapk3]

The problem is that png images take ages to generate, and then it would have to be converted after. The real question is, if you're going to host it online, why would you NOT use jpg images. Factoriomaps already hosts several TB of images. Without jpeg it would be a multiple of what it is now.

[eradicator]

The problem is that png images take ages to generate, and then it would have to be converted after.

False and false. O_o.

[L0laapk3]

The problem is that png images take ages to generate, and then it would have to be converted after.

False and false. O_o.

For sure, you dont want to serve/store PNG images, they are much much bigger. I actually tried to generate png images, but because of the sheer file size difference it was taking much longer.

[bobingabout]

It's been a while since I've run tests, but when you want a pixel perfect capture, PNG almost always results in a smaller file than a JPG, and when you understand the way these compressions work (PNG is essentially a bitmap image compressed, where a JPG is... put this mask(from a mask library) up with this colour, now overlay this one on top, then this one, then that one, until it's "Close enough" to the original. trying to get pixel perfect with this takes a lot of masks.), the more accurate you want an image, the more in favor PNG becomes. JPG is designed to be good with photorealism.

I would run a few tests, but I can't right now, because the most advanced piece of graphics editing software I currently have access to is the epic... Microsoft Paint. And that would be a flawed test, because not only are the JPG options limited, but it doesn't even save PNG files properly, and they end up bloated.

so, if you don't care about pixel perfect, then sure, use a JPG, but I still wonder why you would want to use it for a factorio screenshot.

[eradicator]

Ok. There seem to be a lot of misconceptions. Let's do this one by one:

@L0laapk3:

1. The time it takes to create a png is largely dependant on the compression factor and can range from "instant" to "minutes". With appropriate parameters you can make jpeg slower or faster just as easy.
2. A slow hard disk is not a problem of PNG. Any modern harddisk should be able to write 100Mb+/sec. So either you have a really slow disk, or you're trying to make a lot of pictures in rapid succession.
3. Jpegs are not "converted from png", the engine makes them directly from the raw image data. (Though upon reading your post again, maybe you meant you had to convert them manually because the game doesn't offer quality options?)

@bob

1. Jpeg doesn't use premade masks. It uses math. You can read it up on wiki. It mostly works by removing things from the image "that humans are bad at recognizing", and approximating the rest.
2. Jpeg by it's very nature can never be "pixel perfect". There's a special mode called "Lossless Jpeg" which can do this, but unsuprisingly loses all the size benefits of normal jpegs.
3. Png is always pixel perfect.
4. Because sharing a 5M jpeg is more feasible than sharing a 130M png. And because pictures of factories are essentially fotos. Ofc this doesn't affect you if you never wanted to share a picture of a large installation.
5. Png is best suited for images that have large areas of the same color (i.e. diagrams, graphs, text, etc). Jpeg is best used for images that have many small details that aren't important to the overall impression (i.e. photos, screenshots).
6. Fun fact: Compressing a bitmap of a factory with a modern compression algorythm (i.e. LZMA) actually results in a smaller file than PNG because PNG can not benefit from repeating patterns (like assemblers/furnaces, etc), but takes much longer to create. The sample i tried is 50% smaller with LZMA.

TL;DR:
Yea, i'm still all for exposing more compression options of the underlying library. Mostly to make Screenshot Hotkey better. :D

[bobingabout]

• Jpeg doesn't use premade masks. It uses math. You can read it up on wiki. It mostly works by removing things from the image "that humans are bad at recognizing", and approximating the rest.

I was refering to this: https://en.wikipedia.org/wiki/File:Dctjpeg.png
I'm not entirely up on how it works, but, yeah, that looks like patterns to me.

• Jpeg by it's very nature can never be "pixel perfect". There's a special mode called "Lossless Jpeg" which can do this, but unsuprisingly loses all the size benefits of normal jpegs.
• Png is always pixel perfect.
• Png is best suited for images that have large areas of the same color (i.e. diagrams, graphs, text, etc). Jpeg is best used for images that have many small details that aren't important to the overall impression (i.e. photos, screenshots).

You're telling me things I already know

• Because sharing a 5M jpeg is more feasible than sharing a 130M png. And because pictures of factories are essentially fotos. Ofc this doesn't affect you if you never wanted to share a picture of a large installation.
• Fun fact: Compressing a bitmap of a factory with a modern compression algorythm (i.e. LZMA) actually results in a smaller file than PNG because PNG can not benefit from repeating patterns (like assemblers/furnaces, etc), but takes much longer to create. The sample i tried is 50% smaller with LZMA.

1. That's one big PNG file.
2. PNG uses a specific compression, but I forgot what it is. It's been a while. ZLib perhaps? either way that's interesting.

[eradicator]

I was refering to this: https://en.wikipedia.org/wiki/File:Dctjpeg.png
I'm not entirely up on how it works, but, yeah, that looks like patterns to me.

Meh. Now i'm not so sure myself anymore. Also you just switched from "masks" to "patterns". So i'm writing it off as a semantic misunderstanding :P

• Jpeg by it's very nature can never be "pixel perfect". There's a special mode called "Lossless Jpeg" which can do this, but unsuprisingly loses all the size benefits of normal jpegs.

You're telling me things I already know :P

trying to get pixel perfect with this takes a lot of masks.

I do see a contradiction between "becomes pixel perfect with enough masks" and "never becomes pixel perfect" :p. I apologize for the unfortunate formatting of the post. Not all of the bulletin points were directly responding to something you said. I just felt like adding some additional facts.

1. That's one big PNG file.
2. PNG uses a specific compression, but I forgot what it is. It's been a while. ZLib perhaps? either way that's interesting.

1) That's the size of a screenshot 30% the size of the max resolution take_screenshot allows. As i said. It's of a semi-large production facilty, not of just one of the usual "tilable blueprint" style things. (I could up the jpeg here, but as spoilers don't currently work i don't :p).

2) PNG uses zip. Zlib is just the default implementation. But neither of that is relevant. The problem is that the format is block based, while LZMA can look for patterns over the whole file. It gets even more relevant when archiving large amounts of very similar pictures. Theoretically it should work with PNGs too if one could somehow force them to encode equal blocks exactly the same, but i haven't found a setting yet that does this. (Or at least that's my theory :p).

[bobingabout]

I remember actually using ZLib myself when I was programming, it was part of my save game format. Of course, the library literally just does the compression, then doesn't save any information about what it's done, so you have to define your own file format. I kept it simple, perhaps too simple. how many bytes is it? write that out first. then save the compressed data stream to the file after that. Done. At least, for single file mode.
For "Directory" mode, I think the table of contents was stored in the data stream itself, but I'm not sure. I would have to dig out my old project to be sure. either way it was probably just something simple like... number of files in the root directory, the name of the file, etc. I wrote it years ago, I would need to look it up.

but if ZLib is just a zip file, perhaps I could actually write the ability to read zip files.
The files however were also encrypted (every single byte was XOR'd with a random key byte. the key was saved in the file itself, you just needed to know where it was, a VERY crude encryption) but encryption was optional.

[Rseding91]

Ok. I added support to set quality when taking jpg screenshots for 0.17.

[L0laapk3]

Can you please also add the chroma subsampling flag while you're at it? It will help with the 'dull'ness of the images

[quyxkh]

Ok. I added support to set quality when taking jpg screenshots for 0.17.

Awesome, is your converter the imagemagick libs? The output from those is very good.

[posila]

GDI+ on Windows, stb_image everywhere else.

Just save it as BMP and compress it in something else.

[L0laapk3]

I do want to stress the importance of being able to disable the chroma subsampling. I believe disabling it matches with the technical term 4:4:4 in the jpg vocabulary, which means every color (and luminance) of every pixel gets saved in a 2 by 2 pixel block. Right now i believe it is only saving 1 color per 2x2 block.

[Rseding91]

I do want to stress the importance of being able to disable the chroma subsampling. I believe disabling it matches with the technical term 4:4:4 in the jpg vocabulary, which means every color (and luminance) of every pixel gets saved in a 2 by 2 pixel block. Right now i believe it is only saving 1 color per 2x2 block.

That's not supported using GDI+ and honestly just use PNG if you want to avoid the quality loss of the jpg format.

[eradicator]

I do want to stress the importance of being able to disable the chroma subsampling. I believe disabling it matches with the technical term 4:4:4 in the jpg vocabulary, which means every color (and luminance) of every pixel gets saved in a 2 by 2 pixel block. Right now i believe it is only saving 1 color per 2x2 block.

That's not supported using GDI+ and honestly just use PNG if you want to avoid the quality loss of the jpg format.

PNG is not end-user friendly. The whole point (at least to me) is being able to produce output that has acceptable size/quality so the end-user can directly upload the pictures taken (i.e. for my mod Screenshot Hotkey). The quality option is a great step in that direction. Thank you :).

[L0laapk3]

I do want to stress the importance of being able to disable the chroma subsampling. I believe disabling it matches with the technical term 4:4:4 in the jpg vocabulary, which means every color (and luminance) of every pixel gets saved in a 2 by 2 pixel block. Right now i believe it is only saving 1 color per 2x2 block.

That's not supported using GDI+ and honestly just use PNG if you want to avoid the quality loss of the jpg format.

JPG has a lot of benefits that PNG can't offer. Every self respecting JPG encoder should offer that option. It leads to ringing and loss of saturation. Its an optimalisation made for large, real life images where neighbouring pixels are very alike. Factorio is not like that at all and the resulting quality is unacceptable. There is still a lot of compression to be gained by using a lossy algorithm even with chroma subsampling disabled. Saying just use PNG is really not a solution.