On the practicality of drawing images

[Mat]

In another thread, Jermolene commented on a statement of mine:

[Mat] I assume that's because it is still somewhat iffy to work with images in TW, both to import or to draw them.

[Jermolene] Drawing an image is one click if one has the “new image” button in the sidebar, hard to imagine it being much simpler. In what way is it iffy to import images (besides the browser restrictions we’re discussing here)?

OK, I phrased it sloppily: It is iffy in practice for note taking. For example, it is of course trivial to type "I love TiddlyWiki" on paper as well as in a tiddler. It is also trivial, on paper, to write+draw "I ❤ TiddlyWiki" but this is typically impractical when making a tiddler note. A drawing from a touch pad is, in my experience, a rough sketch  so it is rarely useful outside of an immediate context e.g some explanation. So, in my experience, drawn images such as ❤ should ideally not have to be separate tiddlers as it really is no more separate than when we type the word "love" in a sentence.

That some scribbles are really part of the text is even more obvious when one considers annotations such as underlines or margin scribbles. (I made the transparent canvas proposal partly for this reason, i.e to be able to circumvent having to create a new tiddler and transclude it.) 

This is image-in-text problem is not unique to TW of course. I could not scribble a heart in this very google post either. 

<:-)

[TiddlyTweeter]

I'm not quite sure what you are asking.

I'll stick with the thread title.

TW is pretty boring for image editing/creation. To be expected. It is not Photoshop.

It is perfectly serviceable on touchscreen and systems with graphic pens so long as you zoom the edit area as big as possible.

But I suspect this is not what you want to talk about?

TT

[Mat]

@TT - of all the tiddlers you have, how many are drawings drawn in TW?

<:-)

[TonyM]

Mat,

I totally agree with you here. As a doodler and paper note taker from when I was young, I have a suite of ideographs, symbols, diagramming and annotations not to mention "free hand" drawing. I think the problem here is not a tiddlywiki, one but a universal one, the digital platforms have not come close to handling this ubiquitously yet. 

Personally I think just as you can use an external editor such as notepad++ to edit a browser text field, we should look to see if we can get an external editor to edit images and save back on close. this allows people to use the editor or drawing application of choice as it it were a feature in TiddlyWiki. This allows the graphical and leading edge innovation to be diverse and not our responsibility. "Horses for Courses" I say.

I find the free Inkscape, Gimp, snagit editor, and photoshop elements etc.. to have different strengths so I think an integration method is prefered. I think we can focus on TiddlyWikis unique strength, one of which is integration opportunities. My partner is an Illustrator expert and can generate image and vectors like SVG, I subscribe to an Icon service and have an Icon extractor. By the way the often maligned gif and animated gifs work in tiddlywiki.

Have you seen the new SVG editor?

Where I think we should develop tiddlywiki is in the integration, not just connections with editors but a way to easily import, imbed and layout multiple media types into a tiddler for presentation. We have html and browser standards on our side here.

Back to the real problem you voice, I believe we need a kind markup language for images so we can quickly "hand or command" draw composite images to represent simple and complex concepts. Currently Tiddlywiki is stronger on taking a concept represented as tiddler data and graphically representing it, but like you I would like to go directly from my head to a graphical representation (in TiddlyWiki).

Having invested considerable thought on this I believe our natural languages are weak on describing 2D and 3D images, and thus computers fail to oblige us. A Graphical markup language to describe such images and elements of images is overdue as is a way to convert hand drawn objects to computerise them "beyond the bitmap".

There are solutions, digital whiteboards, digitiser tablets, I even have some special pens, you clip a usb device to a piece of paper and as you draw it knows where the pen it on the page and digitises it, but converting it to reusable/movable elements is not mature.

This is a big subject, lets outsource but integrate.

Regards

Tony

[TiddlyTweeter]

Good question.

It has rarely been first choice. That said its okay for Quick Sketches ... 

[TiddlyTweeter]

