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

[suzuki toshiya]

Dear Anuj,

Anuj Verma wrote:
> 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.

Oh, I see the value to be stored is in a range [-1.0, 1.0].
I want to hear the comments from other developers :-),
whether the initial implementation should be FT_F2Dot14 (16bit)
or float (32bit, at least).

>> 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<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fi.imgur.com%2FruWAhT3.png&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C85cf45a1312845adc8f308d7f6f6976a%7Cc40454ddb2634926868d8e12640d3750%7C1%7C1%7C637249411274580651&sdata=RrQmOFVtQxKnZ1EqlM22%2FKmXaREcx9LZStidy0Tcg%2BE%3D&reserved=0>).
> 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.

I see.

> 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?

If the Distance Fields should be stored as an image (PNG, or
something like that), I want to withdraw my shallow idea. XML
and JSON are not the best options to store the image (using
dataURL and base64 bitstream? what a stupid idea!), please
ignore that.

There is a possibility that JPEG makes better compression
ratio. But I think using PNG is better choice for FreeType2,
because recent ready-made binaries of FreeType2 on many
GNU/Linux platforms (and on maOS and Windows?) have a
dependency to libPNG already (to support bitmap emoji fonts).
Adding new dependency to libJPEG is not the best.

Regards,
mpsuzuki


Anuj Verma wrote:
> 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<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fi.imgur.com%2FruWAhT3.png&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C85cf45a1312845adc8f308d7f6f6976a%7Cc40454ddb2634926868d8e12640d3750%7C1%7C1%7C637249411274580651&sdata=RrQmOFVtQxKnZ1EqlM22%2FKmXaREcx9LZStidy0Tcg%2BE%3D&reserved=0>).
> 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<mailto: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><mailto: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><mailto: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%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-basic_types.html&amp;data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7Ce744d4df60514a93796908d7f6b97d4b%7Cc40454ddb2634926868d8e12640d3750%7C1%7C0%7C637249148842533871&amp;sdata=%2FVbt%2BfNz6x24eJNK9ag1PDhZXz49rS4b64fcmMJ2G9A%3D&amp;reserved=0<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-basic_types.html&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C85cf45a1312845adc8f308d7f6f6976a%7Cc40454ddb2634926868d8e12640d3750%7C1%7C1%7C637249411274580651&sdata=07QmgnoPBg1WWncTqqpfEYh9wc4ZsWqhF8BRImE09sk%3D&reserved=0><https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-basic_types.html&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C9a456680ca6040e37eeb08d7f6dfe807%7Cc40454ddb2634926868d8e12640d3750%7C1%7C1%7C637249313838205364&s
data=QZPY8mNjaJMiznsZrP%2F%2Fx%2FspNjSR7NVrA5Mro4kslrA%3D&reserved=0<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-basic_types.html&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C85cf45a1312845adc8f308d7f6f6976a%7Cc40454ddb2634926868d8e12640d3750%7C1%7C1%7C637249411274590640&sdata=WT034BhLYg0cZID5xqwZJSTiMh7a%2FfqOt84KNhIxloo%3D&reserved=0>>
>>> The computations are described here:
>>> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-computations.html&amp;data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7Ce744d4df60514a93796908d7f6b97d4b%7Cc40454ddb2634926868d8e12640d3750%7C1%7C0%7C637249148842533871&amp;sdata=T%2BQR9KKVWo%2BEI4Lqr5vFkgguWHV8xm8BB3USWcaQ8iY%3D&amp;reserved=0<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-computations.html&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C85cf45a1312845adc8f308d7f6f6976a%7Cc40454ddb2634926868d8e12640d3750%7C1%7C1%7C637249411274600639&sdata=AzFDuf95tA%2BJUUEL8eob9cZCwIkt6aU8kpqu4KiYX%2BY%3D&reserved=0><https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-computations.html&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C9a456680ca6040e37eeb08d7f6dfe807%7Cc40454ddb2634926868d8e12640d3750%7C1%7C1%7C6372493138382
15316&sdata=RB7tz2dCaDs2XpjYZP6tu%2Bt7j%2Fqqn%2B1d7yDYz6dRnb4%3D&reserved=0<https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freetype.org%2Ffreetype2%2Fdocs%2Freference%2Fft2-computations.html&data=02%7C01%7Cmpsuzuki%40hiroshima-u.ac.jp%7C85cf45a1312845adc8f308d7f6f6976a%7Cc40454ddb2634926868d8e12640d3750%7C1%7C1%7C637249411274600639&sdata=AzFDuf95tA%2BJUUEL8eob9cZCwIkt6aU8kpqu4KiYX%2BY%3D&reserved=0>>
>>> 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.
>>
>