\n\n\n#### About Fly.io\n\nFly is a platform for applications that need to run globally. It runs your code close to users and scales compute in cities where your app is busiest. Write your code, package it into a Docker image, deploy it to Fly's platform and let that do all the work to keep your app snappy.\n\nYou can [learn more](https://fly.io/docs/) about how Fly.io can reduce latency and provide a better experience by serving traffic close to your users location.\n\n#### Global image service tutorial\n\n[Learn more](https://fly.io/docs/app-guides/run-a-global-image-service/) about how to run a custom deployment of imaginary on the Fly.io cloud.\n\n### CloudFoundry\n\nAssuming you have cloudfoundry account, [bluemix](https://console.ng.bluemix.net/) or [pivotal](https://console.run.pivotal.io/) and [command line utility installed](https://github.com/cloudfoundry/cli).\n\nClone this repository:\n```\ngit clone https://github.com/h2non/imaginary.git\n```\n\nPush the application\n```\ncf push -b https://github.com/yacloud-io/go-buildpack-imaginary.git imaginary-inst01 --no-start\n```\n\nDefine the library path\n```\ncf set-env imaginary-inst01 LD_LIBRARY_PATH /home/vcap/app/vendor/vips/lib\n```\n\nStart the application\n```\ncf start imaginary-inst01\n```\n\n### Recommended resources\n\nGiven the multithreaded native nature of Go, in terms of CPUs, most cores means more concurrency and therefore, a better performance can be achieved.\nFrom the other hand, in terms of memory, 512MB of RAM is usually enough for small services with low concurrency (<5 requests/second).\nUp to 2GB for high-load HTTP service processing potentially large images or exposed to an eventual high concurrency.\n\nIf you need to expose `imaginary` as public HTTP server, it's highly recommended to protect the service against DDoS-like attacks.\n`imaginary` has built-in support for HTTP concurrency throttle strategy to deal with this in a more convenient way and mitigate possible issues limiting the number of concurrent requests per second and caching the awaiting requests, if necessary.\n\n### Production notes\n\nIn production focused environments it's highly recommended to enable the HTTP concurrency throttle strategy in your `imaginary` servers.\n\nThe recommended concurrency limit per server to guarantee a good performance is up to `20` requests per second.\n\nYou can enable it simply passing a flag to the binary:\n```\n$ imaginary -concurrency 20\n```\n\n### Memory issues\n\nIn case you are experiencing any persistent unreleased memory issues in your deployment, you can try passing this environemnt variables to `imaginary`:\n\n```\nMALLOC_ARENA_MAX=2 imaginary -p 9000 -enable-url-source\n```\n\n### Graceful shutdown\n\nWhen you use a cluster, it is necessary to control how the deployment is executed, and it is very useful to finish the containers in a controlled.\n\nYou can use the next command:\n\n```\n$ ps auxw | grep 'bin/imaginary' | awk 'NR>1{print buf}{buf = $2}' | xargs kill -TERM > /dev/null 2>&1\n```\n\n### Scalability\n\nIf you're looking for a large scale solution for massive image processing, you should scale `imaginary` horizontally, distributing the HTTP load across a pool of imaginary servers.\n\nAssuming that you want to provide a high availability to deal efficiently with, let's say, 100 concurrent req/sec, a good approach would be using a front end balancer (e.g: HAProxy) to delegate the traffic control flow, ensure the quality of service and distribution the HTTP across a pool of servers:\n\n```\n |==============|\n | Dark World |\n |==============|\n ||||\n |==============|\n | Balancer |\n |==============|\n | |\n / \\\n / \\\n / \\\n /-----------\\ /-----------\\\n | imaginary | | imaginary | (*n)\n \\-----------/ \\-----------/\n```\n\n## Clients\n\n- [node.js](https://github.com/h2non/node-imaginary)\n\nFeel free to send a PR if you created a client for other language.\n\n## Performance\n\nlibvips is probably the faster open source solution for image processing.\nHere you can see some performance test comparisons for multiple scenarios:\n\n- [libvips speed and memory usage](https://github.com/libvips/libvips/wiki/Benchmarks)\n- [bimg](https://github.com/h2non/bimg#Performance) (Go library with C bindings to libvips)\n\n## Benchmark\n\nSee [benchmark.sh](https://github.com/h2non/imaginary/blob/master/benchmark.sh) for more details\n\nEnvironment: Go 1.4.2. libvips-7.42.3. OSX i7 2.7Ghz\n\n```\nRequests [total] 200\nDuration [total, attack, wait] 10.030639787s, 9.949499515s, 81.140272ms\nLatencies [mean, 50, 95, 99, max] 83.124471ms, 82.899435ms, 88.948008ms, 95.547765ms, 104.384977ms\nBytes In [total, mean] 23443800, 117219.00\nBytes Out [total, mean] 175517000, 877585.00\nSuccess [ratio] 100.00%\nStatus Codes [code:count] 200:200\n```\n\n### Conclusions\n\n`imaginary` can deal efficiently with up to 20 request per second running in a multicore machine,\nwhere it crops a JPEG image of 5MB and spending per each request less than 100 ms\n\nThe most expensive image operation under high concurrency scenarios (> 20 req/sec) is the image enlargement, which requires a considerable amount of math operations to scale the original image. In this kind of operation the required processing time usually grows over the time if you're stressing the server continuously. The advice here is as simple as taking care about the number of concurrent enlarge operations to avoid server performance bottlenecks.\n\n## Command-line usage\n\n```\nUsage:\n imaginary -p 80\n imaginary -cors\n imaginary -concurrency 10\n imaginary -path-prefix /api/v1\n imaginary -enable-url-source\n imaginary -disable-endpoints form,health,crop,rotate\n imaginary -enable-url-source -allowed-origins http://localhost,http://server.com,http://*.example.org\n imaginary -enable-url-source -enable-auth-forwarding\n imaginary -enable-url-source -authorization \"Basic AwDJdL2DbwrD==\"\n imaginary -enable-placeholder\n imaginary -enable-url-source -placeholder ./placeholder.jpg\n imaginary -enable-url-signature -url-signature-key 4f46feebafc4b5e988f131c4ff8b5997\n imaginary -enable-url-source -forward-headers X-Custom,X-Token\n imaginary -h | -help\n imaginary -v | -version\n\nOptions:\n -a Bind address [default: *]\n -p Bind port [default: 8088]\n -h, -help Show help\n -v, -version Show version\n -path-prefix Url path prefix to listen to [default: \"/\"]\n -cors Enable CORS support [default: false]\n -gzip Enable gzip compression (deprecated) [default: false]\n -disable-endpoints Comma separated endpoints to disable. E.g: form,crop,rotate,health [default: \"\"]\n -key Define API key for authorization\n -mount Mount server local directory\n -http-cache-ttl The TTL in seconds. Adds caching headers to locally served files.\n -http-read-timeout HTTP read timeout in seconds [default: 30]\n -http-write-timeout HTTP write timeout in seconds [default: 30]\n -enable-url-source Enable remote HTTP URL image source processing (?url=http://..)\n -enable-placeholder Enable image response placeholder to be used in case of error [default: false]\n -enable-auth-forwarding Forwards X-Forward-Authorization or Authorization header to the image source server. -enable-url-source flag must be defined. Tip: secure your server from public access to prevent attack vectors\n -forward-headers Forwards custom headers to the image source server. -enable-url-source flag must be defined.\n -enable-url-signature Enable URL signature (URL-safe Base64-encoded HMAC digest) [default: false]\n -url-signature-key The URL signature key (32 characters minimum)\n -allowed-origins Restrict remote image source processing to certain origins (separated by commas). Note: Origins are validated against host *AND* path.\n -max-allowed-size Restrict maximum size of http image source (in bytes)\n -certfile TLS certificate file path\n -keyfile TLS private key file path\n -authorization Defines a constant Authorization header value passed to all the image source servers. -enable-url-source flag must be defined. This overwrites authorization headers forwarding behavior via X-Forward-Authorization\n -placeholder Image path to image custom placeholder to be used in case of error. Recommended minimum image size is: 1200x1200\n -concurrency Throttle concurrency limit per second [default: disabled]\n -burst Throttle burst max cache size [default: 100]\n -mrelease OS memory release interval in seconds [default: 30]\n -cpus Number of used cpu cores.\n (default for current machine is 8 cores)\n -log-level Set log level for http-server. E.g: info,warning,error [default: info].\n Or can use the environment variable GOLANG_LOG=info.\n```\n\nAll command line flags have environment variable equivalents. For example the env variable ENABLE_URL_SOURCE can be used\nto configure -enable-url-source\n\nStart the server in a custom port:\n```bash\nimaginary -p 8080\n```\n\nAlso, you can pass the port as environment variable:\n```bash\nPORT=8080 imaginary\n```\n\nEnable HTTP server throttle strategy (max 10 requests/second):\n```\nimaginary -p 8080 -concurrency 10\n```\n\nEnable remote URL image fetching (then you can do GET request passing the `url=http://server.com/image.jpg` query param):\n```\nimaginary -p 8080 -enable-url-source\n```\n\nMount local directory (then you can do GET request passing the `file=image.jpg` query param):\n```\nimaginary -p 8080 -mount ~/images\n```\n\nEnable authorization header forwarding to image origin server. `X-Forward-Authorization` or `Authorization` (by priority) header value will be forwarded as `Authorization` header to the target origin server, if one of those headers are present in the incoming HTTP request.\nSecurity tip: secure your server from public access to prevent attack vectors when enabling this option:\n```\nimaginary -p 8080 -enable-url-source -enable-auth-forwarding\n```\n\nOr alternatively you can manually define an constant Authorization header value that will be always sent when fetching images from remote image origins. If defined, `X-Forward-Authorization` or `Authorization` headers won't be forwarded, and therefore ignored, if present.\n**Note**:\n```\nimaginary -p 8080 -enable-url-source -authorization \"Bearer s3cr3t\"\n```\n\nSend fixed caching headers in the response. The headers can be set in either \"cache nothing\" or \"cache for N seconds\". By specifying `0` imaginary will send the \"don't cache\" headers, otherwise it sends headers with a TTL. The following example informs the client to cache the result for 1 year:\n```\nimaginary -p 8080 -enable-url-source -http-cache-ttl 31556926\n```\n\nEnable placeholder image HTTP responses in case of server error/bad request.\nThe placeholder image will be dynamically and transparently resized matching the expected image `width`x`height` define in the HTTP request params.\nAlso, the placeholder image will be also transparently converted to the desired image type defined in the HTTP request params, so the API contract should be maintained as much better as possible.\n\nThis feature is particularly useful when using `imaginary` as public HTTP service consumed by Web clients.\nIn case of error, the appropriate HTTP status code will be used to reflect the error, and the error details will be exposed serialized as JSON in the `Error` response HTTP header, for further inspection and convenience for API clients.\n```\nimaginary -p 8080 -enable-placeholder -enable-url-source\n```\n\nYou can optionally use a custom placeholder image.\nSince the placeholder image should fit a variety of different sizes, it's recommended to use a large image, such as `1200`x`1200`.\nSupported custom placeholder image types are: `JPEG`, `PNG` and `WEBP`.\n```\nimaginary -p 8080 -placeholder=placeholder.jpg -enable-url-source\n```\n\nEnable URL signature (URL-safe Base64-encoded HMAC digest).\n\nThis feature is particularly useful to protect against multiple image operations attacks and to verify the requester identity.\n```\nimaginary -p 8080 -enable-url-signature -url-signature-key 4f46feebafc4b5e988f131c4ff8b5997\n```\n\nIt is recommanded to pass key as environment variables:\n```\nURL_SIGNATURE_KEY=4f46feebafc4b5e988f131c4ff8b5997 imaginary -p 8080 -enable-url-signature\n```\n\nIncrease libvips threads concurrency (experimental):\n```\nVIPS_CONCURRENCY=10 imaginary -p 8080 -concurrency 10\n```\n\nEnable debug mode:\n```\nDEBUG=* imaginary -p 8080\n```\n\nOr filter debug output by package:\n```\nDEBUG=imaginary imaginary -p 8080\n```\n\nDisable info logs:\n```\nGOLANG_LOG=error imaginary -p 8080\n```\n\n#### Examples\n\nReading a local image (you must pass the `-mount=` flag):\n```\ncurl -O \"http://localhost:8088/crop?width=500&height=400&file=foo/bar/image.jpg\"\n```\n\nFetching the image from a remote server (you must pass the `-enable-url-source` flag):\n```\ncurl -O \"http://localhost:8088/crop?width=500&height=400&url=https://raw.githubusercontent.com/h2non/imaginary/master/testdata/large.jpg\"\n```\n\nCrop behaviour can be influenced with the `gravity` parameter. You can specify a preference for a certain region (north, south, etc.). To enable Smart Crop you can specify the value \"smart\" to autodetect the most interesting section to consider as center point for the crop operation:\n```\ncurl -O \"http://localhost:8088/crop?width=500&height=200&gravity=smart&url=https://raw.githubusercontent.com/h2non/imaginary/master/testdata/smart-crop.jpg\"\n```\n\n\n#### Playground\n\n`imaginary` exposes an ugly HTML form for playground purposes in: [`http://localhost:8088/form`](http://localhost:8088/form)\n\n## HTTP API\n\n### Allowed Origins\n\nimaginary can be configured to block all requests for images with a src URL this is not specified in the `allowed-origins` list. Imaginary will validate that the remote url matches the hostname and path of at least one origin in allowed list. Perhaps the easiest way to show how this works is to show some examples.\n\n| `allowed-origins` setting | image url | is valid |\n| ------------------------- | --------- | -------- |\n| `--allowed-origins s3.amazonaws.com/some-bucket/` | `s3.amazonaws.com/some-bucket/images/image.png` | VALID |\n| `--allowed-origins s3.amazonaws.com/some-bucket/` | `s3.amazonaws.com/images/image.png` | NOT VALID (no matching basepath) |\n| `--allowed-origins s3.amazonaws.com/some-*` | `s3.amazonaws.com/some-bucket/images/image.png` | VALID |\n| `--allowed-origins *.amazonaws.com/some-bucket/` | `anysubdomain.amazonaws.com/some-bucket/images/image.png` | VALID |\n| `--allowed-origins *.amazonaws.com` | `anysubdomain.amazonaws.comimages/image.png` | VALID |\n| `--allowed-origins *.amazonaws.com` | `www.notaws.comimages/image.png` | NOT VALID (no matching host) |\n| `--allowed-origins *.amazonaws.com, foo.amazonaws.com/some-bucket/` | `bar.amazonaws.com/some-other-bucket/image.png` | VALID (matches first condition but not second) |\n\n### Authorization\n\nimaginary supports a simple token-based API authorization.\nTo enable it, you should pass the `-key` flag to the binary.\n\nAPI token can be defined as HTTP header (`API-Key`) or query param (`key`).\n\nExample request with API key:\n```\nPOST /crop HTTP/1.1\nHost: localhost:8088\nAPI-Key: secret\n```\n\n### URL signature\n\nThe URL signature is provided by the `sign` request parameter.\n\nThe HMAC-SHA256 hash is created by taking the URL path (including the leading /), the request parameters (alphabetically-sorted and concatenated with & into a string). The hash is then base64url-encoded.\n\nHere an example in Go:\n```\nsignKey := \"4f46feebafc4b5e988f131c4ff8b5997\"\nurlPath := \"/resize\"\nurlQuery := \"file=image.jpg&height=200&type=jpeg&width=300\"\n\nh := hmac.New(sha256.New, []byte(signKey))\nh.Write([]byte(urlPath))\nh.Write([]byte(urlQuery))\nbuf := h.Sum(nil)\n\nfmt.Println(\"sign=\" + base64.RawURLEncoding.EncodeToString(buf))\n```\n\n### Errors\n\n`imaginary` will always reply with the proper HTTP status code and JSON body with error details.\n\nHere an example response error when the payload is empty:\n```json\n{\n \"message\": \"Cannot read payload: no such file\",\n \"code\": 1\n}\n```\n\nSee all the predefined supported errors [here](https://github.com/h2non/imaginary/blob/master/error.go#L19-L28).\n\n#### Placeholder\n\nIf `-enable-placeholder` or `-placeholder ` flags are passed to `imaginary`, a placeholder image will be used in case of error or invalid request input.\n\nIf `-enable-placeholder` is passed, the default `imaginary` placeholder image will be used, however you can customized it via `-placeholder` flag, loading a custom compatible image from the file system.\n\nSince `imaginary` has been partially designed to be used as public HTTP service, including web pages, in certain scenarios the response MIME type must be respected,\nso the server will always reply with a placeholder image in case of error, such as image processing error, read error, payload error, request invalid request or any other.\n\nYou can customize the placeholder image passing the `-placeholder ` flag when starting `imaginary`.\n\nIn this scenarios, the error message details will be exposed in the `Error` response header field as JSON for further inspection from API clients.\n\nIn some edge cases the placeholder image resizing might fail, so a 400 Bad Request will be used as response status and the `Content-Type` will be `application/json` with the proper message info. Note that this scenario won't be common.\n\n### Form data\n\nIf you're pushing images to `imaginary` as `multipart/form-data` (you can do it as well as `image/*`), you must define at least one input field called `file` with the raw image data in order to be processed properly by imaginary.\n\n### Params\n\nComplete list of available params. Take a look to each specific endpoint to see which params are supported.\nImage measures are always in pixels, unless ","has_starred","hub_user","immutable_tags_settings",{"_75":11,"_76":77},"enabled","rules",[78],".*","is_automated","permissions",{"_82":21,"_83":11,"_84":11},"read","write","admin","user","storage_size",342343064,"orgData",{"_90":91,"_92":93,"_94":95,"_96":33,"_97":98,"_99":100,"_101":102,"_103":104,"_105":106,"_107":98,"_108":98,"_109":98,"_110":21},"id","fd8e74e5d3d8495a9918272380c76566","uuid","fd8e74e5-d3d8-495a-9918-272380c76566","type","organization","orgname","full_name","","location","Almelo, NL","company","Recognize","profile_url","https://recognize.nl","date_joined","2018-05-28T15:03:25.768498Z","gravatar_url","gravatar_email","badge","is_active","recentTags",[113],{"_114":44,"_115":116,"_117":118,"_90":119,"_120":121,"_50":138,"_139":116,"_140":33,"_141":56,"_57":142,"_143":144,"_145":129,"_146":138,"_147":66,"_148":21},"content_type","creator",3180022,"full_size",95993038,101234721,"images",[122],{"_123":124,"_125":126,"_127":98,"_128":129,"_130":131,"_132":133,"_134":98,"_135":-5,"_136":118,"_63":66,"_137":-5},"architecture","amd64","digest","sha256:1ecc84b18ad595b26549fbf95e12ae367e448baa020bf17bec4d7d18b4110881","features","last_pulled","2026-10-04T02:52:47.942523321Z","last_pushed","2020-12-23T10:37:40Z","os","linux","os_features","os_version","size","variant","2020-12-23T10:37:39.358314Z","last_updater","last_updater_username","media_type","latest","repository",9081089,"tag_last_pulled","tag_last_pushed","tag_status","v2","sbxKitMetadata","isPotentialSpam","isHubSbxKitsEnabled","showSbxLogoOverride","sbxTrademarkText","displaySecurityMetadata","tagAttestations","tagsHaveAttestations",[],"selectedTag","attestationsUrl","routes/_layout.r.$namespace.$reponame.tags",{"_38":162,"_169":170,"_156":179,"_180":11},{"_40":163,"_42":164,"_45":46,"_47":48,"_49":11,"_50":51,"_52":53,"_54":165,"_57":35,"_32":33,"_58":59,"_60":44,"_61":62,"_63":64,"_65":66,"_67":-5,"_68":62,"_69":70,"_71":11,"_72":33,"_73":166,"_79":11,"_80":168,"_85":33,"_86":87},[],[44],[56],{"_75":11,"_76":167},[78],{"_82":21,"_83":11,"_84":11},"tags",{"_171":64,"_172":-5,"_173":-5,"_174":175},"count","next","previous","results",[176],{"_114":44,"_115":116,"_117":118,"_90":119,"_120":177,"_50":138,"_139":116,"_140":33,"_141":56,"_57":142,"_143":144,"_145":129,"_146":138,"_147":66,"_148":21},[178],{"_123":124,"_125":126,"_127":98,"_128":129,"_130":131,"_132":133,"_134":98,"_135":-5,"_136":118,"_63":66,"_137":-5},[],"canDeleteTags","actionData","errors"]

recognizebv/imaginary

Tags for recognizebv/imaginary