npm package discovery and stats viewer.

Discover Tips

  • General search

    [free text search, go nuts!]

  • Package details

    pkg:[package-name]

  • User packages

    @[username]

Sponsor

Optimize Toolset

I’ve always been into building performant and accessible sites, but lately I’ve been taking it extremely seriously. So much so that I’ve been building a tool to help me optimize and monitor the sites that I build to make sure that I’m making an attempt to offer the best experience to those who visit them. If you’re into performant, accessible and SEO friendly sites, you might like it too! You can check it out at Optimize Toolset.

About

Hi, 👋, I’m Ryan Hefner  and I built this site for me, and you! The goal of this site was to provide an easy way for me to check the stats on my npm packages, both for prioritizing issues and updates, and to give me a little kick in the pants to keep up on stuff.

As I was building it, I realized that I was actually using the tool to build the tool, and figured I might as well put this out there and hopefully others will find it to be a fast and useful way to search and browse npm packages as I have.

If you’re interested in other things I’m working on, follow me on Twitter or check out the open source projects I’ve been publishing on GitHub.

I am also working on a Twitter bot for this site to tweet the most popular, newest, random packages from npm. Please follow that account now and it will start sending out packages soon–ish.

Open Software & Tools

This site wouldn’t be possible without the immense generosity and tireless efforts from the people who make contributions to the world and share their work via open source initiatives. Thank you 🙏

© 2026 – Pkg Stats / Ryan Hefner

@gregjohnso/pi-imgview

v0.1.0

Published

Display images from inside the pi coding agent: imgcat-style inline rendering in supported terminals, and one-click open in the system browser.

Vulnerabilities

Powered byPowered by Snyk
  • 0High
  • 0Medium
  • 0Low

Links

Git

Maintainers

gregjohnsogregjohnso

Keywords

pi-packagepi-extensionpi-monoimageimgcatiterm2kittybrowseragentllm

Readme

Imgview Extension

Show images from inside pi: render them inline in the terminal (iTerm2 / Kitty / WezTerm / Ghostty), open them in the system browser, or both.

The LLM gets a single tool, show_image, with a mode switch. You also get three slash commands (/imgcat, /imgshow, /imgboth) for driving the same code path by hand.

Why a separate tool when pi-tui can already render image attachments? Because the LLM has no way to attach an image on its own initiative. show_image is the bridge: it takes a path/URL, loads bytes, sniffs the MIME, and returns a tool result with { type: "image", … } content — which pi-tui then renders inline using the host terminal's image protocol. For terminals without image support, the browser path is a reliable fallback.

Install

# from npm
pi install npm:@gregjohnso/pi-imgview

# or directly from git
pi install git:github.com/gregjohnso/pi-imgview

Then /reload inside pi, or start a new session.

To develop locally, symlink this repo into your extensions directory:

ln -s /absolute/path/to/pi-imgview/extensions/imgview ~/.pi/agent/extensions/imgview

Tools exposed to the LLM

| Tool | Purpose | | ------------ | -------------------------------------------------------------------- | | show_image | Display an image inline in the terminal and/or in the user's browser |

show_image parameters

| Param | Type | Default | Meaning | | --------- | ------ | ----------- | ---------------------------------------------------------------------------------------------- | | source | string | — | Local path (absolute, relative-to-cwd, or ~/...), http(s):// URL, or data: URI. | | mode | enum | terminal | terminal | browser | both. Inline terminal is the strong default. Browser modes only fire when the user explicitly asks. | | caption | string | — | Optional one-line note shown alongside the image. |

The tool's prompt guidelines instruct the LLM to never pick browser or both on its own initiative — launching an external browser window is disruptive. Use the /imgshow slash command, or pass mode: "browser" explicitly, when you do want it.

Returned content:

  • A text summary (source label, MIME, byte count, mode, caption, browser path if any).
  • For terminal and both: an { type: "image", data, mimeType } part that pi-tui renders inline using the host terminal's image protocol. Pi-tui auto-converts non-PNG to PNG when the host uses the Kitty graphics protocol; iTerm2-family terminals consume the bytes directly.

User commands

| Command | Effect | | ---------------------------- | ----------------------------------------------------- | | /imgcat <path\|url> | Render the image inline in the terminal. | | /imgshow <path\|url> | Open the image in the system's default browser. | | /imgboth <path\|url> | Both. |

<path|url> may be:

  • a local file (absolute, relative to cwd, or ~/...)
  • an http:// / https:// URL (downloaded and sniffed)
  • a data: URI

Browser opening

Browser mode writes a tiny self-contained HTML viewer (image embedded as a base64 data URI) to $TMPDIR/pi-imgview/imgview-<id>.html and then:

| Platform | Command | | -------- | ---------------------- | | macOS | open <html> | | Linux | xdg-open <html> | | Windows | cmd /c start "" <html> |

HTML files inherit the user's default-browser association on every supported platform, so this routes through the actual browser rather than (e.g.) Preview.app on macOS.

Supported MIME types

image/png, image/jpeg, image/gif, image/webp, image/bmp, image/avif, image/svg+xml. MIME is determined by magic-byte sniff first, file-extension hint second.

Anything else is rejected with a clear error rather than silently forwarded — base64 of an unknown blob in the model's context window is never useful.

Limits

  • Images larger than SOFT_MAX_BYTES (default 8 MiB) trigger a warning in the tool result. Inline rendering still works; the warning is for context-window awareness.
  • https:// fetches use the global fetch and respect the agent's abort signal.
  • The custom message renderer for the slash-command path uses pi-tui's Image component with maxWidthCells: 60; the LLM-tool path inherits pi's normal tool-result image rendering.

Settings (module constants in index.ts)

SOFT_MAX_BYTES = 8 * 1024 * 1024   // warn-only soft cap
TMP_ROOT       = $TMPDIR/pi-imgview
DEFAULT_MODE   = "terminal"

Running the unit tests

cd ~/.pi/agent/extensions/imgview
npx tsx --test utils.test.ts

Why this is separate from antigravity-image-gen

antigravity-image-gen creates images by calling Google Antigravity, then returns them as tool-result attachments. pi-imgview displays existing images — files on disk, things at URLs, or data URIs the model constructs on its own. They compose: have the model generate via antigravity, save the result to disk, then show_image it.

Share your own pi extension by publishing it to npm with the pi-package keyword — pi's package gallery auto-indexes it.