Github user hhbyyh commented on the issue:
https://github.com/apache/spark/pull/19439
@thunterdb Thanks for the reply.
> It does, indirectly: this is what the field types CV_32FXX do. You need
to do some low-level casting to convert the byte array to array of numbers, but
that should not be a limitation for most applications.
The solution may work but I don't think it's an ideal one, at least there's
some performance concern. Another option is that to support all bytes[],
short[], int[], float[] and double[] as data storage type candidates, and
switch among them according to CvType. (Certainly, with more complexity in
code).
But as an initial PR, I'm OK with just supporting it with byte[], and see
if there's further requirement.
> Yes, this feature has been debated. Some developers have had a compelling
need for directly accessing some information about the origin of the image
directly inside the image.
> One of the main reasons is MLlib pipelines: transformers/estimators work
on a single dataframe column; so it is much easier when "origin" is a part of
this column too.
Sure some extra metadata could be found useful. Yet I don't see origin has
a superiority over other meta data like Option[Label], Option[Roi]. I'm mostly
concerned that path info is not really image data in essence, and the info may
become redundant (if there's a path column), stale(if change environment), or
not useful (After converting to OpenCV Mat). @dakirsa, @thunterdb would you
please kindly provide an example that "origin" info is indispensable in image
transformation. Maybe I missed an important scenario.
> Indeed, this feature may not seem that useful at first glance. For some
hadoop file systems though, in which images are accessed in a batched manner,
it is useful to traverse these batches. This is important for performance
reasons. This is why it is marked as experimental for the time being
Does the wildcard matching still work if recursive == false ?
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
