[Scala][Clojure] Fix problem with some OSX not handling the cast on imDecode

[gigasquid]

Description

My OSX system was having a problem running the Scala function in the Image package imDecode.
When running the Scala unit tests it would error out with:

ImageSuite:
- Test load image
[19:13:09] src/io/image_io.cc:147: Decoding failed. Invalid image file.
2018-11-07 19:13:09,666 [ScalaTest-main-running-ImageSuite] [org.apache.mxnet.ImageSuite] [INFO] - OpenCV load image with shape: ()
2018-11-07 19:13:09,671 [ScalaTest-main-running-ImageSuite] [org.apache.mxnet.ImageSuite] [INFO] - OpenCV resize image with shape: (224,224,3)
- Test load image from Socket *** FAILED ***
  java.lang.IllegalArgumentException: requirement failed: image shape not Match!
  at scala.Predef$.require(Predef.scala:224)
  at org.apache.mxnet.ImageSuite$$anonfun$3.apply$mcV$sp(ImageSuite.scala:69)
  at org.apache.mxnet.ImageSuite$$anonfun$3.apply(ImageSuite.scala:64)
  at org.apache.mxnet.ImageSuite$$anonfun$3.apply(ImageSuite.scala:64)

After some investigation with @lanking520 , I found that adding an explicit conversion of the byte to an int before creating the NDArray solved the issue.

Checklist

Essentials

Please feel free to remove inapplicable items for your PR.

• Changes are complete (i.e. I finished coding on this PR)
• All changes have test coverage:
• Unit tests are added for small changes to verify correctness (e.g. adding a new operator)
• Nightly tests are added for complicated/long-running ones (e.g. changing distributed kvstore)
• Build tests will be added for build configuration changes (e.g. adding a new build option with NCCL)
• Code is well-documented:
• For user-facing API changes, API doc string has been updated.
• For new C++ functions in header files, their functionalities and arguments are documented.
• For new examples, README.md is added to explain the what the example does, the source of the dataset, expected performance on test set and reference to the original paper if applicable
• Check the API doc at http://mxnet-ci-doc.s3-accelerate.dualstack.amazonaws.com/PR-$PR_ID/$BUILD_ID/index.html
• To the my best knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes

Small tweak to the Scala function in imDecode

This is also relevant to #13107

[lanking520]

Thanks for your help finding this hidden bugs! It reminds me of the Digital Eletronics class back to school. https://stackoverflow.com/questions/14713102/what-does-and-0xff-do

[marcoabreu]

I can remember quite a few issues where people reported the same error about apparently invalid image files. I'm not sure whether it was related to Scala, but this is a great catch! Thanks Carin.

[lanking520]

@marcoabreu @gigasquid I do think there might be an issue with a different operating system. The things that make me suspicious is that: In theory, a byte & 0xFF would only bring the positive result. The signed bit has been disabled for that. However, when I feed the positive float data and cast them as uint8. The converted float data from uint8 contains negative values:

The flow is like this:

byte AND 0xFF -> All positive float

float cast uint8 -> uint8

uint8 cast float -> Contains negative value???

@frankfliu since he raised this concern during our offline conversation

[gigasquid]

@lanking520 - I'm thinking that might be just a printing display thing? I can't see how a uint8 ndarray could have negative values. Do you know of a way to test that?

[nswamy]

I haven't followed the entire conversation, but just a reminder that mxnet Scala supports only float32

…

On Nov 9, 2018, at 6:30 PM, Carin Meier ***@***.***> wrote: @lanking520 - I'm thinking that might be just a printing display thing? I can't see how a uint8 ndarray could have negative values. Do you know of a way to test that? — You are receiving this because your review was requested. Reply to this email directly, view it on GitHub, or mute the thread.

[gigasquid]

I'm going to go ahead and merge this since it seems like it fixes the issue. We'll just have to keep an eye open if there are any other problems in this area.

[marcoabreu]

@lebeg 1.3.1 candidate?

[nswamy]

@marcoabreu this feature did not exist in 1.3.0, so No.