You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered: