FR: Some feature requests, including adding command functionality and image classification features

[YIRU69]

Hello, I saw your post on the forum. I really like your plugin. While using it, I noticed that the plugin doesn't have a command invocation feature and can only be opened from the sidebar.
Also, considering there are too many images, could you add an image classification/categorization feature? For example, organizing certain images into spaces, etc. This might be somewhat difficult to implement, but if it's for image management, it should be fairly important, right?

[YIRU69]

Supplement: jepg format cannot be displayed normally

[yanghuidong]

I'm really glad you actually gave it a try, before the review process even started. I'll look into the two smaller issues, thanks for reporting:

• Missing command for opening PicsExplorer;
• JPEG display?

Now about "image management", it is still on my mind, but at this early stage of the project, I have to be cautious not to invest in some hard-to-get-right feature that might not have a great cost-to-benefit ratio. Think of it in terms of CPI; for example, I use Obsidian's full-text search all the time, but tags? Not nearly as much. In this sense, FTS is a high-CPI feature, whereas tagging, at least to me, is of significantly lower CPI. To be clear, I believe tagging is useful, I'm just saying, it's not as useful as searching, not even close.

For now, what you can try to improve image organization and discoverability in your vault, just with the current version 0.3, is the following:

• Place image links of a specific topic you want to curate in notes under a common folder, or with some consistent file/folder naming pattern, and then you can leverage the search feature to gather related images on the fly. For example, if your daily notes are named using the ISO 8601 date format, then you can enter "2025-09" in the search box to collect all images you've added during this month.
• Add tag-like keywords to the image descriptions (i.e. alt attributes), and again use search to discover them; I said "tag-like", because Obsidian currently doesn't parse hashtags within image descriptions. For example, even if you put ![Cat of the day #cute](...) in your note, you won't see #cute being recognized by Obsidian as a vault-wide tag. Nevertheless, you can enter "#cute" in the search box of PicsExplorer and it will find that image for you.

---

Now I realized that the topic is quite thought-provoking, so I'll write on. You might not find the stuff below interesting, however; I just think that in case I do decide to go for a more ambitious image management system in the future, the following can help to put things in the right perspective before the designing phase starts.

At the moment, the plugin is focused on three features:

• Gather
• Search & filter
• View

One way to look at tagging is that it is a tool to facilitate searching / filtering, namely, to find (and display) the images you're looking for. I think that's the ultimate purpose, yet we have several different means to that end.

Now designing and implementing each such means incurs a cost. There are two aspects of the cost:

1. Cost of development - although tagging is considered a conventional feature, it's not trivial to create something that is of great UX, esp. if you want it to be hierarchical, and to promote maximal tag reuse (i.e. preventing creation of similar tags, or rarely useful tags).
2. Cost of use - this is actually the bigger problem; developing it can be considered a one-time cost, if it's done right; but users having to actively use it on a regular basis, that's a never-ending cost, it almost requires a discipline. Question is, Is it worth it? I had personally used quite a few "advanced features" of various software that all take non-trivial effort, but in the end, I stopped, because the effort was , not worth it. And I don't want this to happen to users of this plugin.

So, with that in mind, what is most likely to be the winning approach to "image management"? By winning, I mean, efficient, and more importantly, sustainable. I think a winner will have at least the following qualities:

1. A natural fit to Obsidian's plain-text centric philosophy, i.e. store user-generated metadata as part of the notes (in the vault), not in a separate database (in the browser). That means, a bottom-up, free-form annotation scheme is much more natural, than a top-down, DB-centric approach. The latter is possible, but it just needs to be well justified for taking on that extra cost. Think about the recently introduced Notion-like feature (Bases), not only did it take a fairly long time to design and implement properly, but I bet the team had been arguing about its justification for much, much longer. For the same reason, I think Bases are useful, but not nearly as useful as the notes themselves. Even some avid Notion users say they don't want to make yet another database no more :)
2. Effortless ongoing maintenance by the user, that is, it doesn't become a cognitive burden to keep the management system not broken. That means specifically, when people add an image that they later want to retrieve effectively, they simply describe the image however they want, in the alt attribute, or in the surrounding note context. This is very natural and of low cognitive load, because all they have to think about is the image at hand; Now tagging, on the other hand, requires a lot more planning, because it is about designing a global, possibly hierarchical structure that hopefully consists of orthogonal concepts that compose well, cover all topics with minimal overlap or redundancy, age well, and stay future-proof. It's definitely possible to achieve, but in my experience, it is just not something you want to reach for, if something much simpler, much less daunting, is readily available. For instance, full-text search, where the notes act as rich contexts of the referenced images within.

This I believe is the philosophy of Obsidian, or more generally, of free-form plain-text note-taking:

• Text-heavy, not DB-heavy;
• Effortlessly organic, not perfectionist organization through discipline.

[YIRU69]

You are very thoughtful. The tags function can be replaced by images in markdown. Thank you.

[YIRU69]

[yanghuidong]

Supplement: jepg format cannot be displayed normally

I tested with some JPEG images, both remote and local, and they seem to display fine. What kind of display issues did you see specifically?

As a matter of fact, all supported image formats are treated equally, there's nothing in the code that handles JPEG differently from e.g. PNG.

[yanghuidong]

To the best of my knowledge, this plugin doesn't send GET requests to fetch images, rather, all it does is setting the src attribute of img elements, which is not the same as using the fetch or XHR API. I can only guess those requests that you saw were initiated by something else. It could be Obsidian, or some other plugin.

You can check this by looking at the "Initiator" column of the "Network" tab of the DevTools. Let me know what you see.