I have a question regarding patch size. Patch size is "measured in pixels."
When patch-size is equal to 2, does this number means the width of a patch in pixels (i.e. 2 pixels x 2 pixels) or the area of the patch (i.e.patch occupies 2 pixels)?
Related
Determine the number of bytes necessary to store an uncompressed RGB color image of size 640 ×
480 pixels using 8, 10, 12, and 14 bits per color channel?
I know how to calculate the size of image by using Size = (rows * columns * bpp) but i cannot understand what bit per color channel means in this question
Bits per color channel, is the number of bits that are used for storing a color component of a single pixel.
RGB color space has 3 channels: Red, Green and Blue.
The "bits per color channel" (bpc) is the number of bits that are used for storing each component (e.g 8 bits for red, 8 bits for green, 8 bits for blue).
The dynamic range of 8 bits is [0, 255] (255 = 2^8-1).
8 bpc applies 24 bits per pixel (bpp).
The number of bits per pixel defines the Color Depth of the image.
24 bpp can represent 2^24 = 16,777,216 different colors.
More bits applies larger range: 12 bits range is [0, 4095] (4095 = 2^12-1), and much larger colors variety can be coded in each pixel.
12 bpc applies 36 bpp, and can represent 2^36 = 68,719,476,736 different colors.
For more information refer to BIT DEPTH TUTORIAL
Remark: The bits per channel is not directly related to memory storage (e.g. it's common to store 12 bit in 2 bytes [16 bits] in memory).
As you probably know, an image is built as a matrix of pixels.
Following figure illustrates the structure of an RGB image:
Following figure illustrates a pixel with 8 bits per color channel:
Following figure illustrates a pixel with 10 bits per color channel:
Following figure illustrates a pixel with 12 bits per color channel:
There subject is much wider than that, but I think that's enough...
I have a random satellite image that can be divided into 2 classes:
1) no data values (all pixel values are equal and randomly vary from image to image)
2) footprint (all pixel values are random)
A sum of all the values of no data and footprint gives a bounding box.
What is the fastest algorithm for dividing a random satellite image into these 2 classes?
UPDATE:
Are no data value-areas always at the border of the image?
No data value could not be inside of the footprint and it may be absent.
Are no data-values always black?
No, it's value may vary from picture to picture. But always equal each other inside one image.
Does this no data value-color appear within the footprint?
Most of the images are grayscale and may be in 16, 8-bit data formats. But i need general algorithm. Case specific algorithm is not what i want.
UPDATE 2:
My current approach is:
1) Take every pixel values that lay on the bounding box boarder
2) Take most frequent value and set it as nodata
3) Reclassify image into 2 classes with values: NoData value - nodata class,
1 - footprint class
4) Convert rasters pixels with value 1 into vector format
For big images it take more than 5 minutes to get vector boarders of footprint.
A simple way for you would be to multiply the pixel intensities. From the images you uploaded, the no data values are esentially of 0 intensity. Instead of going for complex methods, simply multiply the image intensities by 1000.
I used OpenCV and could segment out the regions in under 4 lines of code.
Here's an example -
Maybe it's just my head spinning, but there seems to be no documentation on the units of measure for HPDF's HPDF_Font_TextWidth() function, nor can I figure it out.
The number I get for a particular text of 7 characters is around 3000. The rendered text seems to be around 80 pixels, which is also returned from HPDF_Page_TextWidth().
HPDF_Font_TextWidth() does not know the font size so it must use some other unit. What is it?
And is that the same unit that HPDF_Font_GetBBox() returns?
I'm actually trying to put text in the center of a rectangle, and need the width and height of the text in the units of the rectangle.
This is an old post but I just stumbled upon it because I had the same issue. As far as I know, looking into the source of HPDF_Font_GetUnicodeWidth(), the units that it returns needs to be multiplied by the font size, then divided by 1000 to get the width in points, which is what the rest of the PDF coordinate system uses.
width = (HPDF_Font_TextWidth() * font_size) / 1000.0;
All the following return EM units, which must be divided by 1000 and multiplied by the point size to get points, as stated above:
The units are relative to the baseline. Descender, BBox left & bottom are negative. The zone between caps Height and ascender is for diacritics.
To calculate the height of a slug of text, compute caps height less descender, or ascender less descender if your text has upper-case diacritics.
Keyword: Haru PDF
My math must be very rusty. I have to come up with an algorithm that will take a known:
x
y
width
height
of elements in a document and translate them to the same area on a different hardware device. For example, The document is being created for print (let's assume 8.5"x11" letter size) and elements inside of this document will then be transferred to a proprietary e-reader.
Also, the known facts about the e-reader, the screen is 825x1200 pixels portrait. There are 150 pixels per inch.
I am given the source elements from the printed document in points (72 Postscript points per inch).
So far I have an algorithm that get's close, but it needs to be exact, and I have a feeling I need to incorporate aspect ratio into the picture. What I am doing now is:
x (in pixels) = ( x(in points)/width(of document in points) ) * width(of ereader in pixels)
etc.
Any clues?
Thanks!
You may want to revert the order of your operations to reduce the effect of integer truncation, as follows:
x (in pixels) = x(in points) * width(of ereader in pixels) / width(of document in points)
I don't think you have an aspect ratio problem, unless you forgot to mention that your e-reader device has non-square pixels. In that case you will have a different amount of pixels per inch horizontally and vertically on the device's screen, so you will use the horizontal ppi for x and the vertical ppi for y.
assuming your coordinates are integer numbers, the formula x/width is truncating (integer division). What you need is to perform the division/multiplication in floating point numbers, then truncate. Something like
(int)(((double)x)/width1*width2)
should do the trick (using C-like conversion to double and int)
I have an application that is on a mobile device. I am moving resolutions of my app from 240W x 320L to 640W X 480L.
I have a bunch of columns that have their width in pixels (say 55 for example). I need to convert this to the new resolution.
"Easy", I thought 640/240 = 2 2/3. So I just take 55 * 2.6666667 and that is my new width.
Alas, that did not work. My columns (all together) are larger than my screen size now.
I tried 55 * 2 and that is too small. I am sure I can get there with trial an error, but I want to know an exact ratio.
So, what am I missing? how do I calculate my new column widths (other than by trial and error).
Rounding is your problem; Suppose that you have 24 columns of 10 pixels on the 240 pixel display. You calculate the new width: 10*2.667 = 27 so the total width sums to: 648 > 640. Oops...
To get this right you need to scale the absolute location of the column. That is if column number k begins on x-coordinate = X then after scaling it should begin on round(X*2.667). After this subtract rounded right side X from rounded left side X to get the width. This way you will round widths down and some up, but the total width will remain inside your limits.
The screen DPI is changing when resolution changes. So you need to take this into account.
Check this link about DPI Aware apps and search according to your platform (Native or CF)
I think your logic is good, but maybe you had rounding errors? If you want to make sure the total width is less than the screen resolution, after multiplying by the scale factor you should always round down to the nearest integer to get the width in pixels.
Also, if your columns have any padding, borders, or other space between them, you would have to take that into account as well.
If you can run on a desktop environment, I know there are "pixel ruler" sort of tools to actually measure things on the screen, you can search Google for them.