The biggest issue with it is Ctrl+Z does not work. Make a mistake and you are fd.

On Sunday, 1 March 2020 00:20:55 UTC+1, Mat wrote:

[TiddlyTweeter]

Ciao TonyM

[TonyM]

A QUick snap and annotate with Snagit,

You can also extract text

1 Local
© Nighthawk M2 Information
Carrier
Telstra
Signal Strength
Poor
Battery
100%

From my Cellular router while the broadband is dead.

Regards

Tony

[Mark S.]

(Drawing with the "wrong" hand.)

[Mat]

@TT and @Mark

you're either teasing me or your missing my point. The put-on-the-fridge drawings are indeed simple to make in TW. But I'm talking about using the drawing feature as part of taking notes because this is what TW is for. The drawing feature is not well integrated into the real workflow of making notes in TW. It takes 5 seconds to create a tiddler reading "I love TiddlyWiki" but several minutes if you want to inject a little scribble inside the text. AND, again, note that this little "injected scribble" is probably so special that it doesn't fulfill tiddler criteria. It will not be reused and totally belonged to the context. It is a technological limitation that forces us to store it as a separate tiddler.

Still, mom says your drawings are  beautiful and they're already up on the fridge.

<:-)

[PMario]

Hi,

Firefox has a built in screen shot tool for websites. IrfanView is the general image and screenshot tool of my personal choice.

-m

[PMario]

Mozilla also created a free file sharing tool that can be used to share those screen shots.: https://support.mozilla.org/en-US/kb/send-files-anyone-securely-firefox-send

-m

[TonyM]

Mario,

I have similar. What would be nice is to trigger such an editor triggered inline like edit with external editor options on text fields.

I am sure its possible

Tony

[TonyM]

Mat,

I wonder if there were a way to have an image appear to be the background to a tiddler, then the wikitext rendering is overlayed, when in a special edit mode, rather than edit the background have a layer above it. This would allow tiddlers to have set backgrounds we could select then annotate over, saving a big part of the effort and bytes. Imagine a small hierarchy, or intersecting circles etc.. we then edit over them to name the circles etc..

Regards

[Ste Wilson]

I'm with you Mat!
I have never used tiddlywiki for sketching as i found it too.. Imprecise? I've been using Nebo on my android to do maths and sketches. Nebo then has a publish option and i can pull the sketches and the latex back into my tiddlywiki! Example Nebo page: https://www.nebo.app/page/84bf6db3-6830-403c-93ff-8a26e62ac63e

[Ste Wilson]

I take it back! Just had another look at the sketching tool and it would certainly do for the simple line drawings I'm sketching.
Thinking about it at least some of the reason i don't use it is the fairly constant refrain in here.. 'images WILL SLOW DOWN YOUR WIKI'.. So i followed the advice and serve svg's into my wiki from drop box. This coupled with the fact i can't DRAW svgs.. (no one wants to program pictures.. Do they?)
For more formal drawings i use ink scape and then send to my drop box..

[PMario]

On Sunday, March 1, 2020 at 7:30:32 AM UTC+1, Mat wrote:

.... AND, again, note that this little "injected scribble" is probably so special that it doesn't fulfill tiddler criteria. It will not be reused and totally belonged to the context. It is a technological limitation that forces us to store it as a separate tiddler.

I think, you are probably right. It is a technical challenge, even today, which imo is out of the scope of a browser based "mini software".

It's the nature of a "text"-editor to be designed to create text ... only.

Mixing and inline editing text and drawings once was introduced in Microsoft products in 1990. For those of us, which are old enough using those products, I just say: Object Linking and Embedding (OLE). .. Which, from my point of view, was the same as "shooting in your own foot".

Directly embedding 50+ screenshot images into a word ".doc" document, if it worked at all, only worked on the PC it was created. ..

Just to be sure. I'm talking about a time where computer main memory was measured in 1-4 MegaByte and a "write once" CD-ROM costed 10+€s .. per CD!

