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 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.
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 return0.0
for padding/whitespace/empty pixels, and positive numbers (usually1.0
) for non-padding/important pixels.if the summation of
padding_condition
applied 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_condition
is 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.length
a note on performance
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 dropif your equations consist only of
+, -, *, /
, then the performance will be much faster.I've benchmarked this function, and defining
rowAt
,colAt
, andnonPaddingValue
outside of this function, instead of inlining them makes no difference.also, substituting
padding_condition
innonPaddingValue
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 torowAt
). and so, bounding top and bottom is not at all visibly quicker than bounding left and right.