I would strongly advise against using the “Embed an image as a Base64 data Passage” feature of the Twine 1.x application, as doing so causes a number of issues both when generating the Test/Story HTML file and when view that HTML file within a web-browser:
Converting an image file into Base64 data greatly increases the storage space required to hold the image’s data.
eg. Encoded a 24 KB png file resulted in 32 KBs of Base64 data, so increasing the storage space required by 33 percent.
The Twine 1.x application’s “build HTML file” system will fail once the total MBs of Base64 data in the project becomes to large to store in the String buffer used to generate the HTML file, the limit is guessed to be somewhere between 60MB to 90MB in size. note: The exact point when failure will occur is not known, as no-one has bothered to do an intensive test and the limit also seems to be affected by the environment the application is being run on. It is known that simply having more RAM available to the application does not seem to make a difference to the limit.
The web-browser being used to view the Story HTML file needs to load the entire contents of the file before it can start processing that contents, thus the larger the file is the longer the delay before the end-user sees the first Passage.
Depending on the story format being used, its “startup” process may also take longer if it loads a copy of each Passage’s contents into memory to improve later access to those Passage, thus also delaying the end-user seeing the first Passage. SugarCube is one such story format.
Embedding an image as Base64 data can cause the web-browser to consume up to 3 times more memory for each image shown, than using externally stored images:
a. When first loading the HTML file into the memory being used by the web-browser.
b. When loading a copy of the content of the image Passage into memory at “startup”.
c. When converting the image’s Base64 data back into an Image object so it can be shown on the page.
Using embed image data bypasses the web-browser’s own image caching system, which has been specifically design to make efficient usage of the web-browser’s resources.
I agree with you, I was worried about storage space.
What I figure to due (by using the newer version in Twine with Harlowe 3.2.3) is to save the image in OneDrive and open the image into a new tab. Then use the URL from that tab and place it into this code:
and it works for me.
Also the images are already scaling to the test window perfectly.