Hi Mal,
Image processing is a highly advanced art and libraries that can handle it in a sophisticated way are huge in size. .. So I _don't_ think it will ever be convenient to add an image processing library to the TW core. ... To deal with imperfections would be a maintenance nightmare.
IMO working with TW and images always depends on the "target group" you want to reach.
Print target)
As soon as you want to print the content, you'll need "full" resolution, to get good results. ... So I would completely
exclude the "
print"
target group, if I would work with
embedded images. If you need to print something I think you will _have_ to work with "
external images".
Computer screen shots)
I still think, that
GIF is still a format to go here. GIF was very popular in 1990 to 2000 but it had a really BAD problem. LZW lossless compression, which GIF uses was patented. In 2004 the relevant
patents expired and since then GIF IMO is still a image format to go for screen-shots.
The nice thing is, it doesn't need any settings, when you save it. It always uses lossless compression. The only problem it has is the colour range it can handle. ... So if you have an image background ... forget about it. If you have a monochrome background (as I prefer) it's still a good format.
PNG was developed in the 2000th because of the GIF patent wars. IMO it's a bit better for handling modern colour palettes for screenshots, but it also has a bigger file size. _and_ it has a compression setting. :/ which has the potential to be set wrong by users.
With the screenshot I did create from my workspace the setting 9 creates a smaller image as setting 6. Where 9 is better quality. :/ The file size difference between PNG and GIF is about 150kByte. GIF (557k), PNG (703k c9)(710k c6 :/)
JPG should _NOT_ be used for computer screenshots. If you set quality to 100% it produces much bigger images as PNG. In my case 1016kByte instead of 703kByte for PNG
If 80% setting is used the jpg is 388kByte BUT it already produces very bad
JPG-artefacts with text. Which can be seen if the screen-shot is ever printed. It doesn't look professional. ... ever.
Images)
IMO JPEG is the format to go here. WEBP isn't supported by Apple, so chances are high, it produces problems, if embedded. JPG is already compressed and can _not_ be zipped. The second problem with images today is size.
Modern mobile pones easily create 5000x3000 pixel images. That's OK, because we want "good quality" and jpg always uses a "
lossy compression" format, even if set to 100%!
The problem is, that those images already need 4-7MByte, depending on the content details. ... So if we want to embed JPG we need to do some "pre-processing".
IMO googles
Squoosh-app is a nice way to play with different possibilities, that fits your needs. _but_ interested users should read
this info first, to know what's going on. WebApp is:
https://squoosh.app
Optimizing according to the usecase is nice ... BUT ... embedding images into TW converts them into
base64 encoding, which throws a lot of the optimizations out of the window by blowing it up by 100%
SVGs)
just some thoughts
have fun!
mario