I want to use tesseract with multiple core for one image because I run tesseract on Raspberry Pi 3B and tesseract is too slow(1 minute for 1 image). I tried to crop image and process them with multiple cores, but this was slower. I made lots of research, but I couldn't find anything. Thank you.
Even using multiple cores, you have to consider that the memory in the Raspberry may no be enough to feed each core with data faster than one would do for the whole image.
1 minute for an intensive operation as is OCR with a Raspberry Pi is not so bad.
Related
I am using YOLOv5x model on my custom dataset. Inference time is initially 0.055s, then it increases up to 2 seconds gradually. Same thing happens in the validation too. Iterations start from 6 seconds and end as much as 34 seconds.
This performance drop happens in every training setting so I don't think it is about the dataset. I can train it without performance drop in the ssh server.
My current gpu is RTX 2070. I have 16gb ram and i7-9750h cpu.
edit:
If I split images into small parts and wait between the inferences, I get optimal performance. Also, If I run detect for the same part without waiting, I get worse inference time for the same images.
It was because of the thermal throttling. Cleaning and new thermal paste solved the problem. You can also see the original answer from the GitHub page.
Currently the bin files for fastText wiki.en.bin is about 8GB. Is there a version about half the size of this? The bin files consists of the model and pretrained vectors that were generated from a large wiki corpus. Is there a smaller en. version that would make it easier for lower range machines? Loading this up is taking too much memory.
Or to get a smaller size bin file for use with fasttext, should i train my own set of fasttext vectors with a smaller set of parallel corpus?
You can use the quantize function
$ ./fasttext quantize -output wiki.en
This will drastically reduce the size of your model without losing too much accuracy.
Currently, the native Facebook fastText library supports quantization only for the supervised models used for classification, and cannot compress unsupervised models for embedding lookup trained e.g. on wiki.
However, I have created a package compress-fasttext that is able to significantly reduce the size of unsupervised fastText models. You can read more about it in this Medium post.
There are a few models of different sizes (10MB to 200MB) compressed with this package for English and Russian, and a set of tiny models for 101 other languages.
I have a limited system and would like to implement FFT within STM32F103C8 without any extra memory buffers.
So I want to know how many memories are needed to implement if I have 2592x1944x8bit size's one image?
Actually, I want to have a process such as
Origial image ---> FFT ---> Blur ---> IFFT ---> Modified image
What is the memory requirements for FFT on STM32F103C8 ?
So I want to know how many memories are needed to implement if I have 2592x1944x8bit size's one image?
Much more than you have. This isn't going to work out.
2592x1944 # 8bpp is roughly 5 MB. Your microcontroller has 20 KB of RAM, which isn't even enough to store eight lines of your image.
I'm building a one-off smart-home data collection box. It's expected to run on a raspberry-pi-class machine (~1G RAM), handling about 200K data points per day (each a 64-bit int). We've been working with vanilla MySQL, but performance is starting to crumble, especially for queries on the number of entries in a given time interval.
As I understand it, this is basically exactly what time-series databases are designed for. If anything, the unusual thing about my situation is that the volume is relatively low, and so is the amount of RAM available.
A quick look at Wikipedia suggests OpenTSDB, InfluxDB, and possibly BlueFlood. OpenTSDB suggests 4G of RAM, though that may be for high-volume settings. InfluxDB actually mentions sensor readings, but I can't find a lot of information on what kind of resources are required.
Okay, so here's my actual question: are there obvious red flags that would make any of these systems inappropriate for the project I describe?
I realize that this is an invitation to flame, so I'm counting on folks to keep it on the bright and helpful side. Many thanks in advance!
InfluxDB should be fine with 1 GB RAM at that volume. Embedded sensors and low-power devices like Raspberry Pi's are definitely a core use case, although we haven't done much testing with the latest betas beyond compiling on ARM.
InfluxDB 0.9.0 was just released, and 0.9.x should be available in our Hosted environment in a few weeks. The low end instances have 1 GB RAM and 1 CPU equivalent, so they are a reasonable proxy for your Pi performance, and the free trial lasts two weeks.
If you have more specific questions, please reach out to us at influxdb#googlegroups.com or support#influxdb.com and we'll see hwo we can help.
Try VictoriaMetrics. It should run on systems with low RAM such as Raspberry Pi. See these instructions on how to build it for ARM.
VictoriaMetrics has the following additional benefits for small systems:
It is easy to configure and maintain since it has zero external dependencies and all the configuration is done via a few command-line flags.
It is optimized for low CPU usage and low persistent storage IO usage.
It compresses data well, so it uses small amounts of persistent storage space comparing to other solutions.
Did you try with OpenTSDB. We are using OpenTSDB for almost 150 houses to collect smart meter data where data is collected every 10 minutes. i.e is a lot of data points in one day. But we haven't tested it in Raspberry pi. For Raspberry pi OpenTSDB might be quite heavy since it needs to run webserver, HBase and Java.
Just for suggestions. You can use Raspberry pi as collecting hub for smart home and send the data from Raspberry pi to server and store all the points in the server. Later in the server you can do whatever you want like aggregation, or performing statistical analysis etc. And then you can send results back to the smart hub.
ATSD supports ARM architecture and can be installed on a Raspberry Pi 2 to store sensor data. Currently, Ubuntu or Debian OS is required. Be sure that the device has at least 1 GB of RAM and an SD card with high write speed (60mb/s or more). The size of the SD card depends on how much data you want to store and for how long, we recommend at least 16GB, you should plan ahead. Backup batter power is also recommended, to protect against crashes and ungraceful shutdowns.
Here you can find an in-depth guide on setting up a temperature/humidity sensor paired with an Arduino device. Using the guide you will be able to stream the sensor data into ATSD using MQTT or TCP protocol. Open-source sketches are included.
I'm looking to perform many (thousands) of small optimization jobs on my nVidia Geforce.
With small jobs I mean 3-6 dimensions and around 1000 data points input each. Basically it's for curve fitting purposes, so the objective function to minimize is a sum of squares of a continuous (non-trivial) analytical function, of which I can compute the first derivative analytically. Each dimension is constrained between lower and upper boundary.
The only thing these jobs have in common is the original data series out of which they take different 1000 data points.
I suspect this will be much faster on my GPU than now, running them one by one my CPU, so I could use it for realtime monitoring.
However, the GPU libraries I've seen only focus on calculating a single function evaluation (faster) on the GPU.
There was a thread on my specific question on the nvidia CUDA forum, with more users looking for this, but the forums have been down for a while. It mentioned porting an existing C library (eg. levmar) to the CUDA language, but this got lost...
Do you know of an existing library to run many optimizations in parallel on a gpu?
Thanks!
The GFOR loop is meant to tile together many small problems like this. Each body of the loop is tiled together with the other loop bodies. Many people have used it for optimization problems like you describe. It is available for C/C++, Fortran, or Python as well as MATLAB code.
My disclaimer is that I work on GFOR. But I'm not aware of any other production-level GPU library that does similar optimization problems. You might be able to find some academic projects if you search around.