Without knowing anything about this, I wonder if standards are trying to work at the wrong level of abstraction. Like worrying about whether to use GIF or PNG to compress map images, when really it would be better to standardize the underlying data like OpenStreetMap. A better goal might be to decide on a single container format for discrete cosine transform (DCT) data in compressed images like how JPEG works.
We probably need a multidimensional lossy compression scheme for 2D images, 3D volumes/video, and 4+D metadata involving multiple spectrums, exposures, etc. I'd probably start with a multidimensional DCT with a way to specify the coefficients/weights of each layer and metadata (optionally losslessly):
https://en.wikipedia.org/wiki/Discrete_cosine_transform#Mult...
Looks like that's built into MATLAB with dct(x,n,dim):
https://www.mathworks.com/help/signal/ref/dct.html
https://www.mathworks.com/help/images/ref/blockproc.html (coefficients)
https://www.mathworks.com/help/images/discrete-cosine-transf... (2D example)
Then store the data in zipped JSON or BSON, or maybe TAR then ZIP.
Then I'd write an importer and exporter from/to all of the other formats, with a single 0-1 quality argument or maybe an array of qualities for each layer, with a way to specify coefficients or load them from files.
Once a known-good implementation worked, I'd add additional compression schemes that can compress across dimensions, so that a level of zoom only has to save a diff from a previous layer at a slightly different scale or focus (like a 3+D MPEG format, this is probably the standard that we're currently missing, does anyone know of one?).
This all seems fairly straightforward though, so I wonder if proprietary software patents are the real blocker..
We probably need a multidimensional lossy compression scheme for 2D images, 3D volumes/video, and 4+D metadata involving multiple spectrums, exposures, etc. I'd probably start with a multidimensional DCT with a way to specify the coefficients/weights of each layer and metadata (optionally losslessly):
https://en.wikipedia.org/wiki/Discrete_cosine_transform#Mult...
Looks like that's built into MATLAB with dct(x,n,dim):
https://www.mathworks.com/help/signal/ref/dct.html
https://www.mathworks.com/help/images/ref/blockproc.html (coefficients)
https://www.mathworks.com/help/images/discrete-cosine-transf... (2D example)
Then store the data in zipped JSON or BSON, or maybe TAR then ZIP.
Then I'd write an importer and exporter from/to all of the other formats, with a single 0-1 quality argument or maybe an array of qualities for each layer, with a way to specify coefficients or load them from files.
Once a known-good implementation worked, I'd add additional compression schemes that can compress across dimensions, so that a level of zoom only has to save a diff from a previous layer at a slightly different scale or focus (like a 3+D MPEG format, this is probably the standard that we're currently missing, does anyone know of one?).
This all seems fairly straightforward though, so I wonder if proprietary software patents are the real blocker..