The main and cheap backup medium were many  3¹⁄₂" Floppy-disks with 1.44 MByte capacity. ...

Such an "embedding" document could easily add up to 100 MByte.

On the other hand linking images, as used by products like FrameMaker 3.0 or 4.0 created 1 file that was about 100 kByte in size + size of 50+ single file gif's.

IMO the linking concept, for these type of projects, had major advantages, over embedding. .. IMO that's still true.

Today's Office Suites if installed locally, need several 100s of giga-Byte disk space to accomplish mixing and inline editing different media types within "1" Suite, which consists of several apps.

So ... yes it is a technical challenge, which is probably a little bit out of TWs scope.

On the other hand TW can handle tiddler transclusions with ease!! See: https://tiddlywiki.com/#Images%20in%20WikiText so we should be happy to be able to use it that way.

IMO an "out of the box" TiddlyWiki is a multi-OS interchangeable notes platform, which allows sharing _and_ editing information.

If you want to share "Office" files and you want an "out of the box" experience, you better go with PDFs.

Just some thoughts.

have fun!

mario

[PMario]

On Sunday, March 1, 2020 at 11:59:20 AM UTC+1, Ste Wilson wrote:

...

.. So i followed the advice and serve svg's into my wiki from drop box. This coupled with the fact i can't DRAW svgs.. (no one wants to program pictures.. Do they?)

hmm, probably, if it's cool ;)  https://svgjs.com/docs/3.0/#go-crazy-with-animations

-m

[Ste Wilson]

1.44mb floppies!
I remember those... I ask students how much they think could fit on a floppy... The lowest they tend to go is about 1Gb!!!

[Ste Wilson]

[TiddlyTweeter]

Actually the topic is of great interest to me since I work a lot with the graphic arts.

I need think about it a bit.

TT

[TiddlyTweeter]

Mat wrote:

.... AND, again, note that this little "injected scribble" is probably so special that it doesn't fulfill tiddler criteria. It will not be reused and totally belonged to the context. It is a technological limitation that forces us to store it as a separate tiddler.

PMario: I think, you are probably right. It is a technical challenge, even today, which imo is out of the scope of a browser based "mini software".

Right. I think contextualising the issues in broader software function is a good way to come at this. 

It's the nature of a "text"-editor to be designed to create text ... only.

Mixing and inline editing text and drawings once was introduced in Microsoft products in 1990. For those of us, which are old enough using those products, I just say: Object Linking and Embedding (OLE). .. Which, from my point of view, was the same as "shooting in your own foot".

Directly embedding 50+ screenshot images into a word ".doc" document, if it worked at all, only worked on the PC it was created. ..

Just to be sure. I'm talking about a time where computer main memory was measured in 1-4 MegaByte and a "write once" CD-ROM costed 10+€s .. per CD!

The main and cheap backup medium were many  3¹⁄₂" Floppy-disks with 1.44 MByte capacity. ...

Such an "embedding" document could easily add up to 100 MByte.

On the other hand linking images, as used by products like FrameMaker 3.0 or 4.0 created 1 file that was about 100 kByte in size + size of 50+ single file gif's.

IMO the linking concept, for these type of projects, had major advantages, over embedding. .. IMO that's still true.

Sort of. In professional tools like InDesign you can both Embed OR Link. If you embed bit images in a document it is at the highest resolution. Documents can become huge but are fully portable. If you link bit images then you typically set the render resolution first to "draft" resolution so you can work without having to render the full version. On final output you render the linked images into an output file, typically PDF, at the resolution of the destination media. Generally very high for high quality print, low for standard web, medium for modern high res screens.

 

So ... yes it is a technical challenge, which is probably a little bit out of TWs scope. 

Right. But the issue of "placement" (I.e. how the transclusions could be manipulated) is probably something that could be approached in TW. 

