getBoundingBox<Channels>(img_data, padding_condition, minimum_non_padding_value?): Rect
get the bounding box Rect of an image, based on an accumulative padding_condition function that should return
0.0 for padding/whitespace/empty pixels, and positive numbers (usually 1.0) for non-padding/important pixels.
if the summation of padding_condition applied onto a particular row, or column of pixels is less than
minimum_non_padding_value, then that entire row/column will be counted as an empty padding space.
else if the summation of padding_condition is greater than minimum_non_padding_value, then that specific
row/column will be counted as one of the bounding box's sides.
take a look at trimImagePadding to get an understanding of a potential use case.
you do not need to specify the number of channels in your img_data, because it will be calculated automatically
via img_data.width, img_data.height, and img_data.data.length
almost all performance depends purely on the complexity of your padding_condition
if the equations in padding_condition use square-roots, exponents, if conditions, then expect a major performance drop
if your equations consist only of +, -, *, /, then the performance will be much faster.
I've benchmarked this function, and defining rowAt, colAt, and nonPaddingValue outside of this function, instead of
inlining them makes no difference.
also, substituting padding_condition in nonPaddingValue with the actual arithmetic function via inlining (and thus
avoiding constant function calls) makes no difference, thanks to JIT doing the inlining on its own in V8.
finally, the colAt inline function is surprisingly super fast (close to rowAt). and so, bounding top and bottom
is not at all visibly quicker than bounding left and right.
get the bounding box Rect of an image, based on an accumulative
padding_conditionfunction that should return0.0for padding/whitespace/empty pixels, and positive numbers (usually1.0) for non-padding/important pixels.if the summation of
padding_conditionapplied onto a particular row, or column of pixels is less thanminimum_non_padding_value, then that entire row/column will be counted as an empty padding space.else if the summation of
padding_conditionis greater thanminimum_non_padding_value, then that specific row/column will be counted as one of the bounding box's sides.take a look at trimImagePadding to get an understanding of a potential use case.
you do not need to specify the number of channels in your
img_data, because it will be calculated automatically viaimg_data.width,img_data.height, andimg_data.data.lengtha note on performance
almost all performance depends purely on the complexity of your
padding_conditionif the equations in
padding_conditionuse square-roots, exponents, if conditions, then expect a major performance dropif your equations consist only of
+, -, *, /, then the performance will be much faster.I've benchmarked this function, and defining
rowAt,colAt, andnonPaddingValueoutside of this function, instead of inlining them makes no difference.also, substituting
padding_conditioninnonPaddingValuewith the actual arithmetic function via inlining (and thus avoiding constant function calls) makes no difference, thanks to JIT doing the inlining on its own in V8.finally, the
colAtinline function is surprisingly super fast (close torowAt). and so, bounding top and bottom is not at all visibly quicker than bounding left and right.