Mark van der Velden
Mark van der Velden
Your request is a bit brief, perhaps if you could elaborate more about what you want and why you want it that we can formulate a better answer.
Personally I don't see performance as a super relevant reason. There are many aspects of an Image scaling services that is pretty heavy in terms of resources. I hardly think...
Personally I like seeing that health checks actually happen and work as intended. If you want to filter them out you can use the common practices of grep and/or apply...
Not too unsurprisingly, [two tests fail](https://travis-ci.org/h2non/imaginary/builds/495844234?utm_source=github_status&utm_medium=notification) because of this change. The question is, what is correct: ``` --- FAIL: TestCalculateDestinationFitDimension (0.00s) image_test.go:104: Fit dimensions calculation failure Expected : 710/555 (width/height)...
When I look at the implementation in libvips, it's way more complicated and contains many more decision branches (including: https://github.com/libvips/libvips/blob/1a836052385c220ad32f9ce0c9a3363f1f919ad6/libvips/arithmetic/max.c#L534). I think we should proceed with leaning more on vips_thumbnail_buffer()...
@evrenkutar the fix isn't "correct" for all situations, which is why we haven't merged it in yet. Great if it works for your situation, but be careful :-)
Imaginary should actually respect the aspect-ratio, but this part is a tad bit confusing. Try specifying the `nocrop=true` parameter and omit the height. This works for me: ``` http://localhost:9000/resize?width=400&nocrop=true&stripmeta=true&quality=70&url=https%3A%2F%2Fimages.unsplash.com%2Fphoto-1546662654-5029c0524efa%3Fixlib%3Drb-1.2.1%26ixid%3DeyJhcHBfaWQiOjEyMDd9%26auto%3Dformat%26fit%3Dcrop%26w%3D1834%26q%3D80 ```...
I agree it is and I think it can even be considered a bug, but we need to dive into that first. With image manipulation things aren't always that simple...
Can you solve it using [pipelining](https://github.com/h2non/imaginary#get--post-pipeline)?
I wonder if this should be part of Imaginary. I would love to see a clear module API in Imaginary, however it's easy to fork Imaginary and implement the features...