Right now we only support taking a (url to) file blob as input.
This means that we always download and process the entire image, even if we're only interested in a subset of the image (requested output is based on a low-resolution crop of input).
GEGL has capability of doing mipmapped processing via the scale parameter of GeglProcessor, which we are not yet making use of.
But to optimize also the download/network aspects, we'd need to have a tiled mipmap representation of the image instead of just (urls to) file blobs.
This could for instance be done via ipld-image, which would require API consumers to make use of IPFS to use this capability. Since this is a significant addition, it may be best if imgflo-server expose a HTTP API to create the image representation from either a input URL, or even from a file.
Right now we only support taking a (url to) file blob as input. This means that we always download and process the entire image, even if we're only interested in a subset of the image (requested output is based on a low-resolution crop of input). GEGL has capability of doing mipmapped processing via the
scale
parameter ofGeglProcessor
, which we are not yet making use of.But to optimize also the download/network aspects, we'd need to have a tiled mipmap representation of the image instead of just (urls to) file blobs.
This could for instance be done via ipld-image, which would require API consumers to make use of IPFS to use this capability. Since this is a significant addition, it may be best if imgflo-server expose a HTTP API to create the image representation from either a input URL, or even from a file.
http://iiif.io/api/image/2.0 is another alternative to consider