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 <https://tiddlywiki.com/prerelease/#ExternalImages>".
*Computer screen shots)*
I still think, that GIF <https://en.wikipedia.org/wiki/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 <https://en.wikipedia.org/wiki/Portable_Network_Graphics> 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 <https://en.wikipedia.org/wiki/Compression_artifact> 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
<https://en.wikipedia.org/wiki/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 <https://github.com/GoogleChromeLabs/squoosh> is a
nice way to play with different possibilities, that fits your needs. _but_
interested users should read this info
<https://developers.google.com/web/fundamentals/performance/optimizing-content-efficiency/automating-image-optimization>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
<https://en.wikipedia.org/wiki/Base64>, which throws a lot of the
optimizations out of the window by blowing it up by 100%
*SVGs)*
For SVGs optimization we can use: https://jakearchibald.github.io/svgomg/
just some thoughts
have fun!
mario
--
You received this message because you are subscribed to the Google Groups
"TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to tiddlywiki+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/tiddlywiki/0c2f48e3-75dd-450d-bdfa-73a634984f26%40googlegroups.com.
