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.
A note on performance
almost all performance depends purely on the complexity of your padding_condition.
if the equations in padding_condition uses square-roots, exponents, and if-conditions, then expect a major performance drop.
if your equations consist only of only numeric operations +, -, *, /, then the performance will be much faster.
some unsuccessful benchmarks I've tried to boost the performance (in V8):
defining rowAt, colAt, and nonPaddingValue outside of this function, instead of inlining them, made no difference in the performance.
substituting padding_condition in nonPaddingValue with the actual arithmetic functions via inlining
(and thereby avoiding repeated function calls) makes no difference, thanks to the JIT doing the inlining on its own in V8.
finally, the colAt inline function is surprisingly super fast (almost as fast as rowAt).
so, bounding top and bottom is not at all noticeably 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.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.padding_conditionis greater thanminimum_non_padding_value, then that specific row/column will be counted as one of the bounding box's sides.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.length.A note on performance
almost all performance depends purely on the complexity of your
padding_condition.padding_conditionuses square-roots, exponents, and if-conditions, then expect a major performance drop.+, -, *, /, then the performance will be much faster.some unsuccessful benchmarks I've tried to boost the performance (in V8):
rowAt,colAt, andnonPaddingValueoutside of this function, instead of inlining them, made no difference in the performance.padding_conditioninnonPaddingValuewith the actual arithmetic functions via inlining (and thereby avoiding repeated function calls) makes no difference, thanks to the JIT doing the inlining on its own in V8.colAtinline function is surprisingly super fast (almost as fast asrowAt). so, bounding top and bottom is not at all noticeably quicker than bounding left and right.