imaginary
imaginary copied to clipboard
h2non
`embed` option is hardcoded irrespective of user input
https://github.com/h2non/imaginary/blob/master/image.go#L148
this line sets o.Embed=true while converting from imaginary.Options to bimg.Options, irrespective of what user provided via /fit endpoint.
is this intentional?
why I care? It affects the image output of /fit endpoint with black border.
example:
Case:1 - works fine original image resolution: 506x900, requested: 1860x1240, actual output: 825x1240 (maintaining the aspect ratio)
http://localhost:8080/fit?width=1860&height=1240&url=<CDN-URL>
Case:2 - Not working - Have black border
original image resolution: 4608x3072, requested: 1860x1240, actual output: 1860x1240
http://localhost:8080/fit?width=1860&height=1240&url=<CDN-URL>
NOTE: In both cases aspect ratio is maintained, irrespective of requested width and height (meaning no force)
My expected behaviour is, there shouldn't be black border on the second image.
This behaviour happens, https://github.com/h2non/bimg/blob/master/resizer.go#L275 when o.Embed is true.
which is why I'm concerned why its setting as true as hardcoding.
Case 3: Working fine, if extendOrExtrac() is called with o.Extend=false. (my expected behaviour)
Original resolution: 4608x3072, requested: 1860x1240, actual output: 827x1240
http://localhost:8080/fit?width=1860&height=1240&url=<CDN-URL>
I'm aware that this background color can be controlled via extend=5&background=r,g,b params, but I want it without any border. Any opinions are welcome. Please correct me if I'm missing anything.
NOTE: Also one may argue, since it is /fit endpoint, so the output is filled with background to make it size fit as requested by user, but its not because, even on the first example, the output size is not exactly the requested ones, the aspect ration is maintained anyway.
Another Observation: We can't just remove hardcoding o.Embed=true, because this also plays role in setting o.Force=true via
https://github.com/h2non/bimg/blob/master/resizer.go#L183-L186
