I need all bits to 1 on a char size, while I know in C there is limits.h, and vala has int.MAX, I’m not sure of the char size.
How could I find it - a char size - and generate my bitmask for sure, instead of using 0xFFFF ?
apmasell is right, but I don't really like his answer. If you want the size of char (in bytes), you should use sizeof(char) instead of depending on that value in the glib vapi staying the same.
char.MAX, if it existed, wouldn't be 0xff (255), it would be 0x7f (127), but that isn't the right value for a mask since the. From a practical perspective it's probably safe to assume 0xff is the right value, but if you want to be safe you could just use ~((char) 0).
In Vala, char is one byte. Here is the VAPI declaration:
[IntegerType (rank = 2, min = 0, max = 127)]
public struct char {
Related
I want to set the type of a cv::Mat object to CV_32F, but I don't care (at declaration time) of the matrix size.
There is any other way to do this:
cv::Mat m (0,0,CV_32F);
Something like:
cv::Mat m;
m.setType(CV_32F);
The simple answer is use cv::Mat1f or e.g. cv::Mat3f (as #Miki suggested).
However, the place where it actually matters is at allocation time, so there's no problem just leaving m as is, and when you actually come to allocate it to the desired size, set it there (e.g. with cv::Mat::create().
If m is just passed it auto allocating functions, then you don't actually need to set it at all.
I am trying to accomplish something a bit backwards from everyone else. Given an array of sensor data, I wish to print a graph plot of it. My test bench uses a stepper motor to move the input shaft of a sensor, stop, get ADC value of sensor's voltage, repeat.
My current version 0.9 bench does not have a graphical output. The proper end solution will. Currently, I have 35 data points, and I'm looking to get 90 to 100. The results are simply stored in an int array. The index is linear, so it's not a complicated plot, but I'm having problems conceptualizing the plot from bottom-left to top-right to display to the operator. I figure on the TFT screen, I can literally translate an origin and then draw lines from point to point...
Worse, I want to also print out this to a thermal printer, so I'll need to translate this into a sub-384 pixel wide graph. I'm not too worried about the semantics of communicating the image to the printer, but how to convert the array to an image.
It gets better: I'm doing this on an Arduino Mega, so the libraries aren't very robust. At least it has a lot of RAM for the code. :/
Here's an example of when I take my data from the Arduino test and feed it into Excel. I'm not looking for color, but I'd like the graph to appear and this setup not be connected to a computer. Or the network. This is the ESC/POS printer, btw.
The algorithm for this took three main stages:
1) Translate the Y from top left to bottom left.
2) Break up the X into word:bit values.
3) Use Bresenham's algorithm to draw lines between the points. And then figure out how to make the line thicker.
For my exact case, the target bitmap is 384x384, so requires 19k of SRAM to store in memory. I had to ditch the "lame" Arduino Mega and upgrade to the ChipKIT uC32 to pull this off, 32k of RAM, 80 MHz cpu, & twice the I/O!
The way I figured out this was to base my logic on Adafruit's Thermal library for Arduino. In their examples, they include how to convert a 1-bit bitmap into a static array for printing. I used their GFX library to implement the setXY function as well as their GFX Bresenham's algorithm to draw lines between (X,Y)s using my setXY().
It all boiled down to the code in this function I wrote:
// *bitmap is global or class member pointer to byte array of size 384/8*384
// bytesPerRow is 384/8
void setXY(int x, int y) {
// integer divide by 8 (/8) because array size is byte or char
int xByte = x/8;
// modulus 8 (%8) to get the bit to set
uint8_t shifty = x%8;
// right shift because we start from the LEFT
int xVal = 0x80 >> shifty;
// inverts Y from bottom to start of array
int yRow = yMax - y;
// Get the actual byte in the array to manipulate
int offset = yRow*bytesPerRow + xByte;
// Use logical OR in case there is other data in the bitmap,
// such as a frame or a grid
*(bitmap+offset)|=xVal;
}
The big point is to remember with an array, we are starting at the top left of the bitmap, going right across the row, then down one Y row and repeating. The gotchya's are in translating the X into the word:bit combo. You've got to shift from the left (sort-of like translating the Y backwards). Another gotchya is one-off error in bookkeeping for the Y.
I put all of this in a class, which helped prevent me from making one big function to do it all and through better design made the implementation easier than I thought it would be.
Pic of the printout:
Write-up of the project is here.
I'm trying to use the DepthBias property on the rasterizer state in DirectX 11 (D3D11_RASTERIZER_DESC) to help with the z-fighting that occurs when I render in wireframe mode over solid polygons (wireframe overlay), and it seems setting it to any value doesn't change anything to the result. But I noticed something strange... the value is defined as a INT rather than a FLOAT. That doesn't make sense to me, but it still doesn't happen to work as expected. How do we properly set that value if it is a INT that needs to be interpreted as a UNORM in the shader pipeline?
Here's what I do:
Render all geometry
Set the rasterizer to render in wireframe
Render all geometry again
I can clearly see the wireframe overlay, but the z-fighting is horrible. I tried to set the DepthBias to a lot of different values, such as 0.000001, 0.1, 1, 10, 1000 and all the minus equivalent, still no results... obviously, I'm aware when casting the float as integer, all the decimals get cut... meh?
D3D11_RASTERIZER_DESC RasterizerDesc;
ZeroMemory(&RasterizerDesc, sizeof(RasterizerDesc));
RasterizerDesc.FillMode = D3D11_FILL_WIREFRAME;
RasterizerDesc.CullMode = D3D11_CULL_BACK;
RasterizerDesc.FrontCounterClockwise = FALSE;
RasterizerDesc.DepthBias = ???
RasterizerDesc.SlopeScaledDepthBias = 0.0f;
RasterizerDesc.DepthBiasClamp = 0.0f;
RasterizerDesc.DepthClipEnable = TRUE;
RasterizerDesc.ScissorEnable = FALSE;
RasterizerDesc.MultisampleEnable = FALSE;
RasterizerDesc.AntialiasedLineEnable = FALSE;
As anyone figured out how to set the DepthBias properly? Or perhaps it is a bug in DirectX (which I doubt) or again maybe there's a better way to achieve this than using DepthBias?
Thank you!
http://msdn.microsoft.com/en-us/library/windows/desktop/cc308048(v=vs.85).aspx
Depending on whether your depth buffer is UNORM or floating point varies the meaning of the number. In most cases you're just looking for the smallest possible value that gets rid of your z-fighting rather than any specific value. Small values are a small bias, large values are a large bias, but how that equates to a shift numerically depends on the format of your depth buffer.
As for the values you've tried, anything less than 1 would have rounded to zero and had no effect. 1, 10, 1000 may simply not have been enough to fix the issue. In the case of a D24 UNORM depth buffer, the formula would suggest a depth bias of 1000 would offset depth by: 1000 * (1 / 2^24), which equals 0.0000596, a not very significant shift in z-buffering terms.
Does a large value of 100,000 or 1,000,000 fix the z-fighting?
If anyone cares, I made myself a macro to make it easier. Note that this macro will only work if you are using a 32bit float depth buffer format. A different macro might be needed if you are using a different depth buffer format.
#define DEPTH_BIAS_D32_FLOAT(d) (d/(1/pow(2,23)))
That way you can simply set your depth bias using standard values, such as:
RasterizerDesc.DepthBias = DEPTH_BIAS_D32_FLOAT(-0.00001);
I need to develop a method to find the distance of a red line and the bottom of the image.
I already isolate the red line in hsv using some examples...
I know how to do this using MatLab but now i have to use the opencv :s
Someone can tell me how to do this?
You can access each pixel value of the image in following way.
IplImage* img=cvLoadImage("your_image.jpg");
int pixelVal;
for(int x=0;x<img->height;x++){
for(int y=0;y<img->width;y++){
pixelVal=((uchar*)(img->imageData + img->widthStep*x))[y];
}
}
in here,
img->imageData returns a pointer to starting memory location of the image
img->widthStep is the number of bytes in a image row
we access the each pixel value and cast using unsigned char pointer to get int value.
the code comes from a Qt library that helps produce buttons with the shape of an image; it scans through all lines y and all the width x, generating the following change when the rgb part of the pixel coincides with the masking one (mp is the pointer at the start of the line and it is prefilled with 0xff):
*(mp + (x >> 3)) &= ~(1 << (x & 7));
I can't really interpret it; anyone with background to give a hand?
From the looks of the code, mp points to the current line of a 1 bit per pixel image. The code clears the bit representing the pixel at X. It converts the X offset into a byte offset (x >> 3) and then logical AND's the byte with a mask created from the inverse 1 shifted left by the X position within the byte.
for the mortals; ok, background: http://www.cprogramming.com/tutorial/bitwise_operators.html; &= means we are gonna do a bitwise multiplication; in the rhs, the ~ is for the complement, so it flips 1s with 0s and viceversa; 7 in binary has 3 ones in the end and all zeros at front, so x & 7 preserves the last 3 bits in x; combined with << this will move the 1 in the first bit from the char 1 to the left a certain number of places in accordance with the exponent; since the exponent is only using the last 3 bits of x, it is smaller than 8(2^3); so the bit with the one will get in the position 1-8 within the 8 bits of the char; the flip ~ will turn the thing into all 1s except in that magic position; the multiplication performed by the &= will preserve everything in the lhs except that one bit. now for the lhs; we are kicking the last byte or the last 3 bits of x out with >> in a right shift operation; this means the location we'll modify the same byte (char type of mp) for every 8 increments of x; when we "jump", we'll do so by only one byte; when x=9 it will go to mp+1, when x= 17 it will go to mp+2; so it is like x/2^3 in integer operations, but in one shift operation; ok, now we have the elements to understand the whole thing;
tmask has been prefilled with 0xff, all ones; which means that it will be passive upon the &= operation, preserving what the rhs dictactes; this means that in case the there's a hit in an if statement that checks if the particular pixel is equal to the background, then this line is executed and we will wipe the specific bit related to the pixel;