A standalone Tauri v1 + raw WebGL 1 example for loading a still image into a GPU texture, processing it in a fragment shader, comparing the original and processed versions, and exporting the result through a native save dialog.
HTMLImageElement or canvas into a WebGL textureUNPACK_FLIP_Y_WEBGLcanvas.toBlob()| Mode | Purpose |
|---|---|
| Clean | Color grading only |
| Duotone | Maps luminance between two colors |
| Posterize | Reduces each channel to a controlled number of levels |
| Edge ink | Estimates neighboring-pixel differences and creates an inked print |
| Chromatic split | Samples red and blue from opposing offsets |
| Halftone | Converts luminance into a rotated dot screen |
| Prismatic warp | Applies radial displacement and chromatic separation |
| Solarize | Selectively inverts bright channel values |
Every effect is blended against the graded source with the Amount control.
Local image file / generated demo
│
▼
HTML image or canvas
│
texImage2D upload
│
▼
WebGL image texture
│
framing UV transform
│
color-grade function
│
selected effect mode
│
compare split
│
▼
preview canvas
│
temporary export resize
│
canvas.toBlob()
│
Tauri save dialog
│
▼
PNG or JPEG file
The built-in 1024 × 1024 demo texture makes the project useful immediately after launch.
These operations change texture coordinates rather than modifying the source pixels.
The preview can show the original image on one side and processed output on the other. The comparison line can be vertical or horizontal. It is intentionally disabled during export.
Processed output can use:
The source-image button saves the decoded source without framing or shader processing. Processed exports use the current framing, effect, and grade settings.
npm install
npm run dev
npm run build
16-tauri-v1-image-texture-processor/
├── package.json
├── README.md
├── V1-FOLDER-MAP.md
├── src/
│ ├── index.html
│ ├── styles.css
│ └── app.js
└── src-tauri/
├── Cargo.toml
├── build.rs
├── tauri.conf.json
├── icons/
└── src/
└── main.rs
Only the following native APIs are enabled:
No arbitrary filesystem reads are required because local images enter through the WebView file picker and drag-and-drop APIs.
The example uses an RGBA8 image texture and the default canvas framebuffer, so it does not require floating-point texture extensions. Image decoding format support depends on the operating system WebView.
Very large exports consume significant GPU and CPU memory because the completed canvas must be encoded as one image. Tiled export is demonstrated separately in the native-wgpu collection.