Re: [Freetype-devel] Re: GSOC - Distance Fields
Hi Anuj, Please let me finish my thoughts below... >> Each curved segment has a large number of neighboring grid points. >> each of which has a unique nearest projection on the curve. The curve >> is naturally sampled by these projection points a very large number of >> times and quite uniformly. Therefore, why not divide the curve into a >> large number of segments to begin with and then just find whatever >> point is close to each grid? It could be a lot faster to find the >> distance this way. So each curve is sampled a large number of times and the distances are recorded at the grid points. This distance information is about those projection points, not the entire curve. Indeed, should we simply connect those projection points with straight segments, we would get exactly the same distance field. Ultimately, distance fields produce smooth borders because they contain information on how to thread a line between the grid points. It will be very close to the original Bezier curve, but not exactly the same. It will also be close enough to the jagged line though the projection points. It is at this point I am asking why not just split the curve using De Casteljau's algorithm recursively a large number of times and calculate the distance field for a slightly jagged line to begin with. The distance field will do the magic regardless and thread the boundary smoothly through the grid... On Wed, Jun 17, 2020 at 1:08 AM Anuj Verma wrote: > I guess this is similar to the Euclidean distance transform algorithm. > http://webstaff.itn.liu.se/~stegu/JFA/Danielsson.pdf No, I do not think this is it. > As I said before I will not leave out this option, I will try to implement > this > and then we can compare the performance. [skip] > I don't find anything offending in your suggestions. ;)
Re: woff2tags.h copyright date
> I've been running copyright checks for Debian, and came across > src/sfnt/woff2tags.h. > > The copyright statement lists 1996-2020. > > Can I just check why this 1996 is the starting date, instead of > 2019, when the file was created? Certainly a copy-and-paste error, now fixed in git. Thanks for the report. Werner
woff2tags.h copyright date
I've been running copyright checks for Debian, and came across src/sfnt/woff2tags.h. The copyright statement lists 1996-2020. Can I just check why this 1996 is the starting date, instead of 2019, when the file was created? Thanks, Hugh
Re: [Freetype-devel] Re: GSOC - Distance Fields
>> Please elaborate. It's not clear to me what you are referring to, >> and what the problem is about. > > If you checkout this (https://i.imgur.com/hw4vrZL.png) which is an > ascii character `0' at pixel size 31, you can see that fixed point > deviates from the actual path slightly, which does not happen in > case of float. [...] OK, thanks. >> And if there is still some time left for GSoC I suggest that you >> explore how to implement overlapping removal in FreeType, based on >> the Skia code as Behdad suggested. > > I would certainly love to do that even after GSoC. Excellent :-) Werner
Re: Logging Library-GSOC
Hi Werner, > *I think you did a great job with your exploration.* Thanks... > *Do you think that** you already can suggest a library that fits best?* I think I need some time to analyze the already explored logging libraries (mainly dlg and log4c) w.r.t to FreeType, and how to leverage these within FreeType... I will update you on this by this weekend... Thanks, Priyesh On Wed, Jun 17, 2020 at 12:54 PM Werner LEMBERG wrote: > > > After going through log4c, I don't think I have any more options to > > look onto... If you guys know any more logging libraries, please > > let me know... > > I think you did a great job with your exploration. Do you think that > you already can suggest a library that fits best? > > > Werner >
Re: [Freetype-devel] Re: GSOC - Distance Fields
> *Please elaborate. It's not clear to me what you are referring to, and* > *what the problem is about.* If you checkout this (https://i.imgur.com/hw4vrZL.png) which is an ascii character `0' at pixel size 31, you can see that fixed point deviates from the actual path slightly, which does not happen in case of float. Moreover in some glyph (eg: https://i.imgur.com/aLmMPld.png) you can see that there are jagged edges. This happens because of underflow, if you check the `solve_cubic_equation' function ( https://github.com/preversewharf45/freetype2-sdf/blob/dcedba69423fc169a9ca95b6391902e1cf27e0b6/src/sdfgen.c#L490 ) there is a term `q3' which is cube of term `q'. So, in cases where is `q' is pretty small `q3' becomes zero. And later in the algorithm we have to take the `cube_root' of the term (q3 + r2) to find the final roots. Now because of underflow the impact of `q' on the final output is zero. That is why the roots davaiate and we get a wrong value. In some cases the deviation is quite high. I can perhaps increase the precision in case `q' is pretty small, or simply use Newton-Raphson similar to the cubic curve case. > *And if there is still some time left for GSoC I suggest that you* > *explore how to implement overlapping removal in FreeType, based on the* > *Skia code as Behdad suggested.* I would certainly love to do that even after GSoC. Thanks for your explanation of the motive behind using fixed-point and the summarization. Most of the things are clear to me now, I will start writing the code as soon as I figure out how to add a new module. Anuj
Re: Logging Library-GSOC
> After going through log4c, I don't think I have any more options to > look onto... If you guys know any more logging libraries, please > let me know... I think you did a great job with your exploration. Do you think that you already can suggest a library that fits best? Werner
Re: [Freetype-devel] Re: GSOC - Distance Fields
>> - I highly suggest you stick to float internally [...] > > I still think `float' is a better option for generating SDF, > especially in lower resolution glyphs where fixed-point produces > kind of straight lines instead of smooth curves (which is not > noticable if you look at it briefly). Please elaborate. It's not clear to me what you are referring to, and what the problem is about. > Also, why doesn't FreeType use floats? Is it just because of > platform which doesn't have floating point type? Yes. The original intention of FreeType was to provide support for embedded devices, which usually are systems that have CPUs with very limited capabilities and a tiny amount of memory. This goal hasn't changed. However, looking at Behdad's SIMD code in HarfBuzz it is clear that you have to implement this at a very low level, which is basically assembler, to get the most profit. To summarize: I want a good solution that fits into FreeType's general philosophy first, this is, using fixed-point calculations only. After that, a special solution that encapsulates the critical hotspots with specific code for specific CPUs (in particular the SSE instruction set for x86 processors or its ARM equivalent) to accellerate them as much as possible would be great. And if there is still some time left for GSoC I suggest that you explore how to implement overlapping removal in FreeType, based on the Skia code as Behdad suggested. Werner
Re: [Freetype-devel] Re: GSOC - Distance Fields
>> IMHO, in FreeType, SIMD support is something to be done in >> addition, not as a replacement. Since Anuj makes quick progress I >> suggest that he first concentrates on the fixed-float route. If >> there is some time left we should check how SIMD can be >> implemented. > > Just to clarify, ` fixed-float' is the same as `fixed-point' > integer? Yes, sorry for the confusion. Werner
