The image plugin is among the oldest plugin. While there have been changes to improve the creation of the thumbnail, little else has changed. Before talking about the changes, we record our observation Image Plugin Eccentricity, and thoughts Image Plugin Commentary.
# A Work in Progress
View of the new image editor. Showing an image of a half page width image editor in a full width one.
Rather than use the default editor, which only shows the caption, we can create a custom editor for the image plugin. The image can be kept visible.
Depending on the size of the image, the option is given to make the image full page width, new images that are wide enough will start out full width. The image squeeze used in the original image plugin had a target width that is wide enough to resize to full page width.
Rather than using markup within the items text, caption, we will use a new `size` attribute on the image item.
The image drop logic has also been updated to take a dropped `svg` image and put it into a `html` item.
The related issue with the map plugin not rendering well when placed next to images has been resolved by adding modifying its css to clear any floats.
# Currently Being Considered
**How best to store images?**
Currently a somewhat squeezed version, target size being width less than 500 or height less than 300. Is stored base64 encoded in the story item, getting duplicated with each edit. Which can result in significant growth of the page with each edit.
The current thought is to store the larger sized image elsewhere, and only have an appropriately size thumbnail stored in the page.
An obvious place to store images would be in the asset plugin, though web3.storage 
has been suggested. This choice rightly belongs with the asset plugin, rather than overloading the image plugin.
If the image version stored as an asset is the current squeezed image this should have a neutral, or better, disk usage impact on a farm. Maybe a large size squeeze could be used. *The current dialog is opened at 800x600, so is larger than the current squeeze target.*
Using a NASA high resolution image of Pluto, via wikimedia 
. This starting image is 8000x8000 at 5,212.47 KB.
The original image plugin gives a 500x500 image of 18,873 bytes.
The proposed change would give:
* A full width image, 419x419, of 13,554 bytes.
* A half width image, 183x183, of 3,393 bytes.
An alternative approach would be to just save the image as an asset, and use that, rather than having a data URL in the image item on the page.
The image plugin would need to be aware of assets, and search as required for image assets. The editor will need some indication that current wiki does not have a copy of an image asset, and provide the option to fork a copy to the current site. This should not add a journal event.
**Adjacent Images**
In Image Plugin Commentary there are some thoughts about disparity of placement between the page file and the screen rendering.
Ordering the images on the screen to match the order in the file is not practical without knowing their size. This would mean adding the image width and height to the image item. This allows screen size to be known when they are added in the emit phase.
Without adding the image dimensions the best we are likely to manage is to float those on the left half of the page to the left. But, a slow loading image might show some jitter.
**Window rather than JQuery Dialog**
With the aim of not using JQuery in a future version, replacing the use of JQuery Dialog with a browser window is an option.