Apple machine learning in 2020: What’s new?
machinethink.net
machinethink.net
The only exception I'm aware of is HOPL (History of Programming Languages). They still published the papers/proceedings as usual, but have postponed a physical gathering instead of meeting virtually because the conference convenes only once every 10-15 years.
https://github.com/tensorflow/mlir/issues/60
https://github.com/tensorflow/mlir/pull/118
https://github.com/tensorflow/mlir/Are app developers shipping models that are so brittle they cannot handle a different revision of Apple's camera?
I can understand shipping more complex models for devices with better CPU/GPU or whatever Apple's AI accelerator is called, but not different cameras!
(To back up a bit: Image augmentations are how you solve that problem. "How do I make my model robust across different cameras?" It might be tempting to gather labeled data from a variety of cameras, but that doesn't necessarily result in a model that can handle newer, larger-res cameras. So one solution is to distort the training data with augmentations so that the model can't tell which resolution the input images are coming from.)
The other way to deal with it is to just downscale the camera's image to, say, 416x416. But that introduces a question: can different cameras give images that look different when downscaled to 416x416? Sure they can! Cameras have a dizzying array of features, and they perform differently in different lighting conditions.
To return to the point about image augmentations being hard to add: It's so easy to explain what your training code should do "Just distort the hue a bit" and there seem to be operations explicitly for that: https://www.tensorflow.org/api_docs/python/tf/image/adjust_h... but when you go to train with them, you'll discover that backpropagation isn't implemented, i.e. they break in training code.
I've been trying to build an equivalent of Kornia for tensorflow https://github.com/kornia/kornia which is a wonderful library that implements image augmentations using nothing but differentiable primitives. Work is a bit slow, but I hope to release it in Mel https://github.com/shawwn/mel (which will hopefully look less like a TODO soon).
But all of this still raises the question of which augmentations to add. Work in this area is ongoing; see Gwern's excellent writeup at https://github.com/tensorfork/tensorfork/issues/35
Training a model per camera isn't necessarily a terrible idea, either. In the future I predict that we'll see more and more "on-demand" models: models that are JIT optimized for a target configuration (in this case, a specific camera).
Robustness often comes at the cost of quality / accuracy (https://arxiv.org/abs/2006.14536 recently highlighted this). In situations where that last 2% of accuracy is crucial, there are all kinds of tricks; training separate models is but one of many.
Why not do the data augmentation during preprocessing (so that the transformations don't have to be done by differentiable transforms)? I.e., map over a tf.Dataset with the transformation (and append to the original dataset).
Differentiable augmentations aren't necessary unless the augmentations are midstream (so you have to propagate parameters above the augmentations, which is weird) or have parameters (at which point you aren't learning how to work on different views of the same sample, you are learning how to modify a sample to be more learnable, which is a different problem that you are trying to solve).
Don't get me wrong, augmenting samples to reduce device bias is a hard problem, but you might be making it harder than it needs to be.
It wasn't clear from your original post that you were augmenting generated images, not real data.
Meta-learning, or perhaps learning camera embeddings to condition on, would be one way. Although that might all be implicit if you use a deep enough NN and train on a sufficiently diverse corpus of phones+photos.
Someone was telling me of ML cancer detection that was unexpectedly training on the ruler found in most images of cancer.
I can see models based on an image sensor could inadvertently optimize for sensor size or geometry.
This is IMO very visible in the "output" Apple has produced in the space of ML : mostly infrastructure, and very little in the way of innovative tech and research.
And changing culture is a very hard proposition from a management perspective, unless you build a complete skunkworks-like independent entity within the mothership.