# Enable "image/webp" format (behind [Shift] property) to store costumes

### Caution: a very large project, may cause trouble to your browser.

Snap uses "image/png" as the default format for storing images in the project. The new format "webp" has a much better compression ratio and acceptable compatibility. For the users, this change should be fully transparent.
To get some estimation I created a
project with ~70 large costumes
from an image hosting site. The nominal project size is ~16MB.
But I instructed Snap! to store costumes as "image/webp". The size of the project is now 2.6MB and can be stored in the cloud or exported.
There is a block

to change image format before storing a project.

Sounds like a good idea. We certainly won't do it before 7.0, but maybe later.

Does this format allow for storing arbitrary metadata with a picture? I want to teach Snap! to store the XML of a script along with script pics.

"webp" supports Exif and XMP so it's plausible. But not more easily nor harder than for other formats.

Thanks.

I made a proof of concept (Chrome only) picAsXML
You can create a script picture with XML attached - menu "script pic & XML".
When you Shift + drop such picture, attached script is imported.
Dropping from the forum and local filesystem is possible.
Examples to drag&drop :
(Updated to the current version)

JS from "menu script pic & XML" and "accept pic & XML" can be also injected into with user script managers, like Tamper Monkey.

For offline processing XML can be extracted by looking for "Snap\tBlocks\tEmbedded".

An image must be intact - not distorted by any browser optimizer/accelerator.

Edit : now with optional "XML" badge.

Wow! Thank you so much!

This is neat! It looks like the current project still uses PNG? On my Mac, the files are .png, and the XML is there.

My understanding is that data like this would need to be in a structured block in the PNG file. Do you know if it's spec compliant to just ignore data after the end of the file? I couldn't find something obvious about how consistent this behavior is.

Image file type is parametrized inside "menu script pic & XML". To separate concerns, the default is "png".

So am I.
Data beyond logical "EOF" for a given format can be verified by some kind of sanitizer.
Taking into account, that even legit metadata are already considered a privacy threat and vector to iframe incjection, I think that this kind of appending data is only slightly inferior, as compared to EXIF.
Depending on expected use data can be split right before use.

Tested both scripts and works in macOS Safari, at least the 2nd one was imported successfully.

(The 1st one was just missing one of the blocks, the one in the middle)

That's because the current version of that block has a dropdown and no " , with badge" Title text, whereas the older version has a boolean and the Title text " , with badge".

Yes, updated original post.

Ok.

hmm, now neither work in Safari.

Also tried Firefox (with the previous images, before the edit), but got a CORS message, but I think you already knew that.

I used cross-browser methods (at least tried ), but without any test on Mac.

BTW: Did you remember to use Shift while dropping?

For the forum images COORS is needded indeed, so there is a "https://api.allorigins.win/raw?url=" proxy used. You may try save to disk then drag.

Brian reminded me yesterday that you need a more formal way to embed scripts into image. I updated project. Now XML is added as an iTXt chunks, fully compliant with PNG spec. Also non US-ascii characters should be handled.

Cool! Sounds perfect.

Now with EXIF as UserComment.

Hi @dardoro ! I'm Dan Garcia's student that is working on this script-embedding project within his group. I have looked through your code and its amazing! I think that this project is great, and would love to help you anywhere that I can, so if I can, please let me know!

Hi,
Feel free to use it for whatever purpose and modify it to suit your needs.
Code is over-compressed to fit into a single screen Also, I prefer code base reuse by extending the original function with "pre-" or post-processing. If you are able to make PR to the code base those can be inlined.

You are interested mostly in embedding or UI aspects?
There are two most obvious problems:

1. Exporting definition of the custom blocks
2. Remove "shift" modifier. It's hard because drag'n'drop event data is volatile if used in asynchronous code.

There is also room for improvements like a network shared backpack and online blocks decoder.

Hi @dardoro. We are definitely trying to get this integrated and into a PR as soon as possible. We're interested in using this for the embedding aspect, to make the CS10 course more efficient with a ready-to-go code library. I will look into those two problems that you pointed out because those are also Dan's two largest concerns.

I'll be sure to get back to you if I ever run into a wall and need your guidance!

Thanks again!!