Image storage suggestions

[David Allen]

Hey all!  I've got an image-heavy wiki and I'm trying to figure out how best to include these images.

I've tried the following:

• Imported directly into the wiki.  This makes the wiki impossible to load on my chromebook.
• External to the wiki in the same directory: Keeps the images private but does not work between Windows and Chromebook.
• Online image hosting: I'm using Google Photos, but the URL for the images changes occasionally, making it difficult to use

Does anyone have any reliable solution that would be cross-platform and preferably private?

[magev958]

I have the same situation and uses github for image hosting. I think the limit is 1 GB but it is enough for me and it's free

/Magnus

[Mark S.]

Re #2 -- can you show an example of the paths you're using? If you use a relative path name they should work the same on all platforms.

-- Mark

[hubertgk]

I'm using Imgur for image hosting and it works well. The URL is static and nicely shortened. The only limitation is that you have to be online for the images to load :).

The service is free and I think the number of pictures you can upload is unlimited (I could be wrong on this one, though).

As goes for privacy, if you upload individual photos to Imgur (as opposed to images organised in albums) they will be private by default -- although there is no privacy setting as such, individual images are not searchable nor viewable unless accessed by direct URL.

-Hubert

[Ste Wilson]

I'm using drop box via one of two options which allows you to serve files.

Pancake.io or updog.co

[PLATO]

I'm using MyCloudApp for my image hosting, it works well. you can try.

在 2018年1月19日星期五 UTC+8上午11:19:21，David Allen写道：

[Abraham Samma]

How about this: take an image url, embed into your wiki using a reusable

<img>

tag snippet and then cache images. The only problem you'd have to worry about is link rot but I believe it saves you the hassle of looking for a hosting service that can go bust at any time.

Cheers.

[@TiddlyTweeter]

Mark S. wrote:Re #2 -- can you show an example of the paths you're using? If you use a relative path name they should work the same on all platforms.

IMO image linking in TW needs its documentation improving and clarifying. Issues with it come up again and again.

Its NOT from lack of methods to do it. If anything TWs image methods are liberating, NOT restrictive.

I do think that the footpath gets sometimes fouled by users being more concerned with cheap image hosting than how TW works.

Issues get blurred and we often having discussions that confuse final outcome with methods.

Best wishes
Josiah

[Mark S.]

If the image is in the same directory as the TW, all the img src attribute (or the _canonical_uri field) should need is the image name (no path).

-- Mark

[BurningTreeC]

hello @David Allen,

I made a Wiki not long ago with thousands of images and I kept them all external.

I figured out a way that worked very well for me, by using TiddlyDesktop, where the external-attachments-plugin works

I changed the plugin a bit so that I could specify a path relative to my wiki file where my images are stored and the plugin used that path to set the _canonical_uri_, that worked very well, I could import many files at once

Then I made a button that made a catalogue of all images in a data-tiddler with the filename and its corresponding path and that deleted all single tiddlers

I created a macro like <<catalogue-image "name">> and it showed the image

for me this worked on Linux and Windows with the same wiki, when the image folder's relative path to the wiki file was the same

Simon

[BurningTreeC]

oh, I forgot...

even if the path wasn't the same, the macro used the path specified in a tiddler, so that I could change that when needed.

so I could also create different catalogue files, each file using a different folder

[David Allen]

This is what I had before and it did not work on my chromebook.

Virus-free. www.avast.com

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/ZFvg5ssm294/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tiddlywiki+unsubscribe@googlegroups.com.
To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/1a4f6996-e0ff-477b-a0f8-84266ccb5340%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

David Allen

[BurningTreeC]

This is what I had before and it did not work on my chromebook.

Does the file-path naming on chromeOS follow the Linux way like /home/user/Documents?

 

[Mark S.]

As they say in school, "Show your work." It would really be helpful to see how you are referring to your image.

Oh, and be sure that you can view the image in a separate browser tab. If you can't view it in a tab, then you can't view it in TW either. Possible problems include user rights, corrupted files, wrong extension, or (maybe) non-latin character names.

Good luck
-- Mark

On Sunday, January 21, 2018 at 8:45:48 AM UTC-8, David Allen wrote:

This is what I had before and it did not work on my chromebook.

Virus-free. www.avast.com

On Sun, Jan 21, 2018 at 8:36 AM, 'Mark S.' via TiddlyWiki <tiddl...@googlegroups.com> wrote:

If the image is in the same directory as the TW, all the img src attribute (or the _canonical_uri field) should need is the image name (no path).

-- Mark

On Sunday, January 21, 2018 at 3:56:45 AM UTC-8, @TiddlyTweeter wrote:

Mark S. wrote:Re #2 -- can you show an example of the paths you're using? If you use a relative path name they should work the same on all platforms.

IMO image linking in TW needs its documentation improving and clarifying. Issues with it come up again and again.

Its NOT from lack of methods to do it. If anything TWs image methods are liberating, NOT restrictive.

I do think that the footpath gets sometimes fouled by users being more concerned with cheap image hosting than how TW works.

Issues get blurred and we often having discussions that confuse final outcome with methods.

Best wishes
Josiah

--
You received this message because you are subscribed to a topic in the Google Groups "TiddlyWiki" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tiddlywiki/ZFvg5ssm294/unsubscribe.

To unsubscribe from this group and all its topics, send an email to tiddlywiki+...@googlegroups.com.

To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/1a4f6996-e0ff-477b-a0f8-84266ccb5340%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

David Allen

[David Allen]

I've done this two ways now and neither worked.

The first is using an <img> tag, as follows: <img src="blah.jpg">

The second is with a tiddler, whose content type is set to jpg, with a _canonical_uri field with the following: "blah.jpg"

In both instances, I can retrieve the file on my windows computer, but not on chrome.  Both the tiddlywiki file and the blah file are being synced using google drive.

To unsubscribe from this group and all its topics, send an email to tiddlywiki+unsubscribe@googlegroups.com.

To post to this group, send email to tiddl...@googlegroups.com.
Visit this group at https://groups.google.com/group/tiddlywiki.

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/c0cd909e-3e8a-495f-a7a9-14de694ea609%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

David Allen

[Mark S.]

Did you test that you can open the image file by itself (not in TW) inside of chrome?

Is the image file in the same directory as the TW file?

-- Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/c0cd909e-3e8a-495f-a7a9-14de694ea609%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

David Allen