On the other hand TW can handle tiddler transclusions with ease!! See: https://tiddlywiki.com/#Images%20in%20WikiText so we should be happy to be able to use it that way.

Yes. 

I'll comment more later when I thought a bit more about it.

TT

[Mat]

Good news. Well, kind of.

I just realized that the TW tool I'm working on will much simplify this. I think only a few people have had a peek at it so far but you may know what I'm talking about. Hopefully I can have something officially released within a few weeks.

<:-)

[Ste Wilson]

Is it a ui issue? Improve the work flow of expediting functionality? If a button on the edit toolbar created the Transcluded image tiddler seamlessly and allowed drawing directly in the text tiddler so you never had to leave the tiddler you were working on? Or perhaps opened the sketch tiddler at the side or something so you had a 'sketch space'? Later hovering over the image could bring an edit/ view button into view like the tabs one.

[TiddlyTweeter]

TonyM wrote:

... I think the problem here is not a tiddlywiki, one but a universal one, the digital platforms have not come close to handling this ubiquitously yet. 

Personally I think just as you can use an external editor such as notepad++ to edit a browser text field, we should look to see if we can get an external editor to edit images and save back on close. this allows people to use the editor or drawing application of choice as it it were a feature in TiddlyWiki. This allows the graphical and leading edge innovation to be diverse and not our responsibility. "Horses for Courses" I say.

Being able to invoke an external graphics editor should be doable? Though I think Browsers natively are not as easy for this as they once were? In FF, for instance, with the switch to the new architecture, a swathe of tools for plugging into the "textarea" died.

Having invested considerable thought on this I believe our natural languages are weak on describing 2D and 3D images, and thus computers fail to oblige us.

Actually there were also great tools that came and went because the design metaphors bridging visual and textual components did not catch on.

The technologies behind them are alive and well,  mainly within "image language". A simple example is Google Reverse Image Search.

 

A Graphical markup language to describe such images and elements of images is overdue as is a way to convert hand drawn objects to computerise them "beyond the bitmap".

Actually they exist. Images have held meta-data for a long time and the schema are extensible. The issue is the specific "Bridge" needed in the document between image and text. Vector graphics are far superior here in that their conceptual structure is a language of types already.

 

Reflections

TT

[TiddlyTweeter]

Mat & TonyM

Tony gave a nice simple example .... 

These kinds of tool, I believe, just use a simple overlay.

Mat kindly showed me a draft tool demonstrating the possibility of exactly this kind of thing in TW a few weeks ago.

Best wishes

TT

[TiddlyTweeter]

Ste Wilson wrote:

... the fact i can't DRAW svgs.. (no one wants to program pictures.. Do they?)

Right. The drawing language of any SVG  other than very simple shapes is completely unworkable to hand code.

Tweaking (carefully), yes. Writing from scratch, no.

For more formal drawings i use ink scape ...

Right. 

One issue arising, Tony also pointed to, was whether we could interface with an external image editor.

IF Inkscape could run on a TW edit box might you use it?

TT

[Ste Wilson]

Inkscape in tiddlywiki! I'd use that. Perhaps more realistic or something to think about... https://editor.method.ac/

[TonyM]

TT,

A Graphical markup language to describe such images and elements of images is overdue as is a way to convert hand drawn objects to computerise them "beyond the bitmap".

Actually they exist. Images have held meta-data for a long time and the schema are extensible. The issue is the specific "Bridge" needed in the document between image and text. Vector graphics are far superior here in that their conceptual structure is a language of types already.

Actually I am thinking of something a little more innovative.  There was a google project that test something a bit like what I am thinking.

An example would to be able to describe a table, as a flat surface 3m by 5m (5cm thick) standing on 4 legs 1m high and 20cm diameter round. Each leg in 30cm from each corner.

The above is enough for us humans to do a lot with, picture in our minds eye, but most computers will say "I do not compute".

Regards

Tony

[TonyM]

