Closed theRoughCode closed 5 years ago
Can you provide a code sample that yields this error?
To answer your question, I don't think there's a good way to know that. It would be dependent on the encoding used and amount of entropy in the image. There is intentionally no method that allocates a buffer because this would create a lot of garbage and slow down Go - buffer reuse is highly recommended.
I totally understand why this was chosen, but it does generate the above error.
newBufferSize := 50 * 1024 * 1024
buffer := make([]byte, newBufferSize)
img.byteArray, err = imgOps.Transform(decoder, options, buffer)
So, currently I have it set to 50MB which is a pretty large size. This works for most images (and is probably a too big of a buffer for a lot of them). However, I've encountered a few edge cases where 50MB is not large enough.
I see that there is a check that ensures that the buffer len is greater than width * height * CV_ELEM_SIZE(pixelType)
. But CV_ELEM_SIZE
is an opencv function. I was wondering if there was a way to know how big of a buffer I'd need to pass in.
What is in options
?
options := &lilliput.ImageOptions{
FileType: "." + img.format,
Width: img.width,
Height: img.height,
ResizeMethod: resizeMethod,
EncodeOptions: map[int]int{
lilliput.JpegQuality: 100,
lilliput.PngCompression: 0,
},
}
Well, I have a feeling that those EncodeOptions
are going to make files much larger than they need to be. PngCompression
will not affect image quality - pngs are lossless. It'll just change how much cpu time is used. 0
will indeed make the files much larger.
Similarly, 100
JpegQuality
would be pretty uncommon. Typical web-quality Jpegs will sit around 75. 85-90 might be more of a "high quality" level. Additional from there will greatly increase the file size for little improvement in quality.
If you do want to use these options, I'd recommend using a larger buffer. These settings will produce very large encoded images.
I see, thanks for the heads-up. So, there is no way to know how big a buffer is needed?
I'm not sure how you could realistically guess that since image compression is so complex. There might be a maximum possible size for a given resolution, but it's going to be extremely large.
Hi team,
I've been encountering this issue when using the library:
buffer too small to hold image
. Is there a way to know how big of a buffer is needed or a way to bypass passing in a buffer?Thanks!