Re: SDF format

[Alexei Podtelezhnikov]

> > FT_PIXEL_MODE_GRAY16 is endian-sensitive and the description implies
> > that we go by short int divided by 1024 in whatever endianness. Do we
> > need to say that?
>
> I can't quite understand how the format is endian-sensitive ? If it
> necessary to add this to the description please do so.

Which byte in GRAY16 comes first, low or high? This is important for
the client to know.
That is actually why I started researching if GRAY8 is enough to avoid
the endianness issues. I would consider using GRAY8 from 0 at -spread
to 255 at +spread, even for adjustable spread.

Alexei

On Sun, Dec 27, 2020 at 2:40 PM Anuj Verma <anujv@iitbhilai.ac.in> wrote:
>
> Hello Alexei,
>
> > [...] I went searching for *practical* examples on the internet and
> > found very few.
>
> There are quite a few examples on youtube, and most of them use 8-bit
> buffers to represent SDF.
>
> > This blog post
> > https://blog.mapbox.com/drawing-text-with-signed-distance-fields-in-mapbox-gl-b0933af6f817
> > and some others refer to OpenGL textures as the next step, Their
> > format is unclear to me but it seems that we should align.
>
> I don't think we have to align the format with OpenGL. We can convert
> the SDF data to any format in OpenGL, so I don't think we need to align.
> In the blog you mentioned the OpenGL texture format is probably GRAY8.
>
> > The blog post that I mentioned is okay with GRAY8 unevenly split at 192,
> > which brings the question of units too. The units or scale of SDF do not
> > seem to be important.
>
> For most cases negative values are simply ignored, therefore uneven splitting
> is okay. But, that might not be the case in every scenario. The units are not
> important, as long we can create acceptable interpolation to render text.
>
> > Finally, I am not sure if you realize that FreeType gray coverage
> > [...] I wonder if we really need 16 bits for acceptable
> > interpolation. Probably not.
>
> I do know about the FreeType's antialiased rendering, the 'bsdf' renderer
> takes advantage of the coverage values to generate SDF.
>
> As for the number of bits, even behdad told me that 8 bits is enough to
> produce respectable rendering: 
> https://lists.nongnu.org/archive/html/freetype-devel/2020-06/msg00118.html
> And even some other SDF generators use 8 bits to represent the final SDF
> output data :
>  - https://github.com/libgdx/libgdx/wiki/Distance-field-fonts
>  - https://github.com/rougier/freetype-gl/blob/master/distance-field.c
> I did test 8 bit SDF today, and the final rendering output is
> similar to 16 bit. For my testing I used 3.5 fixed point representation,
> similar to what is used in skia. 
> (https://lists.nongnu.org/archive/html/freetype-devel/2020-06/msg00009.html)
>
> Finally, we can definitely use 8 bit output to represent SDF and render
> acceptable text using it. Now, we can either eliminate the current 16 bit
> output, or, we can keep both 16 and 8 bit output. What do you think will be
> the better option ? I think we should keep a single output (probably 8 bit)
> and later add an option to directly output floating point data (if we decide
> to add floating point calculations to FreeType)
>
> Anuj



-- 
Alexei A. Podtelezhnikov, PhD