-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
Migrate to standalone ML Kit and add Image Labeling #2931
Migrate to standalone ML Kit and add Image Labeling #2931
Conversation
It appears that this was a typo -- Android was already using correct spelling
Does the stand alone MLKit run without Google Play Services? This would be great to support more devices. Like current Huawei devices. |
@MSchmidt yes, it appears so! I removed the google play services plugin from the I'll try to update this PR soon with screenshots & more info, but for now I'm not rushing, since it looks like this repo will wait for the new ML Kit to leave beta before adopting it, and could be a while. |
I would like to request if we can publish a dedicated ml kit standalone beta release. In the migration guide to the ML Standalone Kit is stated:
( https://developers.google.com/ml-kit/migration at the bottom ) I think it would be good to align with their release policy, as we would not be at Day 1, when the old ML Kit gets deprecated and we can start to test and use it in production. |
Would love that aswell. Beta release
Would like that as well! |
Hey @davidgovea - taking this in a slightly different direction, react-native-firebase is also processing the separation from 'Firebase ML Vision' to a split of 'Firebase ML' (cloud-based inference) and on-device inference in 'Google ML Kit'. While there is a great deal of overlap between react-native-camera's on-device inference capabilities, there is also a great deal of non-camera functionality in Google ML Kit (text extraction from documents, processing non-camera images, language translation, and running downloaded models or bundled models). Because of the non-camera features I'm obligated to code up react-native-mlkit to wrap the Google ML Kit APIs, and that means I'll have all sorts of repo infrastructure for testing, distribution etc. Additionally, the (deprecated) What I'm thinking is, we should de-duplicate, in the process purging a ton of code out of react-native-camera (perhaps making it more maintainable...) and helping react-native-mlkit because it will have a built in audience of users to keep it moving along (apart from the react-native-firebase users that will migrate to it as well. What do you think? If you like the idea then the real migration here in this PR might be to make sure that whatever interfaces react-native-camera needed were easily available in react-native-mlkit so you could depend on it and get what you needed As a start, it would look something like the APIs that were purged out of react-native-firebase (links to old docs): Usage https://react-native-firebase-a1v1mzwb1.vercel.app/ml-vision/usage 🤔 |
@mikehardy - I agree. Currently the native-side functionality is:
Also, RNCamera throttles detector calls on iOS, but I don't see similar logic on Android. Interestingly, some throttling happens in JS, too. Currently, the throttling is not configurable, and each detector type has its own throttle timer. Perhaps this could be one configurable "frame preview interval" on the native side. Seems like this would be the camera's responsibility, not the mlkit library's The other option is to send everything over the JS bridge, but this has obvious performance downsides. tfjs-react-native attempts to solve this challenge with native-side preprocessing: Just to clarify, you do mean that react-native-mlkit would expose Java / Objective-C interfaces, correct? Like today, gradle/Podfile config could be used to add the additional code/hooks that call MLKit. Sounds doable! |
Thanks for thinking it through @davidgovea - I'm replying quickly (mostly to say thanks) prior to thinking through your response, apologies. Quick take is that normally I'd say it's best not to puncture the abstraction and that it should be JS-land, but this is too far to go in an area with data processing and performance needs like this, so I think some sort of native ability will be required for it to not be terrible. How to do it well? That will be the work :-). I'll follow your links and thought process above and see if I can sketch something out to debate |
Please, fix problems and merge it, this PR solves conflicts with 10.x.x version of Firebase if you need to use in your project. Link of issue: |
I was roped in to other firebase-related items (implementing auth.useEmulator, and then doing a forward port for FlutterFire) so haven't had time to push this forward, sorry. If this works as is, I strongly believe "perfect is the enemy of good" and there is no problem with incrementalism - that is, if it's working merge it. Nothing stopping a reorganization later. I will eventually do a react-native-mlkit regardless and I'll do my best at any time to make it useful for use cases like this one |
@davidgovea we noticed while using it that we no longer get the smile and eye data we expected
but get
|
@amrdraz what platform(s)? And to confirm, you are enabling those modes via props:
|
@danieldkim we initially had
this is because we would get sometimes
But evidently it seems that it maybe always undefined (with this MR). We confirm the issue on IOS, on android it works fine |
b75267a
to
751a402
Compare
@amrdraz thanks for the report! Just pushed up a fix for that -- it was the conditional-compilation of the constants (forgot to update a firebase ML kit reference). Tested the example app on iOS -- was able to get the landmarks and classifications as expected now. I have some updates for this PR soon! Pose detection, modular features on android. Seems like folks want this. We'll see if a fork/secondary package is appropriate, but I'm hopeful we can keep things homed here. |
@davidgovea is this solution work with |
@Peretz30 nope. Just took a look, and on Android, that prop is currently implemented only for the non-mlkit barcode scanning task ( The process of getting frame preview data to the detectors (and throttling the calls) could use some rework. I've withheld from reorganizing & restructuring during the course of this PR |
I just wanted to share that I really appreciate the work that has been done so far. This is the PR I need (And I'm currently using in my app) to have Firebase Database + Text recognition working in my app. |
Like I said in my previous comment. I'm currently using this PR to test some stuff. I use firebase/database together with this version of RNCamera. I did the changes you mention in the issue on the main repo, but I have trouble building for android.
This is the changes in my app/build.gradle:
And ofcourse I'm using this in my package.json:
It's probably something obvious for you guys that I'm missing, I just started using react native. |
Great work on this! What are the plans regarding this? Since 8th of December MLKit is no longer in Beta. Do you need any assistance to complete this or are you planning to extract all the functionality regarding MLKit into a separate package? |
@davidgovea you have any idea what I'm missing in my build script for android? |
I was able to run it without any build errors with
package.json
I hope this is useful for you. It also worked out on iOS without making any changes from the react-native-camera documentation |
Same here. I am able to run build in debug mode with |
I'm unable to build a production iOS app with this change, it throws some errors saying "Undefined symbols for architecture armv7" for the MLKIT. Development version is working fine (or when "Build active architecture only" is set to true). This page explicitly states, that the MLKIT is not compatible with armv7. https://developers.google.com/ml-kit/migration/ios Can someone please shed some light here? |
@comvenger-brandon I question this assertion:
iPhone 5S and newer are 64bit: That is apparently 99.5%+ of the market as this table contains 5S but not 5 and lower: Additionally those phones have been officially unsupported for a while: It's not fun trimming off groups of users but it appears moot if mlkit doesn't support them, so a build settings adjustment is likely needed. Not sure exactly the setting to change, perhaps moving cocoapods platform directive in Podfile to 12 is sufficient? If not then something about valid arches in a post install hook in podfile or your xcode settings modified directly in xcode gui |
Ok, looks like you're right. It seemed more to me at first glance. I think most projects are fine with dropping iPhone 5 and older then. But still, this is something to consider when merging this PR, it should be added to the installation docs. |
This merge request is really important for us, so I will be glad to help if needed. I can test it on multiple devices, review the code, etc 🙂 |
I think this line resolved my issue: |
@davidgovea It might be a good idea to split the |
Any updates on the progress on this issue @davidgovea ? |
instead of ./gradlew assembleRelease do ./gradlew :app:assembleRelease |
Hi all, With stalebot closing the upstream issue #2908, I'm also closing this draft PR. Where I got lost with this PR was trying to achieve conditional compilation of features on Android.
On iOS, this is pretty easy to achieve. On Android, there already exists a variety of different shim classes that get overwritten with a flavor switch. The "best" solution I came to was mangling the So, honestly the most practical solution is probably to clone the mlkit work here, and tear things up to your project's requirements :( That said, I recommend checking out https://github.com/cuvent/react-native-vision-camera if you have specific frame-processing requirements. They are using JS worklets from Reanimated 2 (with modifications), like we had discussed previously. I have not used it yet (not doing much RN these days) but it looks really awesome. |
@davidgovea thanks for the PR and sorry it didn't go through. We're discussing deprecating |
Ohh you are considering deprecating the project. React-native-camera version 4 did seem really promising. But so does react-native-vision-camera. Will work on React-native-camera version 4 stop for now or? |
In reality the v4 code adds the same underlying implementations that react-native-vision already has. But attempting to maintain all of the v3 features migrating and refactoring the existing code is extremely cumbersome, expecially in Android. I was already considering ditching Camera1 and Camera2 and updating the minimum api version to 21 to use only CameraX until I saw how react-native-vision was implemented. It is what I was hoping to achieve and has an even better extensibility/plugin system than the one we thought and implemented. From a more personal opinion, the react-native-camera code is (especially in Android) a mess. There are a lot of overlapping features and most are not documented. A fresh start will be the best way to go, and vision-camera has an excellent architecture and development pace. We don't need 3 repos (camera, camera-kit, camera-vision), we only need one, and vision has proven to be the best candidate. Camera kit is pretty good as well, don't count it out if you need the core camera features, it has amazing performance, but vision promises much more flexibility and extensibility. |
Summary
Addresses #2908
It's unclear how long the new ML Kit will be in beta, so this might be here a while.
What's done:
The example is working well!
What's TODO:
Test Plan
What's required for testing (prerequisites)?
What are the steps to reproduce (after prerequisites)?
Compatibility
Checklist
README.md
CHANGELOG.md
example/App.js
)