Using Data URIs for image field values

[Scott_Sauyet]

@Springer

In fact, this application makes me wonder whether anyone has ever modified TiddlyWiki so that a particular named field (perhaps one whose name itself encodes the type of image — such as jpg or png) could store image data, the way the text field does for tiddlers whose type is image/png (or whatever)… (This would presumably be limited to one such image per tiddler. But that’s often exactly what’s needed!)

I wasn’t sure if you’re aware that you can easily store image data in arbitrary fields, using data uris. And there are a plethora of tools to convert images to data uris.

This shows a single tiddler that has three images included as field data.

Internal Images.json (88.6 KB)

title: Internal Images
asterisk: data:image/svg+xml,%3Csvg%20...
logo: data:image/png;base64,iVBORw0K...
venn: data:image/svg+xml,%3C%3Fxml%2...

!! These are SVG images, encoded as Data URIs in fields of this tiddler:

!!! Field `venn`
<$image source={{!!venn}} width="300px" />

!!! Field `asterisk`
<$image source={{!!asterisk}}  width="300px"/>

!! And this is a logo for SVG (ironically formatted as a PNG, then converted to a Data URI):

!!! Field `logo`:
<$image source={{!!logo}}  width="300px"/>

Of course this doesn’t match your single-field-for-images. But it’s probably quite a bit more flexible, and it’s already built-in.

[Springer]

Whoa! This is exactly what I was thinking was possible — but which I did not know was actual!

How is this not more widely known?? Or perhaps I’m the only one who did not know this!

You have widened my TiddlyWiki world, @Scott_Sauyet!

[Scott_Sauyet]

@Springer

How is this not more widely known??

Perhaps because the only advantage I see to it is that of packing more information into a single tiddler, which generally runs afoul of the Philosophy of Tiddlers. If you don’t need to pack the information together, then separate image tiddlers are more easily found and reused. However, as Charlie points out, there are times when packed individual tiddlers are quite useful.

[jerojasro]

This is really neat. Thanks for mentioning it.

[Springer]

@Scott_Sauyet

packing more information into a single tiddler, which generally runs afoul of the Philosophy of Tiddlers.

Yes…, although this “philosophy of tiddlers” norm is always contextual, right? Something should get its own tiddler if it is likely to be called upon for re-use, if it needs to be separately searchable, etc. In a wiki devoted to students, however, it would make sense to put the profile pic for a student into that tiddler — when the image “belongs” quite directly to a tiddler, it’s easier to transclude it as a tiddler-field pair than to try to remember whatever other naming scheme one might have for image-associated-with-x… and also one doesn’t have to think separately about whether dragging a tag-pill-worth of tiddlers might leave something behind that in some sense “belongs” to them.

At any rate, I’m looking forward to experimenting with this!

[TiddlyTweeter]

@Springer

this “philosophy of tiddlers” norm is always contextual, right?

Right.

It is worth saying why Tiddlers are “context dependent” …

… the underlying architecture of TW means (in extremis) a Tiddler could be …

— A word like “A”

or …

— An entire document like the biblical “Genesis”

The criterion for “appropriate” Tiddlerisation will rest upon the “FOR-ness” the maker is aspiring to.

And a magic in TW is the ability to use TW, in its own self-instance, to recursively chunk / combine Tiddlers using Tiddlers to produce Tiddlers. Ad infinitum.

QED

[TiddlyTweeter]

@Springer

In a wiki devoted to students, however, it would make sense to put the profile pic for a student into that tiddler — when the image “belongs” quite directly to a tiddler, it’s easier to transclude it as a tiddler-field pair than to try to remember whatever other naming scheme one might have for image-associated-with-x… and also one doesn’t have to think separately about whether dragging a tag-pill-worth of tiddlers might leave something behind that in some sense “belongs” to them.

Right.

There is your FOR-ness.
It makes complete sense to have one Tiddler per student profile. The “profile” is the “unit”.

