[HN Gopher] Imagor: A fast, Docker-ready image processing server...
       ___________________________________________________________________
        
       Imagor: A fast, Docker-ready image processing server written in Go
        
       Author : thunderbong
       Score  : 85 points
       Date   : 2021-12-10 19:25 UTC (3 hours ago)
        
 (HTM) web link (github.com)
 (TXT) w3m dump (github.com)
        
       | cosmotic wrote:
       | "image processing" in the context of docker is very confusing.
       | This should be "Docker-ready graphics processing server"
        
       | zsolt224 wrote:
       | So how does it compare to Imaginary?
       | 
       | It looks Imagor can save/cache the resulting files in S3. If so
       | that's a great benefit since Imaginary does not support it and
       | you have to use a CDN.
       | 
       | Do I understand it correctly that Imagor can transform the image
       | from URL and store the results to S3 and next time the same image
       | is requested it is not transformed again but returned from S3?
        
       | clon wrote:
       | libvips is great! The performance is so good you can probably
       | process your images on the fly. Can't recommend it enough.
        
       | svacko wrote:
       | There is also battle-tested imaginary tool [1], offering similar
       | functionality and much more, also using libvips
       | 
       | [1] https://github.com/h2non/imaginary
        
       | cjblomqvist wrote:
       | How does it compare with imgproxy? Seems to be the same (libvips
       | wrapper as docker container) but less polish?
        
       | tbarbugli wrote:
       | It would be great to see a cache layer in front of S3, in my
       | experience fetching the original image from S3 will be slower
       | than the actual resizing (regardless of the library used) and
       | that happens at least once.
       | 
       | So ideally something like:
       | 
       | 1. upload to s3
       | 
       | 2. manipulate image to a friendly size (ie. 2048x2048)
       | 
       | 3. write the image to an LRU cache (ie. memcached)
       | 
       | with steps 2 and 3 on a separate go-routine
       | 
       | Besides that, really cool project :)
        
         | orf wrote:
         | Isn't that cloudfront?
        
       | jrockway wrote:
       | I don't see any documentation around libvps that claims it's safe
       | to run on untrusted inputs, so you might want to run this thing
       | in gVisor or a dedicated VM if that's your plan.
       | 
       | (I also looked for fuzz tests up the chain; libvips -> govips ->
       | imagor, and didn't find any.)
        
         | clon wrote:
         | For what it's worth, libvips is part of OSS fuzz
         | 
         | https://github.com/google/oss-fuzz/tree/a21768ce6a5056d27f82...
         | 
         | I thought they mostly fuzz the loaders, which are the most
         | critical, apparently the found bugs present a picture of a
         | pretty wide coverage:
         | 
         | https://bugs.chromium.org/p/oss-fuzz/issues/list?can=1&q=Lib...
         | 
         |  _As of June 2021, OSS-Fuzz has found over 30,000 bugs in 500
         | open source projects._
        
           | jrockway wrote:
           | Ah, very nice! I should have checked there.
        
         | fragmede wrote:
         | quite. inside docker, on a VPS with only other instances of
         | that container running, uploading to an S3 bucket using IAM
         | write-only privs, and the instance gets automatically cycled
         | every hour.
        
           | thebruce87m wrote:
           | Only every hour? I see you like to take risks.
        
       ___________________________________________________________________
       (page generated 2021-12-10 23:00 UTC)