I'm trying to understand RGB to YUV conversion equation.
and I've got some implementation from https://sistenix.com/rgb2ycbcr.html.
But I can't understand how it to be made as the below especially about R in (4)?
R<<6 + R<<1 ?
How does (65.7388*R)/256 can be represented as R<<6 + R<<1 ?
You are missing a part, (65.7388*R)/256 becomes (R<<6 + R<<1)>>8
The steps are actually pretty easy: approximating to the nearest integer (65.7388*R)/256 becomes (66*R)/256 that can be written as (64*R + 2*R)/256. A multiplication by 2 is equal to a shift to the left thus 2*R becomes R<<1 and 64*R becomes R<<6. In the same way, a division by 2 is equal to a shift to the right, thus /256 becomes >>8
Related
I saw this piece of J code
(**+)&.+.
in RosettaCode FFT section. It is supposed to clean up insignificant digits of FFT result. For example
(**+)&.+. 4e_16j2
gives
0j2
It is similar to Chop function of Mathematica for example.
However
(**+)&.+. _4j_2
gives
4j2 (instead of _4j_2)
which is obviously incorrect.
The question is what is the correct way in J to chop off insignificant digits?
The monad + (as opposed to the dyad +) is "complex conjugate", which is the culprit in producing 4j2 as opposed to _4j_2.
The editor responsible for (**+)&.+. on RosettaCode probably intended to use |, absolute value, in place of +, thus:
(**|)&.+. _4j_2 4e_16j2
_4j_2 0j2
round in the "numeric" package is [ * [: <. 0.5 + %~. You can use it as follows:
require 'numeric'
(0.01&round)&.+. _1.5j_4.6 4e_16j2 2j4e_16
_1.5j_4.6 0j2 2
The code given in the question, corrected to use | instead of + is (**|)&.+. and it is using a byproduct of operating on numbers to round them. You are taking each part of a complex number (&.+.) and multiplying (*) its absolute value (|) by its sign (*). You could achieve the same sort of effect by adding and subtracting a constant from your number with something like 10j10 -~ 10j10 + ].
[ * [: <. 0.5 + %~ doesn't use any byproducts, but rather directly rounds the number to the desired precision. %~ divides y by x, so that if you're rounding 0.3579 to two decimal places, indicated by an x of 0.01, your first step gets you 35.79. You then add 0.5 (0.5 +) and take the floor ([: <.), which is the same as rounding to zero places (35.79 + 0.5 = 36.29, the floor of which is 36). The final step is to multiply by x ([ *) to undo what was done with %~.
While it is tempting to create a complex version of round with [ * [: <. 0.5j0.5 + %~, using <. on a complex number produces the complex floor, which is probably not be what you are after. If you expect the imaginary and real components to be rounded independently, go with applying round under +.. I think the following gives you a taste of how the complex floor is different than taking the floor of each part of the complex number:
<. 0.7 0j0.7 0.6j0.7 0.7j0.6
0 0 0j1 1
This helps explain the following:
1 ([ * [: <. 0.5j0.5 + %~) 0.2 0j0.2 0.1j0.2 0.2j0.1
1 0j1 0j1 1
"Rounding" 0.2 to 1 caught me off-guard, but it is because 0.2 + 0.5i0.5 = 0.7i0.5, and <. 07j0.5 has a complex floor of 1. The same goes for 0j0.2 "rounding" to 0j1.
If you just want the nearest number where both parts of the complex number are integers, you can use ([: <. 0.5 + ])&.+.:
([: <. 0.5 + ])&.+. 0.2 0j0.2 0.1j0.2 0.2j0.1
0 0 0 0
([: <. 0.5 + ])&.+. 0.7 0j0.7 0.6j0.7 0.7j0.6
1 0j1 1j1 1j1
The one I've been using is (**#|) which does not have this problem.
Specifically in this case, this seems to do what you want:
(**#|)&.+.
I understand how to render (two dimensional) "Escape Time Group" fractals (Julia and Mandelbrot), but I can't seem to get a Mobius Transformation or a Newton Basin rendered.
I'm trying to render them using the same method (by recursively using the polynomial equation on each pixel 'n' times), but I have a feeling these fractals are rendered using totally different methods. Mobius 'Transformation' implies that an image must already exist, and then be transformed to produce the geometry, and the Newton Basin seems to plot each point, not just points that fall into a set.
How are these fractals graphed? Are they graphed using the same iterative methods as the Julia and Mandelbrot?
Equations I'm Using:
Julia: Zn+1 = Zn^2 + C
Where Z is a complex number representing a pixel, and C is a complex constant (Correct).
Mandelbrot: Cn+1 = Cn^2 + Z
Where Z is a complex number representing a pixel, and C is the complex number (0, 0), and is compounded each step (The reverse of the Julia, correct).
Newton Basin: Zn+1 = Zn - (Zn^x - a) / (Zn^y - a)
Where Z is a complex number representing a pixel, x and y are exponents of various degrees, and a is a complex constant (Incorrect - creating a centered, eight legged 'line star').
Mobius Transformation: Zn+1 = (aZn + b) / (cZn + d)
Where Z is a complex number representing a pixel, and a, b, c, and d are complex constants (Incorrect, everything falls into the set).
So how are the Newton Basin and Mobius Transformation plotted on the complex plane?
Update: Mobius Transformations are just that; transformations.
"Every Möbius transformation is
a composition of translations,
rotations, zooms (dilations) and
inversions."
To perform a Mobius Transformation, a shape, picture, smear, etc. must be present already in order to transform it.
Now how about those Newton Basins?
Update 2: My math was wrong for the Newton Basin. The denominator at the end of the equation is (supposed to be) the derivative of the original function. The function can be understood by studying 'NewtonRoot.m' from the MIT MatLab source-code. A search engine can find it quite easily. I'm still at a loss as to how to graph it on the complex plane, though...
Newton Basin:
f(x) = x - f(x) / f'(x)
In Mandelbrot and Julia sets you terminate the inner loop if it exceeds a certain threshold as a measurement how fast the orbit "reaches" infinity
if(|z| > 4) { stop }
For newton fractals it is the other way round: Since the newton method is usually converging towards a certain value we are interested how fast it reaches its limit, which can be done by checking when the difference of two consecutive values drops below a certain value (usually 10^-9 is a good value)
if(|z[n] - z[n-1]| < epsilon) { stop }
I am doing ray tracing with sphere. When we solve quadratic equation and get two roots then which value we need to take? My understanding is that we need to take smallest value. But with that i get wrong results when i put that value in calculating intersection point and further lighting calculations. When I take larger one it gives correct results. I saw some examples on the net and some of them are taking smaller one and others are taking larger. I am really confused which one is correct and why.
Suppose the origin of the ray is O and the direction is R (ideally a unit vector). Then the ray is defined by the parametric equation O + tR. Break this into components Ox + tRx, Oy + tRy and Oz + tRz. Substitute these into the equation for the circle x^2 + y^2 + z^2 = 0. This produces a quadratic equation with the variable t. Find the roots of the equation.
Now, if you have no real roots, the ray doesn't hit the sphere. If you have one real root then you hit the side of the sphere. If you have two real roots, then you hit the sphere twice. You want the closer root (the smaller t) unless t is negative in which case the intersection point is behind you and you don't care. If both roots are negative, then both intersection points are behind the origin of the ray and you can ignore them.
If the sphere is transformed away from the origin and you care about rotation and scaling of the sphere, then the equation of the sphere becomes more complex with xy, yz, xz, x, y and z terms. A general quadric shape is defined as Ax^2 + By^2 + Cy^2 + Dxy + Eyz + Fxz + Gx + Hy + Jz + K = 0. The principle above still applies. Substitute the parametric line equation in, solve for t, take the smallest non-negative root.
Your intersection point is O+tR where t is the smallest non-negative root. From there, I don't know why your lighting calculations would be off.
I have a class implementing an audio stream that can be read at varying speed (including reverse and fast varying / "scratching")... I use linear interpolation for the read part and everything works quite decently..
But now I want to implement writing to the stream at varying speed as well and that requires me to implement a kind of "reverse interpolation" i.e. Deduce the input sample vector Z that, interpolated with vector Y will produce the output X (which I'm trying to write)..
I've managed to do it for constant speeds, but generalising for varying speeds (e.g accelerating or decelerating) is proving more complicated..
I imagine this problem has been solved repeatedly, but I can't seem to find many clues online, so my specific question is if anyone has heard of this problem and can point me in the right direction (or, even better, show me a solution :)
Thanks!
I would not call it "reverse interpolation" as that does not exists (my first thought was you were talking about extrapolation!). What you are doing is still simply interpolation, just at an uneven rate.
Interpolation: finding a value between known values
Extrapolation: finding a value beyond known values
Interpolating to/from constant rates is indeed much much simpler than the generic quest of "finding a value between known values". I propose 2 solutions.
1) Interpolate to a significantly higher rate, and then just sub-sample to the nearest one (try adding dithering)
2) Solve the generic problem: for each point you need to use the neighboring N points and fit a order N-1 polynomial to them.
N=2 would be linear and would add overtones (C0 continuity)
N=3 could leave you with step changes at the halfway point between your source samples (perhaps worse overtones than N=2!)
N=4 will get you C1 continuity (slope will match as you change to the next sample), surely enough for your application.
Let me explain that last one.
For each output sample use the 2 previous and 2 following input samples. Call them S0 to S3 on a unit time scale (multiply by your sample period later), and you are interpolating from time 0 to 1. Y is your output and Y' is the slope.
Y will be calculated from this polynomial and its differential (slope)
Y(t) = At^3 + Bt^2 + Ct + D
Y'(t) = 3At^2 + 2Bt + C
The constraints (the values and slope at the endpoints on either side)
Y(0) = S1
Y'(0) = (S2-S0)/2
Y(1) = S2
Y'(1) = (S3-S1)/2
Expanding the polynomial
Y(0) = D
Y'(0) = C
Y(1) = A+B+C+D
Y'(1) = 3A+2B+C
Plugging in the Samples
D = S1
C = (S2-S0)/2
A + B = S2 - C - D
3A+2B = (S3-S1)/2 - C
The last 2 are a system of equations that are easily solvable. Subtract 2x the first from the second.
3A+2B - 2(A+B)= (S3-S1)/2 - C - 2(S2 - C - D)
A = (S3-S1)/2 + C - 2(S2 - D)
Then B is
B = S2 - A - C - D
Once you have A, B, C and D you can put in an time 't' in the polynomial to find a sample value between your known samples.
Repeat for every output sample, reuse A,B,C&D if the next output sample is still between the same 2 input samples. Calculating t each time is similar to Bresenham's line algorithm, you're just advancing by a different amount each time.
When using a bilinear filter to magnify an image (by some non-integer factor), is that process lossless? That is, is there some way to calculate the original image, as long as the original resolution, the upscaled image and the exact algorithm used are known, and there is no loss in precision when upscaling (no rounding errors)?
My guess would be that it is, but that is based on some calculations on a napkin regarding the one-dimensional case only.
Taking the 1D case as a simplification. Each output point can be expressed as a linear combination of two of the input points, i.e.:
y_n = k_n * x_m + (1-k_n) * x_{m+1}
You have a whole set of these equations, which can be expressed in vector notation as:
Y = K * X
where X is a length-M vector of input points, Y is a length-N vector of output points, and K is a sparse matrix (size NxM) containing the (known) values of k.
For the interpolation to be reversible, K must be an invertible matrix. This means that there must be at least M linearly-independent rows. This is true if and only if there is at least one output point in-between each pair of input points.