bundle or replace magick

[ungoldman]

imagemagick and graphicsmagick are burdensome external dependencies that don't work well with distributing a bundled desktop application.

The options I see are:

1. find a way to bundle them with the application distribution
2. find a suitable replacement that doesn't require native bindings
3. create a web service to proxy calls to JPA's servers

I'm leaning towards 3 because I feel like if this ever picks up steam it might be the equivalent of a small DDoS attack on JPA's himawari-8 servers, which would not be very nice at all.

What I'm imagining is a server that:

1. gets the latest hi-res images from http://himawari8-dl.nict.go.jp/himawari8 and stitches them together (maybe even doing some color correction based on @celoyd's work) on a cron job or something equivalent
2. accepts a request for the latest Himawari-8 image and returns a cached image that's already been processed

This could probably be accomplished suitably with nginx caching plus a small service to fetch the latest cached image on each request.

[celoyd]

You might consider something based on numpy. This would integrate well with the other python scripts (for HSD→netCDF and TOA). rio color will handle the particular color corrections I’m using.

[Flet]

I like the idea of a service that pre-stitches/caches the image.

I was looking at jimp as an alternative to imagemagick... it has potential!

[ungoldman]

@bcomnes remembering our conversation about bundling native dependencies in electron but forgetting the details -- essentially we'd need to package prebuilt binaries for each target distribution right?