However IF I had a student who was excellent at homework should that be signalled in another “award” Tiddler? Or IF Igor Igor was absent during your important penultimate tutorial—“new censure Tiddler or not?”

I guess this is partly about HOW to convert workable “administrative routines” into TW “fors?”

Interesting topical topic
TT

[Scott_Sauyet]

@Springer

[T]his “philosophy of tiddlers” norm is always contextual, right?

The more I think about this, the more I agree. I have done too much unnecessary work with naming schemes. And for several wikis where I use member images, so far they look like this:

title: Scott Sauyet
tags: Member
avatar: ScottSauyet.jpg
...

With a template that looks like this:

<% if [<currentTiddler>has[avatar]] %><div class="avatar"><$image source={{!!avatar}} /></div><% endif %>
<$transclude $tiddler="$:/_/my/templates/MemberInfo" $mode="block"/>
{{||$:/core/ui/ViewTemplate/body/default}}
<% if [<currentTiddler>has[avatar]] %><div style="clear: both"></div><% endif %>

While the rule that converts "Scott Sauyet" to "ScottSauyet.jpg" is easy enough to implement, and while currently that’s done outside TW as I generate these members from an external source, I really have no need for for the separate image tiddler. Every place it’s used now is in the context of the member tiddler. So inlining seems to harm nothing, and reduces my tiddler count.

The best thing is that I have to change no wiki code whatsoever to switch to these inlined images. I hadn’t thought about it when I posted the above, but <$image source={{!!avatar}}> works whether avatar is a data uri or the name of another tiddler.

When I get time, I will see if I can create a field editor that allows an image file upload or drop and stores it as a data uri. That would make this quite convenient.

[TiddlyTweeter]

@Scott_Sauyet

inlining [images] seems to harm nothing

Right.

Why should it?
We no longer have, normally, any bit of a bits problem (the largeness).

@Scott_Sauyet

I will see if I can create a field editor that allows an image file upload or drop and stores it as a data uri. That would make this quite convenient.

Yes. A good step for wo/mankind to ease the ways to a yearning obvious.

In the thnigy
TT

[CasperBooWisdom]

Aren’t data uris quite a bit larger than the original image? Probably wouldn’t be as much of an issue with nodejs tiddlywikis, but standalone wikis would probably not benefit from data uris, unless they are used sparingly.

[pmario]

@CasperBooWisdom

Aren’t data uris quite a bit larger than the original image?

They are basically double the size, because they have to be base64 encoded text.

There seems to be a size limit. I did some tests with a code found at StackOverflow

FF on windows 11 could deal with data up to ~30MByte and it started to report illegal strings a bit above that.

Edge seemed to handle ~50MByte well, and started to complain about something above 100MB. But I could not replicate that behaviour. So I’m not sure here.

So mobile browsers may have other limits. – But I did not test that

[TiddlyTweeter]

@CasperBooWisdom

standalone wikis would probably not benefit from data uris, unless they are used sparingly.

Right.

Though this is now, online, an empirical issue we can test.

Capacity for “huge” is interesting in that years ago we would never ever been a Clevor Trever to think we could do big.

Knock me down with a feather.

I do not know the Ultimate Limit on data URI in TW … let’s test now.

TT

[Scott_Sauyet]

@pmario

@CasperBooWisdom

Aren’t data uris quite a bit larger than the original image?

They are basically double the size, because they have to be base64 encoded text.

It’s less than double. In base64 encoding, there are four bytes for every three in the input, with a small amount of additional overhead for the data uri shell. This is reduced by not having a separate tiddler (plus a .meta tiddler) for them, but only a field.

So yes, they will be somewhat larger. But only for Node.js. Because when they are used in a single-file wiki, they need to be converted to text anyway, which (I’m assuming) also uses base64.

[TiddlyTweeter]

@Scott_Sauyet

It’s less than double. In base64 encoding, there are four bytes for every three in the input

Right.

Underneath this is, I think, whether, in current weather, we can survive well already in big?

I do think this topic v. Interesting.

I’d love to see some test results.

TT