Vector graphics can be very low size compared to bitmaps.

[TiddlyTweeter]

TonyM wrote:

A Graphical markup language to describe such images and elements of images is overdue as is a way to convert hand drawn objects to computerise them "beyond the bitmap".

Actually they exist. Images have held meta-data for a long time and the schema are extensible. The issue is the specific "Bridge" needed in the document between image and text. Vector graphics are far superior here in that their conceptual structure is a language of types already.

Actually I am thinking of something a little more innovative.  There was a google project that test something a bit like what I am thinking.

An example would to be able to describe a table, as a flat surface 3m by 5m (5cm thick) standing on 4 legs 1m high and 20cm diameter round. Each leg in 30cm from each corner.

Right. So you have a formal description that a user ADDS, right? Image EXIF fields will take that for major bitmap formats.

IF you mean that some software works out its an image of a table, well Nice, but I can't see that working in TW anytime soon :-)

TT

[TiddlyTweeter]

Ste Wilson wrote:

Inkscape in tiddlywiki! I'd use that. Perhaps more realistic or something to think about... https://editor.method.ac/

You mean embedding an online editor in the TW editor?

TT 

[TiddlyTweeter]

Okay Mat

I got to point I can say a bit.

Regarding the issue of being able to "overlay" (I think you are working on something like that?). Seems absolutely right to me.

All decent image editors work with LAYERS. You have a base layer that you rarely change once done. Then you add layers as needed.

Layers can be filters for things like opacity. Or for "masking" (hiding etc). Or new drawn parts. You get the idea.

I think the structure of TW could be well suited to this kind of approach. 

For instance, as I saw in an experiment of yours, I think, you overlaid a graphic Tiddler over another Tiddler.

In other words you "layered".

I can foresee some issues since I assume you'd use a bitmap Format? Scaling the two tiddlers & size may be an issue sometimes?

Vector (SVG) would be lightweight and never have scaling issues, but TW does not support WYSIWYG svg editing.

That was my main comment. Probably redundant as you seem already there! :-)

Best wishes

Josiah

[Mat]

TiddlyTweeter wrote:

Regarding the issue of being able to "overlay" (I think you are working on something like that?).

Actually, that overlay thing is not what I'm talking about and is not something I'm working on. (The thing I'm referring to is what I posted about privately to you some weeks back.) But, regarding layers, I'm not sure it is an appropriate solution for integrating images in the text because if you rearrange the text, you'll want your image to move accordingly. A layer image would stay fixed, I assume.

Now, layers would be really neat for use cases like the above referenced overlay thing. I created it after some one here described he was an MD and wanted to doodle on top of x-ray images or something similar. This is an interesting use case but what I'm after in my OP here is the much more basic case to just be able to easily type and doodle in the one and same tiddler as you make notes.

<:-)

[TonyM]

Mat/TT,

I will keep the details under my hat until I develop the idea in my head a little but I am playing with an idea I call Ghost tiddlers, since Shadows is a term already taken. I am raising it now because it sounds it could for part of these discussions with image layers. My terminology is all mixed up as I explore these ideas.

Ghosts are almost like 3D tiddlers. 

• Basically you use a namespace such as $:/ghosts under which for every tiddler "tiddlername" you can you can have another tiddler $:/ghosts/tiddlername.  
• When I finalise my Tiddler Serial Number tools this will also be rename independant.
• My idea was so I could annotate the primary tiddler without even editing it, and add number of other cool features.
• With appropriate design the number of Ghosts for a single tiddler could be infinite. 
• The serial number can have a depth/layer/level number SN/0 SN/1... and even this could be reordered with drag and drop.
• The result the user can see can be programed in the view template as desired from a combination of the depth tiddlers.

Why mention them now?

• Such a facility would be helpful for text, however with smart design a ghost/or layer tiddler could have a background, that's displayed behind the foreground content, and one could edit the image on the midground tiddler. Which layer is for edit now could be a simple switch like layered image editors.
• Keeping such a design in mind provides guidance to the way we should provide an image editor for tiddlers, where the result has an invisible background that we could stack layers or include a fixed background.

