API suggestion- thumbnails?

[dobkeratops]

not sure if it already does this, .. would it be possible to serve the current image database as thumbnails e.g. 16x16's so you could get an overview of everything very quickly, along with info for constructing a graph ('image names per label', 'labels per image name')

( looking for fun project ideas, one idea I could pursue is a GL based graph explorer; imagine if the nodes were image thumbnails linked to nodes for labels, and the label-graph, click to expand /zoom in / pin etc. I could use my existing label database for that initially)

[bbernhard]

Do you mean only the images or the images together with its annotations?

Anyway, I think adding such a thing shouldn't be a problem :)

Would you like to have the thumbnails accumumlated in one big (zoomable) image (similar to the Facets Dive tool [1]) or would it be better to provide 16x16 thumbnails for each individual image?

[1] https://research.googleblog.com/2017/07/facets-open-source-visualization-tool.html

[dobkeratops]

Do you mean only the images or the images together with its annotations?

imagine a minimal "thumbnails with ImageID"api - then you can have another api/endpoint for serving "ImageID / annotation info" , and either has utility on it's own. Also you look could around for existing conventions for serving thumbnails (I'm sure this must be a very common requirement)..

On the other hand everything integrated also has benefits.

Would you like to have the thumbnails accumumlated in one big (zoomable) image (similar to the Facets Dive tool [1]) or would it be better to provide 16x16 thumbnails for each individual image?

.. that really depends on the mechanics of serving stuff. 'many small textures' is often a hazard for renderers so a big zoomable image has appeal, but you have to ensure people can calculate the crops correctly (most obvious way is to just stack then top left, increasing across..). A rendering library can always build it's own 'big zoomable image', or even use 'array textures'. So it's a case of whats easier to serve, I guess. Choose the path of minimum resistance.

It is of course possible the Facets tool already provides a superior solution for navigating/visualizing; I seem to remember that showing relations in a grid and being able to swap it around dynamically.

[bbernhard]

Just a quick update:

The donation endpoint is now capable of scaling an image.

e.q: https://api.imagemonkey.io/v1/donation/62d89dfe-3bbc-4a34-887f-ae3ff741e1e8?width=20

Both the width and height query parameter are supported. In case one is left away, it will be set internally to an aspect ratio preserving value.

Together with the export endpoint you can easily build your own image thumbnail overview. The endpoint returns, apart from other data, all the image uuids for a given label. e.q:

https://api.imagemonkey.io/v1/export?query=dog

[dobkeratops]

that sounds great.. I'm curious to know if there's any issue with batching (e.g. 'many small requests' vs 'one big request', analogous to the issues with 'draw calls' in graphics) - but I would imagine the machinery of the web might have a means for dealing with that already (what with pages of images being so common). Any client can choose to assemble/cache the thumbnails however it sees fit (texture atlas? texture-arrays?..)

[bbernhard]

That's indeed a good question.

At the moment there is no caching or whatsoever in place (i.e the file is read from the filesystem, resized to the given dimensions and then served to the user). I am pretty sure that doesn't scale very well if there are more requests, but I went with the easiest solution for now.

I want to add some performance monitoring soon, so that it's possible to detect performance degradations. :)

[dobkeratops]

is this the sort of thing which could be dealt with by a fairly generic 'microservice' (is that jargon right..) e.g. a seperate application (which could be placed on the same box as image monkey ?) which has it's own API ('grab me this list of images as a texture atlas of 16x16 thumbnails') which then communicates with the main application (i.e image monkey) to grab individual images .. a 'texture server', whatever you'd call it ... which can also deal with caching/clustering (I'm thinking back to texture-streaming systems in console games I've worked on, usually the clustering was precalculated with knowledge of the scene but some people tried to make it adaptive in the file system layer, and that might suit the more dynamic/distributed nature of the web)

I wonder if anything like this already exists, given that it must be a common use case (with webgl, and of course plain batches of images).

If something like that doesn't already exist it might be a piece of practice to write in rust independantly, to how it looks using it to build a server (and find any gaps in their image processing libraries)..

perhaps this would also be a nice place to deal with the image segmentation: i.e. make this 'texture server' aware of channels/selections/layered images, interfacing directly with the polygonal annotation information..

EDIT -'ve posted the idea in a rust gamedev forum https://www.reddit.com/r/rust_gamedev/comments/7p6fml/texture_server_any_existing_workscopeinterest/

[bbernhard]

Great idea!

It looks like there is a image proxying server written in Golang [1]. Not sure if that one is suited for our usecase, but it looks definitely promising.

I am myself a huge fan of Redis (I use it quite often for inter-process communications and data caching in all my projects), which theoretically could also be used for caching images.

But you are right, this could be a great opportunity for Rust...:)

perhaps this would also be a nice place to deal with the image segmentation: i.e. make this 'texture server' aware of channels/selections/layered images, interfacing directly with the polygonal annotation information..

that's an awesome idea! If done right and backed by a rich API that's a really cool thing which could offer endless possibilities.

[1] https://github.com/DarthSim/imgproxy