But I'm open to any ideas you may have as to how we could avoid using
floats, yet not run into the overflow situations so easily. We could
probably use division somewhere but I don't think that's actually any
better performance-wise.
It is, when implemented via bit-shifts (very cheap). I know w
Dmitry Timoshkov wrote:
"Vitaly Budovski" <[EMAIL PROTECTED]> wrote:
Both floats and integers have their share of problems. Since the square
root operation has been removed, we are dealing with much larger
numbers, potentially larger than can fit into unsigned int without
looping back around. T
"Vitaly Budovski" <[EMAIL PROTECTED]> wrote:
Both floats and integers have their share of problems. Since the square
root operation has been removed, we are dealing with much larger
numbers, potentially larger than can fit into unsigned int without
looping back around. This is why I think keepin
Jesse Allen wrote:
On 5/7/07, Duane Clark <[EMAIL PROTECTED]> wrote:
Dmitry Timoshkov wrote:
> "Vitaly Budovski" <[EMAIL PROTECTED]> wrote:
>
>>> Now that you got rid of sqrt calls usage of float numbers internally
>>> doesn't look justified (to me) anymore.
>>>
>> Only because in this instance
On 5/7/07, Duane Clark <[EMAIL PROTECTED]> wrote:
Dmitry Timoshkov wrote:
> "Vitaly Budovski" <[EMAIL PROTECTED]> wrote:
>
>>> Now that you got rid of sqrt calls usage of float numbers internally
>>> doesn't look justified (to me) anymore.
>>>
>> Only because in this instance it is used with inte
Dmitry Timoshkov wrote:
"Vitaly Budovski" <[EMAIL PROTECTED]> wrote:
Now that you got rid of sqrt calls usage of float numbers internally
doesn't look justified (to me) anymore.
Only because in this instance it is used with integer data. It doesn't
need to be limited to just integer values. B
"Vitaly Budovski" <[EMAIL PROTECTED]> wrote:
As I explained previously, this algorithm makes no assumptions about the
data that is being queried. Just because in this case (patch 3) we are
working with RGB colour data doesn't mean it is limited to only that. It
will work with *any* values, as
Dmitry Timoshkov wrote:
"Vitaly Budovski" <[EMAIL PROTECTED]> wrote:
Now that you got rid of sqrt calls usage of float numbers internally
doesn't look justified (to me) anymore.
Only because in this instance it is used with integer data. It
doesn't need to be limited to just integer values.
"Vitaly Budovski" <[EMAIL PROTECTED]> wrote:
Now that you got rid of sqrt calls usage of float numbers internally
doesn't look justified (to me) anymore.
Only because in this instance it is used with integer data. It doesn't
need to be limited to just integer values. Besides, what would be g
"Vitaly Budovski" <[EMAIL PROTECTED]> wrote:
Make use of the Triangle Inequality Nearest Neighbour algorithm to find the
nearest colour more efficiently than a simple linear search. The improvements
are most noticeable with a palette of 256 colours. Testing shows approximately
3-4x performance i
Vitaly Budovski wrote:
> Vitaliy Margolen wrote:
>> Vitaly Budovski wrote:
>>
>>> Vitaliy Margolen wrote:
>>> Thanks for the tip. Unfortunately in this instance it will not
>>> work as I
>>> do in fact query more than a < b. See the nearest function in patch 2.
>>>
>> And what is so spec
Vitaliy Margolen wrote:
Vitaly Budovski wrote:
Vitaliy Margolen wrote:
Thanks for the tip. Unfortunately in this instance it will not work as I
do in fact query more than a < b. See the nearest function in patch 2.
And what is so special about subtracting one from the other?
Vitaly Budovski wrote:
> Vitaliy Margolen wrote:
>> Vitaly Budovski wrote:
>>
>>> Make use of the Triangle Inequality Nearest Neighbour algorithm to
>>> find the
>>> nearest colour more efficiently than a simple linear search. The
>>> improvements
>>> are most noticeable with a palette of 256 col
Vitaliy Margolen wrote:
Vitaly Budovski wrote:
Make use of the Triangle Inequality Nearest Neighbour algorithm to find the
nearest colour more efficiently than a simple linear search. The improvements
are most noticeable with a palette of 256 colours. Testing shows approximately
3-4x performa
Vitaly Budovski wrote:
> Make use of the Triangle Inequality Nearest Neighbour algorithm to find the
> nearest colour more efficiently than a simple linear search. The improvements
> are most noticeable with a palette of 256 colours. Testing shows approximately
> 3-4x performance increase for 256 c
15 matches
Mail list logo
