interpolate two angles
Blitz3D Forums/Blitz3D Programming/interpolate two angles
| ||
| How can I interpolate two angles, is there an easy function? eg: angle 1 may be 320 degrees angle 2 may be 20 degrees of course the formula middle=(320+20)/2 is wrong, because the result would be 170, but it should be 350 ... while I write this, I already got an idea, something like function findApproxAngle(a1#,a2#) ; find min and max min= a1 if a2<min then min=a2 max=a2 if a1>max then max=a1 res#=0 dist#=max-min if dist<=180 then res=(max+min)/2 else res=(max+(((360-max)+min)/2.0)) mod 360.0 endif return res# end function got to test this right now... :) EDIT: ehrm, Now I got a new problem: my "angles" use values from 0.0 to 1.0 and I have 4 of them that I want to use to create a middle value (well basicly its a hue value, not an angle, but it uses like an angle a closed circle) So how could I do this? I thnik interpolating them one by one would not return a correct value ? And it would also be pretty slow. Any ideas? |
| ||
| . |
| ||
| hmm I think this won't work, let's assume: mid#(20,320) is diff=(320-20)/2=150 return 20+150 where the middle between the angles 20° and 320° would be 350° (imagine the circle), and not 170°. |
| ||
| . |
| ||
| If you convert your angles to the range -180 to +180, your orginal averageing formula should work. e.g. converting your 'middle = (320 + 20)/2 = 350' to 'middle = (-40 + 20)/2 = -20'. Not sure if this is what you want though because, given 2 angles, there are 2 middle angles between them: one between the accute angle; one between the, er, other (brain's gone dead - forgotten the name) angle. jfk: Is this to do with the HSL/RGB conversion functions you posted about a few days back? When I read it, you said you'd already found a solution so I didn't bother posting my HSL/RGB conversion functions. I can still post them if it helps, though. I've just been getting my hands dirty with this stuff recently while writing a 'color picker' for something I'm working on. Lot's of head scratching. :P |
| ||
| Yes, it's got to do with that. I am trying to write a miniDV 4:2:0 Chroma resampler, this video format stores lumin info for every pixel, but chroma info only for every fourth pixel, 3 of four pixels are interpolated (well, their hue and saturation) and my plan was to resample them and interpolate them in a more intelligent way, so chroma-keying with miniDV Movies wont be such a nightmare any longer. So I had to find the middle value of 4 Hue "angles". (As a first step I need to find the 2*2 fields true color by simulating the orinigal interpolation and comparing my result to the original frame). BTW, I DO need to work with 360 degrees, contrairy to what I sad before, but basicly this doesn't matter. Now I used to mix hue0 and hue2 parallely to hue1 and hue3, and then mix these 2 results. Please can you add your version of RGB to HSL to my Archive entry? Probably something's wrong with my version since I used to convert it from a javascript example, and I had to swap several variables to make it work - so I am still kind of uncertain if everything is right: http://www.blitzbasic.com/codearcs/codearcs.php?code=1380 |
| ||
| OK, I've added my versions to your archive entry. You've lost me a bit with what you're trying to achieve, though - I have no idea what a 'miniDV 4:2:0 Chroma resampler' is. :) |
| ||
| given 2 angles, there are 2 middle angles between them: one between the accute angle; one between the, er, other (brain's gone dead - forgotten the name) angle. OBTUSE |
| ||
| In case you wonder: for purposes of compression the MiniDV Format, used by common video cameras, is not storing color information for every pixel, but only for every fourth pixel. There are two system: PAL uses 4:2:0 and NTSC uses 4:1:1. Professional equipment is using a 4:4:4 Format, so every pixel has the complete information, luminance, hue and saturation. In the 4:2:0 format the (3 of 4) pixels without color information will use interpolated colors, using their neighbour colors. For ordinary movies this looks ok, but when you want to use chroma-keying (greenscreen background that will be replaced by an other movie), the lack of accurate color information for 75% of the pixels will result in messy, blocky outlines of the masked areas (aka Matte Line). An intelligent interpolation would now try to detect contours by changes in luminance and decide if the color should be taken from one side (in case of a detected contour), instead of the ordinary interpolation that would be used when no contour is detected. |
| ||
| I think there are only three ways to interpolate between two angles. None of them is perfect: 1) Always interpolate the acute (or obtuse) angle 2) Choose clockwise or counter-clockwise for your interpolation 3) Don't wrap around your angle values Method 1 will work fine, as long as you always want to interpolate the smaller (or larger) angle difference. You run into a problem if the difference between the angles is exactly 180 degrees--in which case you have to flip a coin. Method 2 is fool-proof, as long as you have a way of deciding whether an interpolation needs to go clockwise or counter-clockwise... which may end up taking you back to option 1. Method 3 is an idea where you store angles in your own variables, allowing them to stretch as far as need be, positive or negative. So, interpolations will always go in the right direction, and could even include whole rotations before reaching the final destination... but then you might not want that. --and actually, I don't think this applies to your color-wheel problem. I think the best solution for you is to use Method 1. In the rare case of an angular difference of exactly 180 degrees, take a survey of the surrounding pixels to see which way they're turning. If you still end up with a 50-50 split, then flip a coin. |
| ||
| Bulletproof: |
| ||
| thanks! |
   |