Well, have to disagree! I have had Coral M.2 running since last autumn, interference times have improved greatly during that period and cpu load is really low (around 6% on average). Reliability of recognition is very good. Win 11, BlueIris (almost newest), Ryzen 3 3200G and 4 FHD cameras and single UHD. At least for my purposes it's acceptable to have some extra recordings, energy efficiency is the key here and that's something M.2 Coral really provides compared to nVidias or CPU. I had Coral USB before M.2, but USB-version was problematic.
CodeProject.AI Version 2.5
- Thread starter MikeLud1
- Start date
Well, have to disagree! I have had Coral M.2 running since last autumn, interference times have improved greatly during that period and cpu load is really low (around 6% on average). Reliability of recognition is very good. Win 11, BlueIris (almost newest), Ryzen 3 3200G and 4 FHD cameras and single UHD. At least for my purposes it's acceptable to have some extra recordings, energy efficiency is the key here and that's something M.2 Coral really provides compared to nVidias or CPU. I had Coral USB before M.2, but USB-version was problematic.
I should start a poll for Coral interface type vs number of problems vs operating system. I’m beginning to suspect that a lot of it has to do with the OS also.
A poll may start a debate like which is better Ford or Chevy. 
But I agree that OS is probably the big one. I've used many OSs over the decades and there has never been a perfect one. I can go all the way back to DOS and it includes Windows 3.1 to 10, MAC OS (many versions), Linux (many distros and versions), and even some other niche OSs. Each has Pros and Cons and every person will have their opinion. That being said, Windows can be a royal PITA. However, to MS's defense (which I do not like to do), there are infinite # of variables they need to contend with and that is why everyone's experience can be different.
The second item would be the fact that you needed to uninstall and reinstall previous versions. I'm sure MANY people were lazy (though they won't admit it) and did not do all the steps Mike Lud documented in the beginning of this thread. I think I forgot one time and when I had problems realized I forgot to do all the steps. I started over following the steps and problems resolved. There are some common issues like needing to restart BI after CPAI but those are minor. To me that is like needing to reboot Windows. We complain about having to restart BI but what's the first thing the Held Desk tells you if you have problems with Windows? Cold Boot, call back. Been that way since 95 but back then the blue screen rebooted for you.
Lastly, most people probably went with the default config which may or may not be the best for them. Kind if like not tuning the cameras. Not only can you choose between model size but there are different models as well. I'm sure those of us that are successfully using a Coral TPU have played with the configs to find the sweet spot. I'll admit I didn't think the TPU was any better then the CPU until I learned about the configs and started testing.
You mention hardware too but hopefully people read the reviews and saw that USB version is not reliable (back to being lazy). To me, the only thing I would trust USB for is keyboards and mice. OK, I should say I do use USB drives but they are just backups and/or used for transferring data from one PC to another if I can't put them on the same network.
You could also mention the fact that BI had many versions when migrating from DeepStack to CPAI so there were also bugs there.
Sorry for being a long post.
But I agree that OS is probably the big one. I've used many OSs over the decades and there has never been a perfect one. I can go all the way back to DOS and it includes Windows 3.1 to 10, MAC OS (many versions), Linux (many distros and versions), and even some other niche OSs. Each has Pros and Cons and every person will have their opinion. That being said, Windows can be a royal PITA. However, to MS's defense (which I do not like to do), there are infinite # of variables they need to contend with and that is why everyone's experience can be different.
The second item would be the fact that you needed to uninstall and reinstall previous versions. I'm sure MANY people were lazy (though they won't admit it) and did not do all the steps Mike Lud documented in the beginning of this thread. I think I forgot one time and when I had problems realized I forgot to do all the steps. I started over following the steps and problems resolved. There are some common issues like needing to restart BI after CPAI but those are minor. To me that is like needing to reboot Windows. We complain about having to restart BI but what's the first thing the Held Desk tells you if you have problems with Windows? Cold Boot, call back. Been that way since 95 but back then the blue screen rebooted for you.
Lastly, most people probably went with the default config which may or may not be the best for them. Kind if like not tuning the cameras. Not only can you choose between model size but there are different models as well. I'm sure those of us that are successfully using a Coral TPU have played with the configs to find the sweet spot. I'll admit I didn't think the TPU was any better then the CPU until I learned about the configs and started testing.
You mention hardware too but hopefully people read the reviews and saw that USB version is not reliable (back to being lazy). To me, the only thing I would trust USB for is keyboards and mice. OK, I should say I do use USB drives but they are just backups and/or used for transferring data from one PC to another if I can't put them on the same network.
You could also mention the fact that BI had many versions when migrating from DeepStack to CPAI so there were also bugs there.
Sorry for being a long post.
Since CPAI 2.6.2 is not using the correct model for me (previous posts) I tried uninstalling and going back to 2.5.1 which is what I had before. However, it went to download ObjectDetectionCoral and I get the following error:
2024-04-19 20:06:43: Unable to download module 'ObjectDetectionCoral' from . Error: No bytes downloaded
I searched on CodeProject's site for offline installers (to get everything in one shot) but could only find a post from a year ago that says it's very complicated and they don't have it yet.
I guess I'm SOL?
2024-04-19 20:06:43: Unable to download module 'ObjectDetectionCoral' from . Error: No bytes downloaded
I searched on CodeProject's site for offline installers (to get everything in one shot) but could only find a post from a year ago that says it's very complicated and they don't have it yet.
I guess I'm SOL?
FYI,
The HIB Error is probably a Windows problem. I just threw BI and CPAI (same versions) on another PC and I'm not getting that error and CPAI is not crashing.
I still have the first 2 bugs on the new PC (says using CPU and not TPU as well as the watchdog).
Also amazing how going from a single TPU to a dual TPU increases the performance by 4x (according to the CPAI benchmark using theEfficientDet-Lite model). I tried going from 1 x Dual TPU to 2 xDual TPU and the it just doubled the performance so I guess It can load the whole model into the Dual TPU's memory and then at that point its just balancing the between the Dual TPU boards. Cool stuff!!
The HIB Error is probably a Windows problem. I just threw BI and CPAI (same versions) on another PC and I'm not getting that error and CPAI is not crashing.
I still have the first 2 bugs on the new PC (says using CPU and not TPU as well as the watchdog).
Also amazing how going from a single TPU to a dual TPU increases the performance by 4x (according to the CPAI benchmark using theEfficientDet-Lite model). I tried going from 1 x Dual TPU to 2 xDual TPU and the it just doubled the performance so I guess It can load the whole model into the Dual TPU's memory and then at that point its just balancing the between the Dual TPU boards. Cool stuff!!
What sized model? You generally don’t see serious multi-segment gains until you get into medium and large YOLO-based models. It’s still a work in progress, but i just got the latest TPU pipeline code merged which should give it a lot more options for balancing segment usage between TPUs. I forget what’s made it to the release as of yet.
github.com
github.com
Various optimizations & fix YOLOv8 image value scaling bug by seth-planet · Pull Request #97 · codeproject/CodeProject.AI-Server
Increase parallelism count as tpu_runner should be thread-safe. Threads are cheap so we can have a large value here. (?) Fix minor bugs when running TPU code in isolation. Delete unused file. Reduc...
github.com
Use new TPU segment option by seth-planet · Pull Request #99 · codeproject/CodeProject.AI-Server
The new TPURunner architecture allows for any number of TPUs to share the work on any model segment. This way, with multi-TPU systems, we aren't stuck with a single segment being a bottleneck. ...
github.com
Model size was medium.
Here are the ops per second (rough rounding and averaging) using the same test image for each run based on the Parallel setting:
1: 6
2: 37
3: 64
4: 87
One strange thing I noticed was as the test was running the Ops/Sec seemed to go up and then drop down at the very end. Similar to a very wide bell curve. For example, when Parallel was set to 4, most of the run seemed to be in over 100 Ops/sec but then dropped down at the end of the run. No big deal just an observation.
Geez, I'm supposed to be focused on getting my system back up as well as a 2nd system up and running as a backup but A.D.D. kicked in and instead I'm reading through your GitHub and looking at the code to see how it looks. I feel like I'm logged in for work. LOL
Although reading through your stuff reminded me of a question.
BI has an option for "Use main stream if available" for AI. I know I've seen many people here say to uncheck that because CPAI will reduce the image anyway. I can see that have an affect especially for a high res image like 4k. Which do you think gives the better reduction quality? Pass the main stream to CPAI and let it reduce it or pass the sub stream? I know the overhead will be more passing the main stream (decoding high res to then pass for reduction). But I'm focused on better inference.
Here are the ops per second (rough rounding and averaging) using the same test image for each run based on the Parallel setting:
1: 6
2: 37
3: 64
4: 87
One strange thing I noticed was as the test was running the Ops/Sec seemed to go up and then drop down at the very end. Similar to a very wide bell curve. For example, when Parallel was set to 4, most of the run seemed to be in over 100 Ops/sec but then dropped down at the end of the run. No big deal just an observation.
Geez, I'm supposed to be focused on getting my system back up as well as a 2nd system up and running as a backup but A.D.D. kicked in and instead I'm reading through your GitHub and looking at the code to see how it looks. I feel like I'm logged in for work. LOL
Although reading through your stuff reminded me of a question.
BI has an option for "Use main stream if available" for AI. I know I've seen many people here say to uncheck that because CPAI will reduce the image anyway. I can see that have an affect especially for a high res image like 4k. Which do you think gives the better reduction quality? Pass the main stream to CPAI and let it reduce it or pass the sub stream? I know the overhead will be more passing the main stream (decoding high res to then pass for reduction). But I'm focused on better inference.
I’d guess that the main stream is the highest quality, but it’s probably not worth it because it’s going to take some time to work with a large image. For example, a 4k image on my computer was taking 15 ms just to resize to the size of a the input tensor. It is pretty resource intense to decompress the 4k image on the BI side, too.
Of course, this depends on many things like the size of your main stream and the size of your sub-stream. It also would depend on if you are tiling the image to split it up and process many sub-images. And it would depend on how much spare CPU cycles you want to devote to it.
Of course, this depends on many things like the size of your main stream and the size of your sub-stream. It also would depend on if you are tiling the image to split it up and process many sub-images. And it would depend on how much spare CPU cycles you want to devote to it.
Last edited:
If folks want to run large images and have CPAI downsample them, I’d suggest figuring out how to install the ‘pillow-simd’ package on Windows and make step-by-step instructions. It does the image resizing significantly faster using the AVX instruction set which is a large win for larger images, but Chris gave up getting it installed on windows. In theory, it would be a significant improvement for anything running python under CPAI.
Last edited:
@mailseth OpenCV is faster then PIL below is a comparison resizing 100 4K image to 640 width
Code:
PIL resizing time: 0.19400310516357422 seconds
OpenCV resizing time: 0.010996818542480469 secondsDo you know what versions you’re looking at there? On their performance metrics page they have OpenCV listed as being a bit slower for image resizing. It it might be version dependent.
Below are the versions and test script (ChatGPT wrote the script)
Code:
Pillow 9.4.0
opencv-python 4.8.1.78
Python:
import time
import cv2
from PIL import Image
def resize_pil(image, output_width):
width_percent = (output_width / float(image.width))
output_height = int((float(image.height) * float(width_percent)))
img = image.resize((output_width, output_height), Image.ANTIALIAS)
return img
def resize_opencv(image, output_width):
height, width, _ = image.shape
output_height = int((output_width / width) * height)
resized_img = cv2.resize(image, (output_width, output_height))
return resized_img
def main():
image_path = 'image.bmp'
output_width = 640
num_resizes = 100
# Load the image
img_pil = Image.open(image_path)
img_cv2 = cv2.imread(image_path)
# Measure time for OpenCV resizing
start_time = time.time()
for _ in range(num_resizes):
img_cv2 = resize_opencv(img_cv2, output_width)
opencv_time = time.time() - start_time
print(f"OpenCV resizing time for {num_resizes} images: {opencv_time:.8f} seconds")
# Measure time for PIL resizing
start_time = time.time()
for _ in range(num_resizes):
img_pil = resize_pil(img_pil, output_width)
pil_time = time.time() - start_time
print(f"PIL resizing time for {num_resizes} images: {pil_time:.8f} seconds")
# Save the last resized image from both methods
img_pil.save("pil_resized_image.jpg")
cv2.imwrite("opencv_resized_image.jpg", img_cv2)
print("Last resized images saved successfully.")
if __name__ == "__main__":
main()Looks like pillow resize ANTIALIAS is the LANCZOS filter, while cv2 resize uses a linear filter by default, which are basically on opposite ends of the performance spectrum. Also, the version of pillow used isn't the SIMD one. So it's a bit of an apples-to-oranges comparison.
Still, even on the pillow-simd performance link I sent above, OpenCV has a pretty solid showing. If those numbers are all correct, OpenCV is much better than the non-simd pillow install I'm currently using.
Still, even on the pillow-simd performance link I sent above, OpenCV has a pretty solid showing. If those numbers are all correct, OpenCV is much better than the non-simd pillow install I'm currently using.
Also, the latest Coral pillow code uses the thumbnail() call:
pillow.readthedocs.io
Which cheats a bit (see "reducing gap") to downsample a large image to a much smaller one. I don't know if there is an equivalent OpenCV operation.
Image Module
The Image module provides a class with the same name which is used to represent a PIL image. The module also provides a number of factory functions, including functions to load images from files, a...
Which cheats a bit (see "reducing gap") to downsample a large image to a much smaller one. I don't know if there is an equivalent OpenCV operation.
So, for a good benchmark you'd need to add interpolation=cv.INTER_LANCZOS4 to the cv2 call, and add a pillow comparison that uses thumbnail instead of resize, test that, and then install pillow-simd (w/ AVX) and test it again.
Edit: Looking a bit further, you might want to try the 'cv.INTER_AREA' technique to opencv instead of lanczos. It should be faster and better looking for this usage.
Edit2: you’ll need to make a copy of the image on each iteration because thumbnail resizes the image in place.
Edit: Looking a bit further, you might want to try the 'cv.INTER_AREA' technique to opencv instead of lanczos. It should be faster and better looking for this usage.
Edit2: you’ll need to make a copy of the image on each iteration because thumbnail resizes the image in place.
Last edited:
So, cleaning up the office last night, and I found my USB version of the Coral TPU. Decided to plug it into the Windows 11 machine and enable Coral modules in CP.AI. First chose to update to the latest 2.6.2 version of CP.AI, but it too reports errors installing the Coral USB libraries?
DOH!! It seems I should have followed the Coral instructions at the URL below instead, before plugging in the device. Windows 11 complains about the .BAT file not being trusted, but you have to bypass that warning to get the USB drivers installed successfully.
coral.ai
Code:
08:03:00:System: Windows
08:03:00:Operating System: Windows (Microsoft Windows 11 version 10.0.22631)
08:03:00:CPUs: Intel(R) Core(TM) i7-8700 CPU @ 3.20GHz (Intel)
08:03:00: 1 CPU x 6 cores. 12 logical processors (x64)
08:03:00:GPU (Primary): Microsoft Remote Display Adapter (Microsoft)
08:03:00: Driver: 10.0.22621.3235
08:03:00:System RAM: 32 GiB
08:03:00:Platform: Windows
08:03:00:BuildConfig: Release
08:03:00:Execution Env: Native
08:03:00:Runtime Env: Production
08:03:00:Runtimes installed:
08:03:00: .NET runtime: 7.0.10
08:03:00: .NET SDK: Not found
08:03:00: Default Python: Not found
08:03:00: Go: Not found
08:03:00: NodeJS: Not found
08:03:00: Rust: Not found
08:03:00:App DataDir: C:\ProgramData\CodeProject\AI
08:03:00:Video adapter info:
08:03:00: Microsoft Remote Display Adapter:
08:03:00: Driver Version 10.0.22621.3235
08:03:00: Video Processor
08:03:00: Intel(R) UHD Graphics 630:
08:03:00: Driver Version 30.0.100.9864
08:03:00: Video Processor Intel(R) UHD Graphics Family
08:03:00:STARTING CODEPROJECT.AI SERVER
08:03:00:RUNTIMES_PATH = C:\Program Files\CodeProject\AI\runtimes
08:03:00:PREINSTALLED_MODULES_PATH = C:\Program Files\CodeProject\AI\preinstalled-modules
08:03:00:DEMO_MODULES_PATH = C:\Program Files\CodeProject\AI\demos\modules
08:03:00:MODULES_PATH = C:\Program Files\CodeProject\AI\modules
08:03:00:PYTHON_PATH = \bin\windows\%PYTHON_NAME%\venv\Scripts\python
08:03:00:Data Dir = C:\ProgramData\CodeProject\AI
08:03:00:Server version: 2.6.2
08:03:03:Setting up initial modules. Please be patient...
08:03:03:Installing initial module ObjectDetectionCoral.
08:03:03:Preparing to install module 'ObjectDetectionCoral'
08:03:04:Downloading module 'ObjectDetectionCoral'
08:03:04:Installing module 'ObjectDetectionCoral'
08:03:04:ObjectDetectionCoral: Installing CodeProject.AI Analysis Module
08:03:04:ObjectDetectionCoral: ======================================================================
08:03:04:ObjectDetectionCoral: CodeProject.AI Installer
08:03:04:ObjectDetectionCoral: ======================================================================
08:03:04:ObjectDetectionCoral: 860.1Gb of 953Gb available on
08:03:04:ObjectDetectionCoral: General CodeProject.AI setup
08:03:05:ObjectDetectionCoral: Creating Directories...done
08:03:05:ObjectDetectionCoral: GPU support
08:03:05:ObjectDetectionCoral: CUDA Present...No
08:03:05:ObjectDetectionCoral: ROCm Present...No
08:03:05:Server: This is the latest version
08:03:08:ObjectDetectionCoral: Reading ObjectDetectionCoral settings.......done
08:03:08:ObjectDetectionCoral: Installing module Object Detection (Coral) 2.2.2
08:03:08:ObjectDetectionCoral: Installing Python 3.9
08:03:22:ObjectDetectionCoral: Downloading Python 3.9 interpreter...Expanding...done.
08:04:52:ObjectDetectionCoral: Creating Virtual Environment (Local)...done
08:04:52:ObjectDetectionCoral: Confirming we have Python 3.9 in our virtual environment...present
08:04:59:ObjectDetectionCoral: Downloading edge TPU runtime...Expanding...done.
08:05:01:ObjectDetectionCoral: Copying contents of edgetpu_runtime-20221024.zip to edgetpu_runtime...done
08:05:03:ObjectDetectionCoral: Installing the edge TPU libraries...
08:05:07:ObjectDetectionCoral: Installing UsbDk
08:05:52:ObjectDetectionCoral: Installing Windows drivers
08:05:55:ObjectDetectionCoral: Microsoft PnP Utility
08:05:55:ObjectDetectionCoral: Adding driver package: coral.inf
08:05:58:ObjectDetectionCoral: Driver package added successfully. (Already exists in the system)
08:05:58:ObjectDetectionCoral: Published Name: oem64.inf
08:05:58:ObjectDetectionCoral: Adding driver package: Coral_USB_Accelerator.inf
08:06:03:ObjectDetectionCoral: Failed to add driver package: The publisher of an Authenticode(tm) signed catalog has not yet been established as trusted.
08:06:03:ObjectDetectionCoral: Adding driver package: Coral_USB_Accelerator_(DFU).inf
08:06:04:ObjectDetectionCoral: Failed to add driver package: The publisher of an Authenticode(tm) signed catalog has not yet been established as trusted.Get started with the USB Accelerator | Coral
Learn how to set up the Coral USB Accelerator and run some demo code.
coral.ai
Last edited:
Well there was another bug in the code where it saved out the thumbnail and then used the thumbnail in the next iteration for resizing. I thought it was suspiciously fast. But still looks like OpenCV easily takes the speed crown here using a 4k image.
Weirdly, however, OpenCV is easily the worst for an already-small image that you'd see in a sub-stream. There must be a lot of overhead in the implementation.
Edit: Swapping OpenCV to
Looks like OpenCV is the library to use here!
Edit 2: For fairness set this, but OpenCV still wins.
Edit3: To answer the original question, there is 10-55 ms of resizing overhead for 4k images depending on the method and library used. There may be additional overhead for file transfer, decompression, and I/O.
Edit 4:
I just ran this on my Intel Mac without the SIMD pillow and single-threaded OpenCV. 96-440 ms per image when resizing 4k images.
Bash:
$ python test_img_timing.py
cv2: 4.9.0
PIL.Image version: 9.0.0.post1
OpenCV resizing time for 100 images: 1.41319346 seconds
PIL resizing time for 100 images: 5.16413379 seconds
PIL thumbnailing time for 100 images: 4.68970108 seconds
Last resized images saved successfully.Weirdly, however, OpenCV is easily the worst for an already-small image that you'd see in a sub-stream. There must be a lot of overhead in the implementation.
Bash:
$ python test_img_timing.py
cv2: 4.9.0
PIL.Image version: 9.0.0.post1
OpenCV resizing time for 100 images: 0.70441604 seconds
PIL resizing time for 100 images: 0.40047526 seconds
PIL thumbnailing time for 100 images: 0.05203104 seconds
Last resized images saved successfully.
Python:
import time
import cv2
import copy
from PIL import Image
def thumbnail_pil(image, output_width):
width_percent = (output_width / float(image.width))
output_height = int((float(image.height) * float(width_percent)))
image.thumbnail((output_width, output_height), Image.LANCZOS)
return image
def resize_pil(image, output_width):
width_percent = (output_width / float(image.width))
output_height = int((float(image.height) * float(width_percent)))
img = image.resize((output_width, output_height), Image.LANCZOS)
return img
def resize_opencv(image, output_width):
height, width, _ = image.shape
output_height = int((output_width / width) * height)
resized_img = cv2.resize(image, (output_width, output_height), interpolation=cv2.INTER_LANCZOS4)
return resized_img
def main():
image_path = 'Downloads/45.25[M][0@0][0].jpg'
output_width = 640
num_resizes = 100
print(f"cv2: {cv2.__version__}")
print(f"{Image.__name__} version: {Image.__version__}")
# Load the image
img_pil = Image.open(image_path)
img_cv2 = cv2.imread(image_path)
# Measure time for OpenCV resizing
start_time = time.time()
for _ in range(num_resizes):
resize_opencv(copy.deepcopy(img_cv2), output_width)
opencv_time = time.time() - start_time
print(f"OpenCV resizing time for {num_resizes} images: {opencv_time:.8f} seconds")
# Measure time for PIL resizing
start_time = time.time()
for _ in range(num_resizes):
resize_pil(copy.deepcopy(img_pil), output_width)
pil_time = time.time() - start_time
print(f"PIL resizing time for {num_resizes} images: {pil_time:.8f} seconds")
start_time = time.time()
for _ in range(num_resizes):
thumbnail_pil(copy.deepcopy(img_pil), output_width)
tn_time = time.time() - start_time
print(f"PIL thumbnailing time for {num_resizes} images: {tn_time:.8f} seconds")
# Save the last resized image from both methods
thumbnail_pil(img_pil, output_width).save("pil_tn_image.jpg")
cv2.imwrite("opencv_resized_image.jpg", resize_opencv(img_cv2, output_width))
print("Last resized images saved successfully.")
if __name__ == "__main__":
main()Edit: Swapping OpenCV to
cv2.INTER_AREA is much faster:
Bash:
$ python test_img_timing.py
cv2: 4.9.0
PIL.Image version: 9.0.0.post1
OpenCV resizing time for 100 images: 0.08085299 seconds
PIL resizing time for 100 images: 0.39692140 seconds
PIL thumbnailing time for 100 images: 0.04550600 seconds
Last resized images saved successfully.Edit 2: For fairness set this, but OpenCV still wins.
Python:
cv2.setNumThreads(1)Edit 4:
I just ran this on my Intel Mac without the SIMD pillow and single-threaded OpenCV. 96-440 ms per image when resizing 4k images.
Bash:
$ python test.py
cv2: 4.9.0
PIL.Image version: 10.3.0
OpenCV resizing time for 100 images: 9.64040709 seconds
PIL resizing time for 100 images: 44.42225170 seconds
PIL thumbnailing time for 100 images: 29.33279991 seconds
Last resized images saved successfully.
Last edited:
FYI, you are replying to a post that I made which was based on data from late February.
Since then, @mailseth has been working on the Coral object detection module.
Until last week, I was using the 2.2.0 version of the Coral module, with excellent results. Having seen zero failed inferences on about 100,000 inferences, I wondered if there was a mistake somewhere.
On the CPAI forum I was assured the module had been improved, and the zero failed inferences was correct.
I am on Windows 10 Blue iris the latest stable version, CPAI version 2.6.2 and Coral module 2.2.0 with the YOLOv8 model. I see inference times with the small model of 8 to 12 ms.
My only concern at this point is the use of the full COCO label set, as the module will be identifying trains, toilets, elephants, traffic lights, etc. for that reason, I occasionally will revert to using the YOLOv5 .Net with the ipcam-combined and ipcam-dark models. This works well for me.
BTW, the Windows machine is using a Coral M.2 accerator.
I have been trying to read up on how to reduce the default model for the Coral module. I would love to see something like ipcam-combined or similar for the Coral module, but I am afraid that is beyond my ability at this point.
Bottom line is the Coral module version 2.2.0 is MUCH better. Thanks to the work of @mailseth!
Sent from my iPlay_50 using Tapatalk
Last edited:
Nothing wrong with finding trains in your yard. My toddler would love that! Same with elephants….
The biggest problem these days with the Coral module is that my Linux machine is rock solid so I can’t test, improve, and recover from the crashes folks are seeing. I need to start running the USB dongle under Windows.
The other problem is the lack of custom models, but that will happen in due time.
Same with elephants….The biggest problem these days with the Coral module is that my Linux machine is rock solid so I can’t test, improve, and recover from the crashes folks are seeing. I need to start running the USB dongle under Windows.
The other problem is the lack of custom models, but that will happen in due time.
I am sorry to say, I just updated the Coral Module from ver 2.2.0 to 2.2.2. I am now seeing the same behavior that I was seeing regarding the failed inferences. AFAIK, the settings for the Coral module are the same.
Environment Variables
CPAI_CORAL_MODEL_NAME = YOLOv8
CPAI_CORAL_MULTI_TPU = true
MODELS_DIR = <root>\modules\ObjectDetectionCoral\assets
MODEL_SIZE = small
Status Data: {
"inferenceDevice": "TPU",
"inferenceLibrary": "TF-Lite",
"canUseGPU": "false",
"successfulInferences": 705,
"failedInferences": 243,
"numInferences": 948,
"averageInferenceMs": 7.479432624113475
This is about 25% failed inferences.