Re: [Freetype-devel] Re: GSOC - Distance Fields

[Anuj Verma]

Hello Suzuki,

> There are already FT_F2Dot14 (16bit), and FT_F26Dot6 (32bit) and FT_Fixed (16Dot16, 32bit).

I think using FT_F2Dot14 will be a good option because the signed distance field will have a range [-1.0, 1.0].

But for now I'll stick with *float* as you suggested.

> BTW, the most biggest trade-off in your mind is the size
> of extra table (in TrueType font file) to store Distance
> Fields info? Or, the speed to calculate the Distance Fields
> info?

Usually distance fields are stored as an image (e.g. https://i.imgur.com/ruWAhT3.png).

And since each pixel in the distance field is the distance to the nearest edge/outline there

can be more than 255 values. So, in this case the trade-off can be the accuracy of the distance.

But, on the other hand, I think 255 values might be enough because they are interpolated if a

point lies between two.

> *This is just my idea without deep thinking*, XML or JSON
> (or, compressed version of them) would be considerable option
> to store the data, during the development of the initial
> draft, because it is easy for them to change the data
> format, insert or remove some extra data. Also it would be
> easy for external programs to extract or manipulate.

This is interesting, I haven't thought about storing them as XML or JSON.

This option can be good if the parsing time is less than the generation time,

otherwise the external application can directly generate the distance field.

We can also store them in some format which support floating point (e.g. hdr)

But, for now I think the storing part can be postponed until we have compared the

accuracy. If there isn't a much difference in the accuracy of floats vs integers, then

we can simply use 8 bits per pixel and store them as something like PNG.

What do you think about this?

Thanks,

Anuj

On Wed, May 13, 2020 at 9:03 AM suzuki toshiya <address@hidden> wrote:

Dear Anuj,

I think you can use *float* directly in the initial draft.

When we merge the implementation using the float type into
the official public release, we should discuss the design.

There are already FT_F2Dot14 (16bit), and FT_F26Dot6 (32bit)
and FT_Fixed (16Dot16, 32bit). But yet we don't know which
is the most appropriate for your Distance Fields project,
or we need another type, thus starting with direct usage
of float would be safer to keep the all possibilities.

BTW, the most biggest trade-off in your mind is the size
of extra table (in TrueType font file) to store Distance
Fields info? Or, the speed to calculate the Distance Fields
info?

*This is just my idea without deep thinking*, XML or JSON
(or, compressed version of them) would be considerable option
to store the data, during the development of the initial
draft, because it is easy for them to change the data
format, insert or remove some extra data. Also it would be
easy for external programs to extract or manipulate.

Regards,
mpsuzuki

Anuj Verma wrote:
> Thank you all for the comments.
>
> I too agree with Werner.
> I think comparing both the types seems to be a good option, So, I'm gonna do as Suzuki suggested
> and use floats for my initial draft and later without floats.
> And I'm not gonna focus on the saving part because the user can always do a conversion.
>
> Also, can I directly use *float* or use FT_Fixed?
>
> Thanks,
>
> Anuj
>
>
> On Wed, May 13, 2020 at 5:47 AM suzuki toshiya <address@hidden<mailto:address@hidden>> wrote:
> Dear Anuj,
>
> I agree with Werner's comment.
>
> It might be uncomfortable for you to leave an untested question, something
> like "if I use a floating point calculation, the result could be better?".
>
> Please use a floating point in your initial draft (if you want),
> and let's discuss about the trade-off with the implementation
> with no floating point, in later.
>
> Regards,
> mpsuzuki
>
> On 2020/05/13 6:14, Alexei Podtelezhnikov wrote:
>> I'll just add references below.
>>
>> On Tue, May 12, 2020 at 4:15 PM Werner LEMBERG <address@hidden<mailto:address@hidden>> wrote:
>>>> I can't decide which format to use for storing the SDF(signed
>>>> distance fields).  I think using floating-point values (fixed-point
>>>> in this case) for generation will be more accurate than using
>>>> integer, but then saving the SDF to a file will require a
>>>> conversion.
>> The basic types are described here:
>> https://jpn01.safelinks.protection.outlook.com/?url=""><https://jpn01.safelinks.protection.outlook.com/?url="">>
>> The computations are described here:
>> https://jpn01.safelinks.protection.outlook.com/?url=""><https://jpn01.safelinks.protection.outlook.com/?url="">>
>> Saving files is not of FreeType's business. We just return data.
>>
>>> The basic question is whether the accuracy is really needed.
>>> Currently, FreeType doesn't use floating-point arithmetics.
>>> Personally, I would favour a solution without floats, but maybe there
>>> are good reasons for using them.
>>
>
>