I really don't need a new project, but I would love a clustered and/or GPU accelerated image editor for massive images.
-
I really don't need a new project, but I would love a clustered and/or GPU accelerated image editor for massive images.
Something that can comfortably and performantly rotate, crop, layer stack, align, etc. images at gigapixel scale without bogging down for minutes at a time even on my big iron.
Across my lab I can harness something like 160 physical / 320 logical CPU cores, 1.3 TB of RAM, 50+ GB of VRAM, and more shader cores than I feel like counting.
Everything is or will soon (after I swap a few NICs) be connected by 40/100GbE.
Deleting part of a layer in an 0.8 gigapixel image with five layers, with that much compute available, doesn't seem like it should be the kind of thing I have to sit and watch GIMP updating scanline by scanline.
Like even drawing a selection on parts of this image is making GIMP slow. it's just a list of polygon vertices for the outlined area, this should be *trivial*. Especially since dragging to make a selection can't have a resolution greater than the currently displayed pixel size.
-
Like even drawing a selection on parts of this image is making GIMP slow. it's just a list of polygon vertices for the outlined area, this should be *trivial*. Especially since dragging to make a selection can't have a resolution greater than the currently displayed pixel size.
@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 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.
@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
-
Like even drawing a selection on parts of this image is making GIMP slow. it's just a list of polygon vertices for the outlined area, this should be *trivial*. Especially since dragging to make a selection can't have a resolution greater than the currently displayed pixel size.
@azonenberg how much RAM is used with an image that large + layers ? Is it I/O bound, compute?
-
@azonenberg how much RAM is used with an image that large + layers ? Is it I/O bound, compute?
@choofa First order estimate, if it's 5 layers @ 800 Mpix RGBA32, the pixel data should be O(16 GB).
-
@choofa First order estimate, if it's 5 layers @ 800 Mpix RGBA32, the pixel data should be O(16 GB).
@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.
-
@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.
@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.
-
@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.
@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.
-
Like even drawing a selection on parts of this image is making GIMP slow. it's just a list of polygon vertices for the outlined area, this should be *trivial*. Especially since dragging to make a selection can't have a resolution greater than the currently displayed pixel size.
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
-
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
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 outputSo 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.
-
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 outputSo 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.
@azonenberg there should be no matrix math in image rotation. The fast way to do it is two orthogonal shear transforms
