I really don't need a new project, but I would love a clustered and/or GPU accelerated image editor for massive images.

[petrillic@hachyderm.io]

@azonenberg if you have a Mac/Win machine, give Affinity a spin. I'm pretty sure it uses GPU for a bunch of things. Canva bought it, made it free, and, at least so far, haven't f-d it up.

[azonenberg@ioc.exchange]

@petrillic All of my Windows boxen are VMs and my one mac is a Mini with 16GB of RAM that probably can't even open a file this big much less edit it.

The other thing is, it needs to not assume it can fit the entire image into VRAM. Like, this particular image and workstation combo would probably work (it's ~800mpix, 5 layers, so ~4 Gpix, at RGBA32 that's 16GB and my new GPU has 32GB of VRAM) but anything much bigger would not.

So intelligently managing transfers between CPU and GPU to do the transformations will be part of the requirements for such a tool to avoid getting horribly bottlenecked on PCIe bandwidth

[choofa@infosec.exchange]

@azonenberg how much RAM is used with an image that large + layers ? Is it I/O bound, compute?

[azonenberg@ioc.exchange]

@choofa First order estimate, if it's 5 layers @ 800 Mpix RGBA32, the pixel data should be O(16 GB).

[azonenberg@ioc.exchange]

@choofa But "drawing a polygon on the image to select a region I am later going to crop/flood fill/whatever" should be fast, it's a simple vector operation that doesnt have to touch the pixels at all.

[azonenberg@ioc.exchange]

@choofa When I'm doing something like rotating the image, that's an embarrassingly parallel operation that if properly implemented is mostly memory bound. Some level of care in the order of operations will ensure good cache hit rates, but for the most part every output pixel is independent of every other.

[azonenberg@ioc.exchange]

@choofa Looking at CPU load I see GIMP threading some of the operations while other seem to saturate a single core. I think a lot of it is simply the tool not being designed for handling gigapixel-sized images so operations that are normally negligible run time on smaller images become major bottlenecks because nobody thought to architect it for scalability.

I really am going to end up building a custom tool for this one day, I can feel it. Things like having vector annotations on top of bitmap graphics (I don't need to rasterize text as bitmaps 1:1 with the image resolution), arbitrary multilayer polygon mesh warping... One day.

[azonenberg@ioc.exchange]

A few quick tests:

* One layer visible, turning on another layer: 13 seconds until the new layer is fully drawn. These should be mipmapped at various LODs with the currently visible texture enabled in <1 frame.

* Rotating one layer by 0.2 degrees: 2 min 29 sec for the transform, plus about another 13 sec to redraw after it's done

[azonenberg@ioc.exchange]

Rotating is basically

For each output pixel
* Multiply by a rotation matrix to determine the nominal input pixel location
* Bilinearly interpolate from the four adjacent input pixels since the output is likely not exactly aligned to an input pixel
* Write to the output

So basically you have a couple FMAs for the coordinate transformation, a texture fetch with four memory reads and some weighted averaging, and a texture store.

To a first order for 800mpix this is going to be memory bound with 3.2 Gpix of reading and 800 Mpix of writing. With a good choice of access patterns, cache locality should be decent.

Assuming RGBA32, 3.2 Gpix of fetches with 0% cache hit rate is 12.8 GB of memory reads. This should be doable in well under a second on a modern GPU.

[cliffordheath@mastodon.social]

@azonenberg there should be no matrix math in image rotation. The fast way to do it is two orthogonal shear transforms