Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

How to "Import" Images into Twine 2

QRGinP.png

Someday, Twine 2—currently rocking version 2.0.6—may include the ability to import images just like its forerunner, Twine 1. If that's the case, this guide will suddenly become obsolete! Good riddance I say!

Until then, we can quickly and easily include images into Twine 2 twines using Base64 encoding. (You better notice the "BASE64" in the above meme—it took me all of five minutes to edit it! Ha, ha, ha! I'm so funny!)

Notice, in the title of this thread I placed "Import" in quotes—that's because there isn't currently a UI option to do so (i.e., there's no "Import Image" button). So, we can't actually include images in that fashion. However, I wanted to make it clear that this isn't a guide to using basic HTML to display images in the standard fashion, something many people already know how to do. No, we're going to actually put the images inside our twine's HTML so that we don't have to include other files or link to the images elsewhere on the 'Net.

Here's a excerpt from the official Twine 2 Guide:
If you'd like to create something that makes heavy use of images, sound, or movies, you may want to stick to Twine 1 for now. But that's not to say that you can't use these things in your story! For now, you'll need to store them elsewhere – whether it's on a web site you control, or a service you use like Dropbox – and put references to them in your story.

The guide's author knows all about Base64, I guarantee, but its use goes beyond the scope of the guide. That's where this tutorial steps up to the plate.

The standard way to include images in a Twine 2 twine is the same as it is with any Web page; that's because Twine 2, like Twine 1, creates HTML files and HTML files are Web pages when accessed on the Internet. HTML is the standard markup language used to create web pages.

latest?cb=20120930201320

Shut up, Nicolas Cage meme! This is a beginner's guide! >:-(

Anyway, here's the standard way to show an image in Twine 2:
<img src="www.example.com/image.jpg">

Of course, one must replace the example URL with the URL of an actual image, but that code in any passage will display an image. Finding an image on the Internet and image hosting isn't within the scope of this guide—but I'd hope that's general knowledge in this day and age. You heard it here first! There are images on the Interwebz! I wonder if there's porn?!

Unless you're like me and are a godlike AI computer brain that can convert images into Base64 using your vast cosmic intelligence, you'll want a tool to do the work for you. There are several out there that your search engine of choice can find.

480225.jpg

. . . If only I knew . . . :-(

Okay! No more interruptions from the meme-o-sphere! Let's get to it!


For this guide, we'll use http://www.base64-image.de/.

If you're playing along, open that URL now. In another tab or browser window, open Twine 2 and follow these steps:

1. Using base64-image.de, click on Upload Image. It's a huge orange button; can't miss it. ;-)

2. Click the "choose file" button and upload your image from your computer.

3. Click the "encode image" button.

4. A new page will open. Scroll down to the "XHTML Image" field. It's right above the "XML Image" field, so don't get the two confused.

5. Copy the code. Using Windows, you can do so by left clicking once anywhere on the line of code to select it, then right click in the same location and click "Copy." Or, after selecting the code, you can just press the Ctrl and 'C' buttons simultaneously on your keyboard. Hello, basic computer use skills!

6. Paste the code into your Twine 2 passage. Likely, this will be a massive, super-long block of code that looks like utter gibberish (to feeble non-AI brains like yours).

7. ???

8. PROFIT!!!

Boom. That's it. Yep. Pretty simple. Even an Earthling can do it!

Pfft. Stupid Earthlings. Your day will come.

Now, get to work putting images in your twines! One less excuse to not use file hosting services such as philome.la or IFDB or Adventure Cow!


Included is an example HTML file using Harlowe (1.0.1), the default story format for Twine 2, but was tested and confirmed to work in SugarCube (1.0.25) and Snowman (1.0.2).


Disclaimer: This basic beginner tutorial was not meant to address all the various nuances and details of Base64 encoding. My anecdotal tests indicate that Base64-encoded images seem absolutely identical in appearance to my eye with no noticeable degradation at all from the process. However, as an unexpected bonus, using Base64 greatly decreased page loading times for me when switching from the HTTPS required for cloud hosting solutions such as Dropbox (Microsoft confirmed this should be the case). Notice that the single-passage, no-text file is "heavy" by some 400 KB, roughly the size of the Base64 image, versus a "blank" twine. While the size of my Base64-encoded image is negligibly larger than the source file (or might even be exactly the same) in my example HTML, a Google search tells me Base64 increases the size by a varied amount (some say as much as 33%). Base64 is unlikely to work in ancient, junk browsers (IE8 and older) so old and outdated that they are unlikely to support a lot more than just Base64, so it's practically inconsequential. In other words, if they are using that old of a browser, Base64 support is the least of your design concerns. Most browsers support gigabytes worth of Base64-encoded images. Again, you'll likely run into other limitations before the size of your images matter. For more information on Base64 encoding, see the Internet.

Comments

  • Excellent guide.

    One small issue/warning you may want to include is that if the Author is using one of the web-browser based versions of Twine 2 then there is a limit on how large a Story Project can be. (the total size in MB's)
    This is due to the Twine 2 application using the web-browse local storage, which is limited by default to between 5 and 10MB's depending on the web-browser being used.
  • I like that 7 is just question marks! hahaha
  • @Sharpe
    Question, I saw that you can also Base64-encode audio as well. How do I include that in the story?
  • Sage wrote: »
    @Sharpe
    Question, I saw that you can also Base64-encode audio as well. How do I include that in the story?
    Browser-based versions of Twine 2 need not apply.

    Because the browser-based versions of Twine 2 stores your projects within the browser, you have a very limited quota (generally, 5–10 MiB; although, that's a little misleading, since, because of the encoding used, you actually only get to use about half of that). If you really wanted to do this, you'd have to increase the Web Storage quota significantly. How you go about doing that varies from browser to browser, but generally entails voiding the warranty (no warranties exist, so no warranties are actually voided, but you would have to jigger settings in your browser's guts, or the registry in IE's case).
  • hahaha - need not apply. Check.
  • Sage wrote: »
    @Sharpe
    Question, I saw that you can also Base64-encode audio as well. How do I include that in the story?
    I'm guessing you saw B64 audio in my Harlowe 1.1 beta bug report, for which I attached an HTML files.

    The HTML audio tag is used to play sound files. Base64 can be considered a source type. Here's how I used it in that twine:
    <audio autoplay loop>
      <source src="data:audio/mp3;base64,[Base64 Goes Here]" type="audio/mp3">
    </audio>
    

    Here is the tool I used to encode the original sound file (which I can't remember if it was an .ogg or .mp3 originally, but it doesn't seem to matter when it comes to the HTML code to play it):

    http://www.opinionatedgeek.com/dotnet/tools/base64encode/

    Included is the working twine (tested in Chrome, FireFox and IE) from Harlowe 1.1.1.

    It was made using the online, web-based Twine 2, but it's a very small audio file. Still, a lot can be done in 5-10 megabytes, or even 2-5 megabytes.

    On the other hand, currently, if someone is making use of more than a few bleep-bloops here and there, SugarCube (and Twine 1) is a vastly more appropriate story format.
  • @Sharpe
    SugarCube Til I Die, son !!!

    But seriously though:
    Do the tags look the same? Or were you saying from your link to MotoSlave that you don't know the syntax?

    The reason I ask, is because MAYBE... just MAYBE... I need to leave the browser version. But I don't know if I want to. Right now it seems so freakin easy.

    And in a world where literally EVERYTHING is basically new to me... not having to worry about compiling and/or installing seems like a gift (although... no doubt my ignorance is showing here... probably no compiling... am I right?).
  • Sharpe wrote: »
    <audio autoplay loop>
      <source src="data:audio/mp3;base64,[Base64 Goes Here]" type="audio/mp3">
    </audio>
    
    Note: That audio/mp3 is not a real MIME-type.

    For an MP3, the data URI's MIME-type should be audio/mpeg. The <source type> parameter should either be the same or, if you're feeling like a boss, you can also include the codec component, which would make it audio/mpeg; codecs=mp3.

    For example:
    <source src="data:audio/mpeg;base64,[Base64 Goes Here]" type="audio/mpeg">
    
    Boss version:
    <source src="data:audio/mpeg;base64,[Base64 Goes Here]" type="audio/mpeg; codecs=mp3">
    
  • Sage wrote: »
    Do the tags look the same? Or were you saying from your link to MotoSlave that you don't know the syntax?
    Sharpe was using the HTML5 <audio> element (and <source>), which works in SugarCube as-is.

    I wouldn't recommend them, however, which is the main reason why SugarCube's audio macros exist. That said, there's currently no macro which will ingest a data URI (<<cacheaudio>> only accepts file/network URIs), so that's an issue for now.

    Sage wrote: »
    The reason I ask, is because MAYBE... just MAYBE... I need to leave the browser version. But I don't know if I want to. Right now it seems so freakin easy.
    There is, literally, no way in which the browser-based version is superior to the executable version, save one (being usable on mobile devices), and several ways in which it is inferior (generally, all revolving around the fact that Web Storage was never meant for the workload being forced upon it; i.e. you aren't allowed enough of it and it's far too easy to wipe out).

    Sage wrote: »
    And in a world where literally EVERYTHING is basically new to me... not having to worry about compiling and/or installing seems like a gift (although... no doubt my ignorance is showing here... probably no compiling... am I right?).
    Yes, no compiling. And the installer is both bog standard and simple. Seriously.
  • Alright. I'll switch. I have lubuntu. I assume that works without a WINE-kludge.

    I'll go check it out now and install it.

    :)

    Cheerio. Pip pip. And whatnot
  • Lol. Boss version.
  • I wouldn't recommend them, however, which is the main reason why SugarCube's audio macros exist.

    Oh, heck no; I wouldn't either. The audio macros in SugarCube (and Leon's for Sugarcane) are great.

    I only answered how to do so because you asked, Sage, and I only included Base64 audio in my bug report because Harlowe has no audio macros and I was testing for bugs and you can't import anything in Twine 2 (yet?).

    So, totally agreed: SugarCube (Twine 1 or 2) and Sugarcane (Twine 1 only) audio macros are far, far better. Like I said:
    Sharpe wrote: »
    On the other hand, currently, if someone is making use of more than a few bleep-bloops here and there, SugarCube (and Twine 1) is a vastly more appropriate story format.
  • There is, literally, no way in which the browser-based version is superior to the executable version, save one (being usable on mobile devices) […]
    Actually, that's not correct, at the moment. The browser-based version does, currently, have another, and very useful, advantage over the executable version. Being able to drop assets relative to its root directory and having them picked up when using Test/Play.

    I forgot about that one. Mea culpa.
  • edited July 2015
    The browser-based version does, currently, have another, and very useful, advantage over the executable version.
    Also the Test/Play options open in a standard browser window allowing you to inspect the HTML, CSS, and Javascript when testing, whereas you have to Publish your story to do these things using the installed version or as I found out today use the Ctrl+Alt+Shft+D key combination.
  • I would also suggest using SVG images. Their code can be written directly into the CSS and as they are vectors, are fully responsive. This can also be animated with CSS directly or jQuery. Using SVG there is no need for converting or linking at all
Sign In or Register to comment.