I'm unclear as to what value to set for NSOpenGLPFAColorSize when creating an NSOpenGLPixelFormat. From the documentation it states:
Value is a nonnegative buffer size specification. A color buffer that most closely matches the specified size is preferred. If unspecified, OpenGL chooses a color size that matches the screen.
But does this mean the number of bits per pixel? Or bits per component? For example, if it were set 24 and interpreted as bits per pixel then that would mean that each RGBA color would have 6-bits per component for a total of 24-bits for the entire RGBA pixel.
However, if it is to be interpreted as bits per component then that would mean 24-bits for each of the red, green, blue and alpha components to make a 96-bit RGBA pixel.
I'm inclined to believe that it means bits per component as the values I've seen set in sample code ranges from 8, 16, 24, 32 and everything but 24 makes sense when interpreted as bits per component. It would be nice though to have some definitive answer.
Note: Edited to reflect that pixels in OpenGL are RGBA not RGB.
After scouring the documentation further I came across the NSOpenGLPFAColorFloat attribute, which according to the documentation:
A Boolean attribute. If present, this attribute indicates that only renderers that are capable using buffers storing floating point pixels are considered. This should be accompanied by a NSOpenGLPFAColorSize of 64 (for half float pixel components) or 128 (for full float pixel components). Note, not all hardware supports floating point color buffers thus the returned pixel format could be NULL.
With that additional information it must mean bits per pixel.
I did some experimenting as well, setting NSOpenGLPFAColorSize to each of 8, 16, 24 & 32 and then checking what I got back. In each case I was returned a pixel format with NSOpenGLPFAColorSize set to 32 - meaning 32-bits per RGBA pixel. Just passing NSOpenGLPFAColorFloat with nothing set for the Color Size is enough to get back a pixel format with 64-bits per pixel.
Related
I have the task to simulate a camera with a full well capacity of 10.000 Photons per sensor element
in numpy. My first Idea was to do it like that:
camera = np.random.normal(0.0,1/10000,np.shape(img))
Imgwithnoise= img+camera
but it hardly shows an effect.
Has someone an idea how to do it?
From what I interpret from your question, if each physical pixel of the sensor has a 10,000 photon limit, this points to the brightest a digital pixel can be on your image. Similarly, 0 incident photons make the darkest pixels of the image.
You have to create a map from the physical sensor to the digital image. For the sake of simplicity, let's say we work with a grayscale image.
Your first task is to fix the colour bit-depth of the image. That is to say, is your image an 8-bit colour image? (Which usually is the case) If so, the brightest pixel has a brightness value = 255 (= 28 - 1, for 8 bits.) The darkest pixel is always chosen to have a value 0.
So you'd have to map from the range 0 --> 10,000 (sensor) to 0 --> 255 (image). The most natural idea would be to do a linear map (i.e. every pixel of the image is obtained by the same multiplicative factor from every pixel of the sensor), but to correctly interpret (according to the human eye) the brightness produced by n incident photons, often different transfer functions are used.
A transfer function in a simplified version is just a mathematical function doing this map - logarithmic TFs are quite common.
Also, since it seems like you're generating noise, it is unwise and conceptually wrong to add camera itself to the image img. What you should do, is fix a noise threshold first - this can correspond to the maximum number of photons that can affect a pixel reading as the maximum noise value. Then you generate random numbers (according to some distribution, if so required) in the range 0 --> noise_threshold. Finally, you use the map created earlier to add this noise to the image array.
Hope this helps and is in tune with what you wish to do. Cheers!
MSDN's truetype font article (https://learn.microsoft.com/en-us/typography/opentype/otspec160/ttch01) gives the following for converting FUnits to pixels:
Values in the em square are converted to values in the pixel coordinate system by multiplying them by a scale. This scale is:
pointSize * resolution / ( 72 points per inch * units_per_em )
where pointSize is the size at which the glyph is to be displayed, and resolution is the resolution of the output device. The 72 in the denominator reflects the number of points per inch.
For example, assume that a glyph feature is 550 FUnits in length on a 72 dpi screen at 18 point. There are 2048 units per em. The following calculation reveals that the feature is 4.83 pixels long.
550 * 18 * 72 / ( 72 * 2048 ) = 4.83
Questions:
It says "pointSize is the size at which the glyph is to be displayed." How does one compute this, and what units is it in?
It says "resolution is the resolution of the output device". Is this in DPI? Where would I get this information?
It says "72 in the denominator reflects the number of points per inch." Is this related to DPI or no?
In the example, it says '18 point'. Is this 18 used in computing the resolution or the pointSize?
Unfortunately, Apple's documentation is more or less the same, and other than that there are barely any resources other than just reading the source code of stb_truetype.
It says "pointSize is the size at which the glyph is to be displayed." How does one compute this, and what units is it in?
You don’t compute the point size, you set it. It’s the nominal size you want the font to be displayed in (think the font menu in a text editor). The ‘point size’ is a traditional typographical measurement system, with ‘point’ being roughly 1/72 of an inch. This brings the other question:
It says "72 in the denominator reflects the number of points per inch." Is this related to DPI or no?
No. Again, these are typographical points — the same unit you set the point size with. That’s why it’s part of the denominator in the first place: the point size is expressed in a measurement system of 72 points to an inch, and that has to be somehow taken into account in the equation.
Now, the typographical points are different from the output device’s dots or pixels. While in the early days of desktop publishing it was common to have a screen resolution of 72 pixels per inch that indeed corresponded to typographical system of 72 points per inch (no coincidence in that), these days the output resolution can, of course, vary quite dramatically, so it’s important to keep the point vs pixel distinction in mind.
In the example, it says '18 point'. Is this 18 used in computing the resolution or the pointSize?
Neither. It is the point size; see above. The entire example could be translated as follows. With a font based on 2048 units per em, if a particular glyph feature is 550 em units long and the glyph gets displayed at the size of 18 points (that is, 18/72 of an inch) on a device with screen resolution of 72 pixels per inch, the pixel size of that feature will be 4.84.
It says "resolution is the resolution of the output device". Is this in DPI? Where would I get this information?
It’s DPI/PPI, yes. You have to query some system API for that information or just hardcode the value if you’re targeting a specific device.
i need to set color by byte type or integer, not float values.
How can i assign this type into gl_FragColor?
Dividing the value by 256 wont give me the wanted precision.
My main purpose is to know the specific value of each bit in the color buffer, if i draw line only with specific color.
for example i want that in the color buffer at the red value of pixel only 2 lsbits will be on, what color value should i transfer to gl_FragColor?
If i had an option to write byte type values, i would write the value 3 to red component
Thanks
As far as I know, gl_FragColor must always be floating point. However, if you know the colour buffer is 8 bits per channel it shouldn't be hard to force whatever you want into it. You might consider
gl_FragColor = vec4(floor(number)/255.0, 0, 0, 0);
for example. The more recent versions of GLSL support bitwise operations, but I doubt GLES2 does.
If you want to draw to specific bits, maybe...
glEnable(GL_BLEND);
glBlendFunc(GL_ONE, GL_ONE);
...
gl_FragColor = vec4(pow(2.0, bitIndex)/255.0, 0, 0, 0);
I haven't tested this but see no reason why it couldn't work assuming geometry never overlaps (in which case the bit would overflow into the next).
I want to know how much data can be embedded into an image of different sizes.
For example in 30kb image file how much data can be stored without distortion of the image.
it depends on the image type , algoridum , if i take a example as a 24bitmap image to store ASCII character
To store a one ASCII Character = Number of Pixels / 8 (one ASCII = 8bits )
It depends on two points:
How much bits per pixel in your image.
How much bits you will embed in one pixel .
O.K lets suppose that your color model is RGB and each pixel = 8*3 bits (one byte for each color), and you want embed 3 bits in one pixel.
data that can be embedded into an image = (number of pixels * 3) bits
If you would use the LSB to hide your information this would give 30000Bits of available space to use. 3750 bytes.
As the LSB represents 1 or 0 into a byte that gets values from 0-256 this gives you in the worst case scenario that you are going to modify all the LSBs distortion of 1/256 that equals 0,4%.
In the statistical average scenario you would get 0,2% distortion.
So depends on which bit of the byte you are going to change.
When checking this method, I was expecting for red, green and blue to be in the 0-255 range. Instead, it's in 0-1.
Am I the only one who thinks this is weird?
Is there any reason not o use the more common 0-255 values for RGB, or even hex numbers (as in html)?
In my opinion this is not weird. Both 0-255 and 0.0-1.0 levels are widely used in different platforms. You can always convert that by using something like this:
#define FLOAT_COLOR_VALUE(n) (n)/255.0
The reason sometimes RGB values are represented as float values rather than 0 to 255 is because 0 to 255 assumes you are using 8 bits to represent each colour component and hence have to use 24 bits for each colour in your frame buffers. This may not be the case if you are using displays that only support 256 colours in total or more than 16 million etc.
In theory then can be an infinite number of shades of red, green or blue. The number of bits you use to represent them depends on how accurate you need to represent colour and how much memory you have on graphics cards to represent images etc.
For many cases 0 to 255 is fine. But there is another world out there where it isn't fine, and for those devices / accurate rendering requirements, floating point numbers provide a much needed alternative.