I am converting RGB to HSV using built in function of UIColour: - (BOOL)getHue:(CGFloat *)hue saturation:(CGFloat *)saturation brightness:(CGFloat *)brightness alpha:(CGFloat *)alpha but for some RGB it is not giving correct output.
CGFloat h,s,v,a;
UIColor *tColor=[UIColor colorWithRed:(230.0/255.0) green:(226.0/255.0) blue:(226.0/255.0) alpha:1.0];
BOOL success=[tColor getHue:&h saturation:&s brightness:&v alpha:&a];
NSLog(#"Output-> Success:%d, hue:%f, sat:%f, value:%f, alpha:%f",success,h,s,v,a);
Actual output:
Output-> Success:1, hue:1.000000, sat:0.017391, value:0.901961, alpha:1.000000
Expected output:
hue:0, sat:0.017391, value:0.901961, alpha:1.000000
Note: I have derived this expected output from some online conversion tools(ex: http://www.rapidtables.com/convert/color/rgb-to-hsv.htm)
You can see clearly difference in Hue? So, why such difference in Hue and how can I get my expected output?
While most of the rest of the world defines "hue" as going from 0 to 360 degrees, for UIColor it's 0.0 to 1.0.
Actually, just as 360.000 degrees is identical to 0.000 in geometry or someone else's hue, so we have with UIColor's hue that 1.000 is identical to 0.000 (hallucinate as many zero digits after the decimal point as you like, and in binary if you prefer.)
So, your "actual output" and "expected output" are identical. In coding, keep hue in the range 0.000 to 0.999, and change 1.000 to 0.000 to avoid trouble.
Hue in HSB or HSL is measured as degrees around a colour circle, starting with red at 0° and wrapping back around to red at 360°; so a hue of 0° is the same as a hue of 360°. UIColor maps this range (0–360°) to the values 0–1 (0°=0.0, 360°=1.0).
Related
I have been trying to implement some of the layer blending modes of GIMP (GEGL) to Python. Currently, I am stuck in Subtract Blending mode. As per documentation, Subtract = max(Background - Foreground, 0). However, doing a simple test in GIMP, with Background image = (205,36,50) and Foreground image = (125,38,85), the resultant composite image/colour comes to be (170, 234, 0) which doesn't quite follow the math above.
As per understanding, Subtract does not use Alpha Blending. So, could this be a compositing issue? Or Subtract follows different math? More details and background can be find in a separate SO question.
EDIT [14/10/2021]:
I tried with this image as my Source. Performed following steps on images normalised in range [0, 1]:
Applied a Colour Dodge (no prior conversion from sRGB -> linear RGB was done) and obtained this from my implementation which matches with GIMP result.
sRGB -> linear RGB conversion on Colour Dodge and Source image. [Reference]
Apply Subtract blending with Background = Colour Dodge and Foreground = Source Image
Reconvert linear RGB-> sRGB
I obtain this from POC. Left RGB triplet: (69,60,34); Right RGB triplet: (3,0,192). And the GIMP result. Left RGB triplet: (69,60,35); Right RGB triplet: (4,255,255)
If you are looking at channel values in the 0 ➞ 255 range they are likely gamma-corrected. The operation is possibly done like this:
convert each layer to "linear light" in the 0.0 ➞ 1.0 range using something like
L = ((V/255) ** gamma) (*)
apply the "difference" formula
convert the result back to gamma-corrected:
V = (255 * (Diff ** (1/gamma)))
With gamma=2.2 you obtain 170 for the Red channel, but I don't see why you get 234 on the Green channel.
(*) The actual formula has a special case for the very low values IIRC.
I have posted similar question 3 days ago ("increase pixel size"). However, so far, no answer. Therefore, I decided to start a new thread and make my question more precise.
I have 2D matrix 68 per 68 and I want to make a heat map from it. I did it, but
the problem is that for the matrix of this size cells become really small.
https://www.dropbox.com/s/b4ygdg0csa7d5y5/TEST_68x68.png?dl=0
Therefore, I want to increase size of a cell, for example twice and keep it fixed.
So, my idea was to define a matrix, which will be twice bigger than 68/68 that is 68*2/68*2 and then increase size of cell accordingly. I tried it: https://www.dropbox.com/s/spwo6zik1f077z3/TEST_incresedTwice.png?dl=0
However, dimensions of cells are also scaled. They have the same size like in the standard 68/68 matrix (see the first link). The cells also move. For example, instead of being bound to their original coordinates, all my values are moved by 10. I know why. The question is, how to prevent GNUPLOT from doing it?
Summarizing, I want to increase size of cells, keep their dimensions fixed and plot these bigger cells on a 68*2/68*2 matrix.
Any suggestions? Thank you.
Thank you.
Code below:
set terminal png transparent truecolor nocrop enhanced size 2000,2000 font
"arial bold,30”
set output 'TEST_now.png'
set size ratio 1
set palette rgbformulae -21,-22,-23
set xrange[-0.5:136.5]
set yrange[-0.5:136.5]
plot "matrix.dat" matrix using ($1*2):($2*2):3 with image not
With the image plotting style you get 68×68 pixels, all of the same size. You cannot increase the size of single pixels.
In your data file you have many entries with 0.00 which is what makes the white pixels. And, in the data file you have section like
0.000 0.457 0.000 0.000
0.000 0.000 0.000 0.000
0.000 0.073 0.337 0.000
0.002 0.993 0.916 0.000
0.000 0.003 0.000 0.000
and here I wouldn't even know how you would expect the pixels to be enlarged.
On possibility would be to plot every pixel as square point and use a large point size. This however leads to overlapping of immediately neighbouring points. To reduce this problem a bit, you could first draw all points with 0 < z <= 0.1, then those with 0.1 < z <= 0.2 and so on:
set terminal pngcairo transparent truecolor nocrop enhanced size 2000,2000 font "arial bold,30”
set output 'TEST_now.png'
set size ratio 1
set palette rgbformulae -21,-22,-23
set autoscale xfix
set autoscale yfix
set offsets 1,1,1,1
plot for [i=1:10] "matrix.dat" matrix using ($3 > 0.1*(i-1) && $3 <= 0.1*i ? $1 : 1/0):2:3 with points pt 5 ps 7 palette notitle
I don't know of any "smarter" solution, even when disregarding gnuplot's abilities.
I've got a bunch of thumbnails/icons packed right up next to each other in a texture map / sprite sheet. From a pixel to pixel relationship, these are being scaled up from being 145 pixels square to 238 screen pixels square. I was expecting to get +-1 or 2 pixel accuracy on the edges of the box when accessing the texture coordinates, so I'm also drawing a 4 pixel outline overtop of the thumbnail to hide this probable artifact. But I'm seeing huge variations in accuracy. Sometimes it's off in one direction, sometimes the other.
I've checked over the math and I can't figure out what's happening.
The the thumbnail is being scaled up about 1.64 times. So a single pixel off in the source texture coordinate could result in around 2 pixels off on the screen. The 4 pixel white frame over top is being drawn at a 1-1 pixel to fragment relationship and is supposed to cover about 2 pixels on either side of the edge of the box. That part is working. Here I've turned off the border to show how far off the texture coordinates are....
I can tweak the numbers manually to make it go away. But I have to shrink the texture coordinate width/height by several source pixels and in some cases add (or subtract) 5 or 6 pixels to the starting point. I really just want the math to work out or to figure out what I'm doing wrong here. This sort of stuff drives me nuts!
A bunch of crap to know.
The shader is doing the texture coordinate offsetting in the vertex shader...
v_fragmentTexCoord0 = vec2((a_vertexTexCoord0.x * u_texScale) + u_texOffset.s, (a_vertexTexCoord0.y * u_texScale) + u_texOffset.t);
gl_Position = u_modelViewProjectionMatrix * vec4(a_vertexPosition,1.0);
This object is a box which is a triangle strip with 2 tris.
Not that it should matter, but matrix applied to the model isn't doing any scaling. The box is to screen scale. The scaling is happening only in the texture coordinates that are being supplied.
The texture coordinates of the object as seen above are 0.00 - 0.07, then in the shader have an addition of an offset amount which is different per thumbnail. .07 out of 2048 is like 143. Originally I had it at .0708 which should be closer to 145 it was worse and showed more like 148 pixels from the texture. To get it to only show 145 source pixels I have to make it .0.06835 which is 140 pixels.
I've tried doing the math in a calculator and typing in the numbers directly. I've also tried doing like =1305/2048. These are going in to GLfloats not doubles.
This texture map image is PNG and is loaded with these settings:
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MIN_FILTER,GL_NEAREST);
glTexParameteri(GL_TEXTURE_2D,GL_TEXTURE_MAG_FILTER,GL_NEAREST);
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_S, GL_CLAMP_TO_EDGE );
glTexParameteri( GL_TEXTURE_2D, GL_TEXTURE_WRAP_T, GL_CLAMP_TO_EDGE );
but I've also tried GL_LINEAR with no apparent difference.
I'm not having any accuracy problems on other textures (in the same texture map) where I'm not doing the texture scaling.
It doesn't get farther off as the coords get higher. In the image above the NEG MAP thumb is right next to the HEAT MAP thumb and are off in different directions but correct at the seam.
here's the offset data for those two..
filterTypes[FT_gradientMap20].thumbTexOffsetS = 0.63720703125;
filterTypes[FT_gradientMap20].thumbTexOffsetT = 0.1416015625;
filterTypes[FT_gradientMap21].thumbTexOffsetS = 0.7080078125;
filterTypes[FT_gradientMap21].thumbTexOffsetT = 0.1416015625;
==== UPDATE ====
A couple of things off the bat I realized I was doing wrong and are discussed over here: OpenGL Texture Coordinates in Pixel Space
The width of a single thumbnail is 145. But that would be 0-144, with 145 starting the next one. I was using a width of 145 so that's going to be 1 pixel too big. Using the above center of pixel type math, we should actually go from the center of 0 to the center of 144. 144.5 - 0.5 = 144.
Using his formula of (2i + 1)/(2N) I made new offset amounts for each of the starting points and used the 144/2048 as the width. That made things better but still off in some areas. And again still off in one direction sometimes and the other other times. Although consistent for each x or y position.
Using a width of 143 proves better results. But I can fix them all by just adjusting the numbers manually to work. I want to have the math to make it work out right.
... or.. maybe it has something to do with min/mag filtering - although I read up on that and what I'm doing seems right for this case.
After a lot of experiments and having to create a grid-lined guide texture so I could see exactly how far off each texture was... I finally got it!
It's pretty simple actually.
uniform mat4 u_modelViewProjectionMatrix;
uniform mediump vec2 u_texOffset;
uniform mediump float u_texScale;
attribute vec3 a_vertexPosition;
attribute mediump vec2 a_vertexTexCoord0;
The precision of the texture coordinates. By specifying mediump it just fixed itself. I suspect this also would help solve the problem I was having in this question:
Why is a texture coordinate of 1.0 getting beyond the edge of the texture?
Once I did that, I had to go back to my original 145 width (which still seems wrong but oh well). And for what it's worth I ended up then going back to all my original math on all the texture coordinates. The "center of pixel" method was showing more of the neighboring pixels than the straight /2048 did.
I want to smooth some hand draw lines in iphone.
I have used the following code in
http://webdocs.cs.ualberta.ca/~graphics/books/GraphicsGems/gems/FitCurves.c
However, I found that some bezier curved was wrong, the second control point and end point is invalid.
Did anybody have the same problem before?
Thanks.
Bezier Curves are not designed to go through the provided vertices!
They are designed to shape a smooth curve influenced by the control points.
First you must decide if you want to interpolate between missing points,
or if you want to filter non smooth data:
Filtering
You should look at "sliding average" with a small averaging window. (try 5 - 10 pixel).
This works as follows: (look for wiki for a detailed description)
I use here an average window of 10 points:
start by calculation of the average of points 0 - 9, and output the result as result point 0
then calculate the average of point 1 - 10 and output, result 1
And so on.
Interpolation
If you want to interpolate between (missing) points using a smooth curve, you could use piece - wise cubic splines:
You calculate the coefficients of a cubic polygon through 3 vertices.
You start with calculating the cubic polygon through:
Point[0] - Point[2], but you draw your output only from Point[0] to Point[1] .
Then you move on one step: and calculate through
Point[1] - Point[3], but you draw only from p1 to p2.
And so on.
You need to search on wiki for cubic interpolation for a detailed explanation how to caluclate a cubic polygon (sometimes called cubic spline).
I want to draw pentagon rotated to an angle of 45 degree. How to write code for this shape?
Since this question is tagged 'wolframalpha' is assume that the 'code' you refer to should be entered at the wolfram alpha site. Entering Pentagon rotated 45 degrees there gives me a figure of a rotated pentagon.
In Mathematica:
WolframAlpha["Pentagon rotated 45 degrees", {{"VisualRepresentation",1}, "Content"}]