Just thinking

Tony

[TonyM]

Illustrated?

tiddler

Layer1..n

ghost

Shadow

View template: Present a single view of all layers according to some rules

Tony

[Mat]

Tony - it sounds interesting!

<:-)

[TonyM]

Mat,

One reason I have gone down this path of ghost tiddlers is I would like to add icons, descriptions keywords etyc... to shadow system tiddlers without actually editing them.

I expect the application of layers will demand a changed viewtemplate

Regards

Tony

[TiddlyTweeter]

Ciao Mat

Round 2 :-)

Mat wrote:

... it is of course trivial to type "I love TiddlyWiki" on paper as well as in a tiddler. It is also trivial, on paper, to write+draw "I ❤ TiddlyWiki" but this is typically impractical when making a tiddler note. A drawing from a touch pad is, in my experience, a rough sketch  so it is rarely useful outside of an immediate context e.g some explanation.

 

... drawn images such as ❤ should ideally not have to be separate tiddlers as it really is no more separate than when we type the word "love" in a sentence.

Emoji combined characters work natively in TW. But I think you mean actual images embedded in a Tiddler?

 

That some scribbles are really part of the text is even more obvious when one considers annotations such as underlines or margin scribbles. (I made the transparent canvas proposal partly for this reason, i.e to be able to circumvent having to create a new tiddler and transclude it.) 

This is image-in-text problem is not unique to TW of course. I could not scribble a heart in this very google post either. 

 

Right. a couple of things occur to me to maybe look at ... 

Editor behaviour. Part of the issue is ability to make/insert images during edit without segway to a separate Tiddler. Mark S. and BTC some time ago suggested some proofs of concept of creating new Tiddlers inline during edit without segway. I have not had time to fully test their code ideas which I think are very neat and want to get working well sometime. To get an idea see: https://groups.google.com/d/msg/tiddlywiki/B0VGpW27MC4/bNVAKOxCCQAJ. 

Placement. I'd say that easier setting size of the insertion and its placement would matter. In old tools like Word, insertions can be sized & scaled in context using either handles at the edge of the inserted image or manual numeric sizing. Drag-to-Move placement within context is also common with text reflow.  Other types of tool overlay the item in an invisible box at some point relative to the containing div. I guess what I'm wondering if much of this could be achieved through some form of transclusion -- maybe with addition of an approach to editing similar to last point.

Thoughts

TT

[TiddlyTweeter]

Mat wrote:

That some scribbles are really part of the text is even more obvious when one considers annotations such as underlines or margin scribbles. (I made the transparent canvas proposal partly for this reason, i.e to be able to circumvent having to create a new tiddler and transclude it.) 

Round 3.

Raw in Tiddler v. transclusion. Not sure how well that would work. You could inline using base-64 thingie. That blob would then be fully hard-coded in-line. But for bitmap blobs you'd still have the same issues on scale but without the manipulable possibilities of transclusion? It seems to me transclusion is good. Perhaps the issue is about how to have a more "live" methodology in edit to create transcluded Tiddlers and edit them inline at will?

Thoughts

TT

[Mat]

Mat wrote:

Good news. Well, kind of.

I just realized that the TW tool I'm working on will much simplify this. I think only a few people have had a peek at it so far but you may know what I'm talking about. Hopefully I can have something officially released within a few weeks.

So, the thing referred to is EditorMagic. You can try this out (but not on Firefox) by, in the editor, typing "??dr" - this triggers a popup with a small canvas and and a button which, when clicked, inserts a transclusion like so {{image}} replacing the "??dr" in your edited text. It is just a rough proof-of-concept to show the idea. Eventually, such a popup should reasonably feature the canvas drawing toolbar, some resize function and an inline/block-display option. 

<:-)