Uploading to Fission, resizing with Squoosh

[boris]

Here’s a screenshot of me uploading to my TWGroceries on Fission.

Photos are on my phone, transferred to my desktop.

Then I drag them into Squoosh, an installable PWA that can compress and resize images. 10x smaller than straight out of my phone, and then I reduce the size to get them half again as small.

Yes, this is a vote for integrating image resizing / optimization like Squoosh in some way.

I imagine the filter system could be used to good effect for this: if larger than X, then resize. And/or make thumbnails and so on.

Thanks @saqimtiaz – this is making me happy to have more great visuals on my food site.

This should be a better TWGroceries permaview of posts featuring images.

[saqimtiaz]

That is a very spiffy looking wiki Boris!

@boris

Yes, this is a vote for integrating image resizing / optimization like Squoosh in some way.

I imagine the filter system could be used to good effect for this: if larger than X, then resize. And/or make thumbnails and so on.

I agree that image processing/resizing capabilities in TiddlyWiki would add a lot of value, both to file uploads but for other usage as well.

Using the same filter based mechanism as the file uploads to determine what gets resized would indeed be a good fit. (For example: the filter for image resizing picks up all tiddlers over a certain size and marks them as resized, and then the upload filter uploads all tiddlers that are either resized or don’t need resizing.)

However, ideally we would want the image processing features to be available outside of uploads as well, so users who don’t use the file uploads feature could make use of it.

Interestingly one can think of image processing as a type of sync task as well. Implementing image processing in this manner would also be another step in the general direction that the core will likely move, i.e. multiple types of sync tasks configured and running at the same time. So while this would be significantly work than just hardcoding a image processing step into file uploads, the end result would both be more flexible and offer greater utility to users now, and would also inform and facilitate the future core work that we discussed on the community call yesterday.

It would be fantastic to get community support towards working on image processing through feedback and engagement here and through OpenCollective.

[saqimtiaz]

PS: Now you’ve made me hungry.

[pmario]

I’m in favour of optimizing images for “web-use” before upload. … BUT it has to be absolutely clear, that it is not a backup.

Scaling images is a destructive function and the quality after the safe is not the same as before.

So from my point of view there has to be a very clear difference between a “foto upload service” and a “foto store for web use”. For tiddlywiki I think it should be the later.

For Fission the “foto upload / backup service” can be a completely different product.

Eg: Fotos scaled and optimized for “web use” many times can not be used for “poster like” printouts anymore.

So as a user I would be really disappointed, if my backups are “compressed” without me understanding, what happened. Just to be informed at a later date that my fotos can not be used in the same way as prior to the upload. …

Just my thoughts.

[saqimtiaz]

@pmario

So from my point of view there has to be a very clear difference between a “foto upload service” and a “foto store for web use”. For tiddlywiki I think it should be the later.

I don’t see why it has to be either one or the other. I think what is important is that any resizing or compression has to be enabled by the user, with a message explaining the consequences.

This is another reason why it makes sense for image processing to be uncoupled from file uploading. If image processing/resizing is made available as an independent optional feature in TW, users can choose to configure their images to be resized before upload or not.

I can also imagine a workflow where a user wants to resize and keep thumbnails in the wiki as base64 tiddlers and upload the original files. While that isn’t a focus at the moment, for the long term the core solutions we arrive at need to be flexible enough to accommodate such use cases.

[boris]

@pmario

For Fission the “foto upload / backup service” can be a completely different product.

The reality is, unless someone were to make a “Photo Edition” for TiddlyWiki, what people want is fast loading images.

As a user, that’s my goal: to easily include photos. I’m not (currently) asking Fission or TW to do backup.

A photos edition — and the use case that Saq mentioned on the call, dropping a TW into a folder full of local images — are neat possibilities once TW handles photos better.

Saq’s next post has excellent points. Originals and thumbnails and many other different combinations are possible.

Actually, for me, this is all about workflow and ease of use. So for example, if I can set up a Fission feature to say, sync from Dropbox, which is synced to my photos on my phone, and then I can browse those photos on TW, and it generates a thumbnail on insert — that would be amazing!

No immediate plans around this, but these are the kind of things I’m thinking of for Fission: making people’s files and data more usable with any app.