I am trying to train a haar-like classifier for pedestrians in OpenCV using 3340 positive images and 1224 negative images. (in a .txt file I keep the negative image names i.e negatives(1).bmp, and in a txt file I keep the positives i.e. picture(1).bmp 1 0 0 64 128.
Actually positive examples are already cropped images of pedestrians so I only need specify one positive sample per image).
At some point during the training process it stops and says :
"Opencv Error: Assertion failed (elements_read==1)in unknown function, file c:\path\cvhaartraining.cpp, line 1858"
Any ideas as to what is causing this ?
this issue was answered by creater of the utility on the OpenCV DevZone site in June 2012.
To quote Maria:
The problem is that your vec-file has exactly the same samples count
that you passed in command line -numPos 979. Training application used
all samples from the vec-file to train 0-stage and it can not get new
positive samples for the next stage training because vec-file is over.
The bug of traincascade is that it had assert() in such cases, but it
has to throw an exception with error message for a user. It was fixed
in r8913.
-numPose is a samples count that is used to train each stage. Some already used samples can be filtered by each previous stage (ie
recognized as background), but no more than (1 - minHitRate) * numPose
on each stage. So vec-file has to contain >= (numPose + (numStages-1)
* (1 - minHitRate) * numPose) + S, where S is a count of samples from vec-file that can be recognized as background right away. I hope it
can help you to create vec-file of correct size and chose right numPos
value.
It worked for me. I also had same problem, I was following the famous tutorial on HAAR training but wanted to try the newer training utility with
-npos 7000 -nneg 2973
so i did following calcs:
vec-file has to contain >= (numPos + (numStages-1) * (1 - minHitRate) * numPos) + S
7000 >= (numPos + (20-1) * (1 - 0.999) * numPos) + 2973
(7000 - 2973)/(1 + 19*0.001) >= numPos
numPos <= 4027/1.019
numPos <= 3951 ~~ 3950
and used:
-npos 3950 -nneg 2973
It works. I also noticed that others have also had success with reducing numPos : here
Related
I have a console program which I have used for years, for (among other things) displaying info about certain audio-file formats, including mp3. I used data from the mpeghdr site to calculate the frame sizes, in order to further calculate playing time for the tracks. The equation that I got from mpeghdr was:
// Read the BitRate, SampleRate and Padding of the frame header.
// For Layer I files use this formula:
//
// FrameLengthInBytes = (12 * BitRate / SampleRate + Padding) * 4
//
// For Layer II & III files use this formula:
//
// FrameLengthInBytes = 144 * BitRate / SampleRate + Padding
This works well for most mp3 files, but there have always been a small subset for whom this equation failed. Recently, I've been looking at a set of very small mp3 files, and have found that for these files this formula fails much more often, so I'm trying to finally nail down what is going on. All of these mp3 files were generated using Lame V3.100, with default settings, on Windows 7 64-bit.
In all cases, I can successfully find the first frame header, but when I used the above formula to calculate the offset to the next frame header, it is sometimes not correct.
As an example, I have a file 'wolf howl.mp3'; analytical files such as MPEGAudioInfo show frame size as 288 bytes. When I run my program, though, it shows length of first frame as 576 bytes (2 * 288). When I look at the mp3 file in a hex editor, with first frame at 0x154, I can see that the next frame is at 0x154 + 208 bytes, but this calculation does in fact result in 576 bytes...
File info:
mpegV2.5, layer III
frame: bitrate=32, sample_rate=8000, pad=0, bytes=576
mtemp->frame_length_in_bytes =
(144 * (mtemp->bitrate * 1000) / mtemp->sample_rate) + mtemp->padding_bit;
which equals 576
I've looked at numerous other references, and they all show this equation...
At first I thought is was an issue with MPEG 2.5, which is an unofficial standard, but I have also seen this with MPEG2 files as well. Only happens with small files, though.
Does anyone have any insights on what I am missing here??
//**************************************
Later notes:
I thought maybe audio format would be relevant to this issue, so I dumped channel_mode and mode_extension for each of my test files (3 calculate properly, 2 don't). Sadly, all of them are cmode=3, mode_ext=0
(i.e., last byte of the header is 0xC4)... so that doesn't help...
Okay, I found the answer to this queston... it was in the MPEGAudioInfo program on CodeProject site. Here is the vital key:
//*************************************************************************************
// This reference data is from MPEGAudioInfo app
// Samples per Frame / 8
static const u32 m_dwCoefficients[2][3] =
{
{ // MPEG 1
12, // Layer1 (must be multiplied with 4, because of slot size)
144, // Layer2
144 // Layer3
},
{ // MPEG 2, 2.5
12, // Layer1 (must be multiplied with 4, because of slot size)
144, // Layer2
72 // Layer3
}
};
It is unfortunately that none of the reference pages mention this detail !!
My program now successfully calculates frame sizes for all of my mp3 files, including the small ones.
I had the same problem. Some documents, I've read, don't define dividing by 2 in Frame-Size formula for MPEG2.5L3. But some src-code, I encountered - does.
It's hard to find out any proof.
I have nothing better than this link:
https://link.springer.com/chapter/10.1007/978-1-4615-0327-9_12
(it's better to share that link in "add a comment"-form, but I have insufficient rank)
I am trying to build a learning curve which compares training and testing accuracy versus training set size in WEKA. The testing accuracy portion versus training set size is easily done (through LearningRateProducer), but what I can't figure out is how to get training accuracy results through the experimenter module in an automated way. Here is an example of the output I'm looking for. This result is from the simple CLI module after running IBk.
=== Error on training data ===
Correctly Classified Instances 4175 100 %
Incorrectly Classified Instances 0 0 %
Kappa statistic 1
Mean absolute error 0.0005
Root mean squared error 0.0012
Relative absolute error 0.717 %
Root relative squared error 0.6913 %
Total Number of Instances 4175
I could do this through simple CLI, but I have many experiments that I need to generate a learning curve for and I would prefer a less manual way. An experiment module solution would be most desirable.
Thanks,
B
I was able to get this information by installing the groovy console and using the following script:
data = (new weka.core.converters.ConverterUtils.DataSource("/Path/To/Arff")).getDataSet()
data.setClassIndex(data.numAttributes() - 1)
data.randomize(new Random(1))
classifier = new weka.classifiers.trees.J48()
println "|train|\t%acc_{train}\t%acc_{test}"
stepSize = data.numInstances() / 10
for (int i = stepSize; i < data.numInstances(); i += stepSize ) {
subset = new weka.core.Instances(data, 1, i)
classifier.buildClassifier(subset)
evaluationObject = new weka.classifiers.evaluation.Evaluation(subset)
evaluationObject.evaluateModel(classifier, subset)
testSubset = new weka.core.Instances(data, i + 1, data.numInstances() - (i + 1))
evaluationObjectTest = new weka.classifiers.evaluation.Evaluation(subset)
evaluationObjectTest.evaluateModel(classifier, testSubset)
credit to Eibe Frank: https://weka.8497.n7.nabble.com/How-to-generating-learning-curve-for-training-set-td41654.html
The solution is comparable to Experimenter. You can directly call classifiers through groovy code and batch them however you need.
I am new to working with Promela and in particular SPIN. I have a model which I am trying verify and can't understand SPIN's output to resolve the problem.
Here is what I did:
spin -a untitled.pml
gcc -o pan pan.c
./pan
The output was as follows:
pan:1: VECTORSZ is too small, edit pan.h (at depth 0)
pan: wrote untitled.pml.trail
(Spin Version 6.4.5 -- 1 January 2016)
Warning: Search not completed
+ Partial Order Reduction
Full statespace search for:
never claim - (none specified)
assertion violations +
acceptance cycles - (not selected)
invalid end states +
State-vector 8172 byte, depth reached 0, errors: 1
0 states, stored
0 states, matched
0 transitions (= stored+matched)
0 atomic steps
hash conflicts: 0 (resolved)
I then ran SPIN again to try to determine the cause of the problem by examining the trail file. I used this command:
spin -t -v -p untitled.pml
This was the result:
using statement merging
spin: trail ends after -4 steps
#processes: 1
( global variable dump omitted )
-4: proc 0 (:init::1) untitled.pml:173 (state 1)
1 process created
According to this output (as I understand it), the verification is failing during the "init" procedure. The relevant code from within untitled.pml is this:
init {
int count = 0;
int ordinal = N;
do // This is line 173
:: (count < 2 * N + 1) ->
At this point I have no idea what is causing the problem since to me, the "do" statement should execute just fine.
Can anyone please help me in understanding SPINs output so I can remove this error during the verification process? The model does produce the correct output for reference.
You can simply ignore the trail file in this case, it is not relevant at all.
The error message
pan:1: VECTORSZ is too small, edit pan.h (at depth 0)
tells you that the size of directive VECTORSZ is too small to successfully verify your model.
By default, VECTORSZ has size 1024.
To fix this issue, try compiling your verifier with a larger VECTORSZ size:
spin -a untitled.pml
gcc -DVECTORSZ=2048 -o run pan.c
./run
If 2048 doesn't work too, try some more (increasingly larger) values.
In a script I'm using, the code generates a figure where a number of subplots are generated. Usually it creates a rectangular grid of plots, but for it's current use, the horizontal parameter only has 1 value, and the vertical parameter has considerably more values than it has had previously. This is causing my program to crash while running, because (presumably) the vertical dimension is too large. The code that's causing the issue is:
#can't get past the first line here
self.fig1 = plt.figure('Title',figsize=(4.6*numXparams,2.3*numYparams))
self.gs = gridspec.GridSpec(numYparams,numXparams)
self.gs.update(left=0.03, right=0.97, top=0.9, bottom=0.1, wspace=0.5, hspace=0.5)
and then later in a nested for loop running over both params:
ax = plt.subplot(self.gs[par0, par1])
The error I'm getting is:
X Error of failed request: badAlloc (insufficient resources for operation)
Major opcode of failed request: 53 (X_CreatePixmap)
Serial number of failed request: 295
Current serial number in output stream: 296
My vertical parameter currently has 251 values in it, so I can see how 251*2.3 inches could lead to trouble. I added in the 2.3*numYparams because the plots were overlapping, but I don't know how to create the figure any smaller without changing how the plots are arranged in the figure. It is important for these plots to stay in a vertically oriented column.
There are a couple of errors in your code. Fixing them allowed me to generate the figure you are asking for.
# I needed the figsize keyword here
self.fig1 = plt.figure(figsize=(4.6*numXparams,2.3*numYparams))
# You had x and y switched around here
self.gs = gridspec.GridSpec(numYparams,numXparams)
self.gs.update(left=0.03, right=0.97, top=0.9, bottom=0.1, wspace=0.5, hspace=0.5)
# I ran this loop
for i in range(numYparams):
ax = fig1.add_subplot(gs[i, 0]) # note the y coord in the gridspec comes first
ax.text(0.5,0.5,i) # just an identifier
fig1.savefig('column.png',dpi=50) # had to drop the dpi, because you can't have a png that tall!
and this is the top and bottom of the output figure:
Admittedly, there was a lot of space above the first and below the last subplot, but you can fix that by playing with the figure dimensions or gs.update
I recently switched from OpenCV 2.4.6 to 3.0.
My Code looks like this:
Ptr<ml::SVM> pSVM = ml::SVM::create();
pSVM->->setType(cv::ml::SVM::C_SVC);
pSVM->setKernel(cv::ml::SVM::LINEAR);
pSVM->->setC(1);
cv::Ptr<cv::ml::TrainData> TrainData = cv::ml::TrainData::create(TrainMatrix, cv::ml::ROW_SAMPLE, Labels);
//TrainMatrix is a cv::Mat with 35000 rows and 1900 cols and float values in it. One Feature per row.
//Labels is a std::vector<int> with 35000 Elements with 1 and -1 in it.
pSVM->trainAuto(TrainData, 10, cv::ml::SVM::getDefaultGrid(cv::ml::SVM::C), cv::ml::SVM::getDefaultGrid(cv::ml::SVM::GAMMA), cv::ml::SVM::getDefaultGrid(cv::ml::SVM::P),
cv::ml::SVM::getDefaultGrid(cv::ml::SVM::NU), cv::ml::SVM::getDefaultGrid(cv::ml::SVM::COEF), cv::ml::SVM::getDefaultGrid(cv::ml::SVM::DEGREE), false);
When my program reaches the trainAuto method is crashes and in the error message stands that it cannot allocate 524395968 bytes. This number seems a little bit high. Before the crash the program consumes about 400 MB in Debug Mode.
If I put a smaller matrix (about 500 rows) in the method everything runs normally.
Has anyone same problems and knows a solution to it?