I suppose that makes sense. I’ve been thinking about this for quick embeds, where I only rarely would care much about image fidelity. If I’m scaling it down to fit nicely in the flow of a tiddler, I am likely less worried about exactly how faithful my compressed version is. But that’s not the only likely workflow; and those who don’t want it might be hoodwinked by the easy offerings.
Alignment images would likely still be helpful. Why is this a rabbit hole?
I am not referring to editor tools in the current editor or a popup therein for aligning images, but rather an entire new class of editor that renders transcluded images inline and provides affordances to align and resize them.
If we are talking about the image editor, it would be a good idea to rebuild this, because at the current stage it is lacks many features that would be necessary to make it universal enought so that I would really use it.
namely: cropping, perspectitve distorsion and alpha-channel.
Image cropping is a relatively simple action if you use it for GIF or PNG screenshots. After cropping it’s possible to save without image quality loss. … But as soon as JPG is involved there are actions, which can be applied without loosing image quality and other actions will lower image quality with every load → modify → save action.
Fixing the perspective distortion needs advanced algorithms and should already be applied, when an image is created, because it’s the least amount of work needed to put into the whole workflow, if it done immediately.
Creating an alpha-channel is also advanced. Most of the time the alpha channel is used to create transparency, but it can also be used for other effects like “height maps”, which is a completely different “beast”.
So what I want to say is, that even “simple task” can become complex as soon as there are minimal changes to the “standard” workflow a browser can do out of the box.
I think it should be completely avoided, since there are a lot of dedicated image apps which create good results.
I like to use https://squoosh.app/ to experiment with lower image sizes using lossy compressions like JPGs
I like to use IrfanView and its filter addOns for “simple” modifications and batch-processing of many images.
I personally would never try to implement something into TW, because it can be done much easier and much better with dedicated software.
Any kind of image editing/compression is entirely outside the scope of what is being discussed here. Apologies for any confusion on that front.
THank you for your thoughts.
The alpha-channel would have the most advantages in TW because this would make it possible to draw over images e.g. to demonstrate something.
But if you use TW as classroom-tool, it would be good not to be forced to leave the TW to perform tasks - even if you can easily find tools on the net to do something like this.
Imagine you capture the photo of a drawing but have to crop it, it would be cool to do this in fast and direct.
@saqimtiaz sorry for the confusion 
your tool drives me to further desires.
I have pushed some updates with customization options.
https://saqimtiaz.github.io/tw5-plugins-sandbox/#%24%3A%2Fplugins%2Fsq%2Fquickimages
The alternate mode where a popup is shown for image alignment and size options is something I will work on in the future and I need to consider if that is an extension of this plugin or an alternate plugin.
If there are users that find this workflow useful with no popup shown prior to import, feel free to test this and report back if there any issues you come across.
This plugin changes nothing with regards to where images are stored other than generating unique titles on import.
Currently if I take a screenshot in windows, it is getting stored in a Screenshots folder by default. If the change the location of the file or delete the file, the image within the wikis is still working. Does that mean the storage location of the screenshot doesn’t matter at all once the image is within the wiki. Is the image saved within the wiki ?
I am not clear on the details of your current workflow or how what you describe is implemented. However, it seems completely independent of what has been described in this thread.
If you have questions about how images are stored in TiddlyWiki, I recommend creating a new thread with details about your current workflow and what needs clarification.
May be I misunderstood the use of this plug-in. Is it only for creating unique and custom quick titles for the imported images. Saving of the image happens in the default tiddlywiki ways rite (independent of this pug-in) ?
What about scaling? When you hover over a tab, you see a thumbnail of the web page. This suggests that the browser can already do scaling.
The reason I ask is because often an imported picture is much larger than you really need it. Also, for making bookmarks and other use-cases a thumbnail would be really helpful.
To me, the features an editor needs to prevent having to open up a separate app is cropping, and scaling.
It automates the name creation, so it all happens without having to stop and use the import dialog. The image is stored locally in the TW file. TW doesn’t know anything about the original file disk location. In fact, in the stand-alone TW files, the browser doesn’t share the originating path because for some obscure reason browser manufacturers consider this a security risk.
One idea would be a button that changes icon depending on status (like e.g the save-wiki button, or the preview button). Regular import could be depicted like so: 
i.e with an empty square, and the other one would have an image in the square, i.e you merge the former with this 
. Same idea but maybe clearer if non-intruding arrow: 
and the square could be blank vs colored.
@saqimtiaz - having now tested you plugin I must say it is way smoother than the native UI.
Like you, I wish to easily import a lot of images but, of course, single file TW is not optimal for that.
…however, if dropping image urls could wrap them with [img[my-image-url]] then it would be super smooth to include externally hosted images. I.e, it is possible to grab this image and drop it into the editor… but that only adds the url. If it was automatically wrapped with [img[...]] then the image is seen.
…and if the mechanism allows the user to pre-activate a (user created) custom macro that modifies the url string after it is dropped into the editor but before it appears there, then images hosted in special services (google drive, etc) can be used!
I experimented with this when you proposed it previously but there wasn’t enough feedback and engagement so it never went anywhere. With core improvements since then such as functions and the substitute operator it might be more feasible today. However, at present it really does not fit my own use cases so I am unlikely to revisit it.
Understandable and thanks for previous experiments! My impression, after a quick peek at the contents of your plugin, is that the bits defining the critical events after dropping the blob (is that the correct term?) and before it is inserted in the editor is implemented in js, so it would be difficult for a wikitexter like myself to build on it. Would it be possible to include a procedure call to a non-existing procedure at the critical moment so that iff the procedure exists, then it is run instead of the current mangling in your plugin?
Thanx 
@twMat this plugin is concerned entirely with files that are dropped/pasted into the editor. The handling for text that is pasted/dropped is entirely separate and not relevant for this plugin.
If anyone is interested on a different workflow I have developed for myself to do with images within “instruction wikis” is as follows for my single file wikis and no server backend. I just developed it so I may need to revise.
Step 1 - Include in wiki
[img[imagename]]
step 2 - externalise images
I use this Externalising Image Files with JSzip using tools you probably already have
Here is a different approach – a set of tools that allow you to zip up your image files into one convenient download which you can then extract wherever you want.
I do a bulk export and unzip in my wikis folder or subfolder
#1
$:/images/ prefix so they no longer appear in searches it would help.{{imagename}} or [img[imagename]] to easily find where they are in use.