Re: [fonc] Morphic 3 defensive disclosure
Hi Juan, Yes, that is some of the best TTF non-hinted rendering I've seen. Nice work! And, yes, it does look like the bug is gone, thanks! It will be interesting to look through a simplified, stand-alone(ish) version of the code to fully grasp the detail of your approach. Again, no rush, though. Dan On Tue, Sep 23, 2014 at 6:50 PM, J. Vuletich (mail lists) juanli...@jvuletich.org wrote: Hi Dan, Quoting Dan Amelang daniel.amel...@gmail.com: Hi Juan, Thanks for the screenshots, that helps a lot! Now, it would be ideal to have a visual like this to for the comparison: http://typekit.files.wordpress.com/2013/05/jensonw-900.png. But, I know that you've got limited time to work on this, and such a thing wouldn't be very high priority. Maybe down the road. Please take a look at https://dl.dropboxusercontent.com/u/13285702/Morphic3-TimesNewRomanSample.png I used Times New Roman for the sample. It is similar but not identical to the font in the Adobe demo image. I did it by converting the text to SVG in Inkscape, then using Morphic 3 to draw the svg file. There is no hinting at all here! Just better rasterization. The shape and weight is truer and more uniform (especially at smaller sizes), most glyphs look sharper. Starting from the third line, the quality is consistently better. Also, comparing your renderer+stroke font to the recently open sourced Adobe font rasterizer would be interesting, too ( http://blog.typekit.com/2013/05/01/adobe-contributes-cff-rasterizer-to-freetype/). As far as I can tell, Adobe's rasterizer is pretty much the the state-of-the-art rasterizer for outline font rasterization. If you're making the case that outline fonts are intrinsically unable to match the quality of your stroke font, this comparison would be a convincing way to do so. I think the real contribution of Morphic 3 here is better rasterization, that doesn't need hinting to give very crisp and detailed results. Going back to the topic of Morphic 3 rendering TrueType fonts, I'm attaching a few unfiltered zooms from your M3-TTF.png (your more recent M3-TTF-5.png looks the same in these areas). Notice the saturated colors in the middle of the black text. You mentioned that you have color fringing problems with 9 point sizes, but this font is about 12pt and the problem doesn't look like color fringing (i.e., the coloring isn't light nor just on the fringes, see http://typekit.files.wordpress.com/2010/10/gdi-cleartype.png for what I understand color fringing to look like). Maybe something else is going on here? ... snip ... Dan Yes. There was a bug there. It only happened for curve segments shorter than one pixel, affecting only very small point sizes. Thanks for pointing it out! The sample I prepared today clearly shows that the bug was fixed. Cheers, Juan Vuletich ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Morphic 3 defensive disclosure
Agreed. these are impressive! I was curious about the defensive disclosure. Are you intending to patent this work or simply preventing a non-open source implementation from claiming patent infringements? I’d be curious to try and recreate some of these results :) shawn On Sep 24, 2014, at 5:24 PM, Dan Amelang daniel.amel...@gmail.com wrote: Hi Juan, Yes, that is some of the best TTF non-hinted rendering I've seen. Nice work! And, yes, it does look like the bug is gone, thanks! It will be interesting to look through a simplified, stand-alone(ish) version of the code to fully grasp the detail of your approach. Again, no rush, though. Dan On Tue, Sep 23, 2014 at 6:50 PM, J. Vuletich (mail lists) juanli...@jvuletich.org wrote: Hi Dan, Quoting Dan Amelang daniel.amel...@gmail.com: Hi Juan, Thanks for the screenshots, that helps a lot! Now, it would be ideal to have a visual like this to for the comparison: http://typekit.files.wordpress.com/2013/05/jensonw-900.png. But, I know that you've got limited time to work on this, and such a thing wouldn't be very high priority. Maybe down the road. Please take a look at https://dl.dropboxusercontent.com/u/13285702/Morphic3-TimesNewRomanSample.png I used Times New Roman for the sample. It is similar but not identical to the font in the Adobe demo image. I did it by converting the text to SVG in Inkscape, then using Morphic 3 to draw the svg file. There is no hinting at all here! Just better rasterization. The shape and weight is truer and more uniform (especially at smaller sizes), most glyphs look sharper. Starting from the third line, the quality is consistently better. Also, comparing your renderer+stroke font to the recently open sourced Adobe font rasterizer would be interesting, too (http://blog.typekit.com/2013/05/01/adobe-contributes-cff-rasterizer-to-freetype/). As far as I can tell, Adobe's rasterizer is pretty much the the state-of-the-art rasterizer for outline font rasterization. If you're making the case that outline fonts are intrinsically unable to match the quality of your stroke font, this comparison would be a convincing way to do so. I think the real contribution of Morphic 3 here is better rasterization, that doesn't need hinting to give very crisp and detailed results. Going back to the topic of Morphic 3 rendering TrueType fonts, I'm attaching a few unfiltered zooms from your M3-TTF.png (your more recent M3-TTF-5.png looks the same in these areas). Notice the saturated colors in the middle of the black text. You mentioned that you have color fringing problems with 9 point sizes, but this font is about 12pt and the problem doesn't look like color fringing (i.e., the coloring isn't light nor just on the fringes, see http://typekit.files.wordpress.com/2010/10/gdi-cleartype.png for what I understand color fringing to look like). Maybe something else is going on here? ... snip ... Dan Yes. There was a bug there. It only happened for curve segments shorter than one pixel, affecting only very small point sizes. Thanks for pointing it out! The sample I prepared today clearly shows that the bug was fixed. Cheers, Juan Vuletich ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Morphic 3 defensive disclosure
Hi Shawn, I'm not intending to patent it. But I want to avoid others to patent it and restrict my right (and yours) to use it. Feel free to use it as you please. The code is MIT license, as is Cuis Smalltalk. In any case, I'd appreciate reasonable and fair attribution of the ideas in stuff you, or anybody else, publishes. Cheers, Juan Vuletich Quoting shawnmorel shawnmo...@icloud.com: Agreed. these are impressive! I was curious about the defensive disclosure. Are you intending to patent this work or simply preventing a non-open source implementation from claiming patent infringements? I’d be curious to try and recreate some of these results :) shawn On Sep 24, 2014, at 5:24 PM, Dan Amelang daniel.amel...@gmail.com wrote: Hi Juan, Yes, that is some of the best TTF non-hinted rendering I've seen. Nice work! And, yes, it does look like the bug is gone, thanks! It will be interesting to look through a simplified, stand-alone(ish) version of the code to fully grasp the detail of your approach. Again, no rush, though. Dan On Tue, Sep 23, 2014 at 6:50 PM, J. Vuletich (mail lists) juanli...@jvuletich.org wrote: Hi Dan, Quoting Dan Amelang daniel.amel...@gmail.com: Hi Juan, Thanks for the screenshots, that helps a lot! Now, it would be ideal to have a visual like this to for the comparison: http://typekit.files.wordpress.com/2013/05/jensonw-900.png. But, I know that you've got limited time to work on this, and such a thing wouldn't be very high priority. Maybe down the road. Please take a look at https://dl.dropboxusercontent.com/u/13285702/Morphic3-TimesNewRomanSample.png I used Times New Roman for the sample. It is similar but not identical to the font in the Adobe demo image. I did it by converting the text to SVG in Inkscape, then using Morphic 3 to draw the svg file. There is no hinting at all here! Just better rasterization. The shape and weight is truer and more uniform (especially at smaller sizes), most glyphs look sharper. Starting from the third line, the quality is consistently better. Also, comparing your renderer+stroke font to the recently open sourced Adobe font rasterizer would be interesting, too (http://blog.typekit.com/2013/05/01/adobe-contributes-cff-rasterizer-to-freetype/). As far as I can tell, Adobe's rasterizer is pretty much the the state-of-the-art rasterizer for outline font rasterization. If you're making the case that outline fonts are intrinsically unable to match the quality of your stroke font, this comparison would be a convincing way to do so. I think the real contribution of Morphic 3 here is better rasterization, that doesn't need hinting to give very crisp and detailed results. Going back to the topic of Morphic 3 rendering TrueType fonts, I'm attaching a few unfiltered zooms from your M3-TTF.png (your more recent M3-TTF-5.png looks the same in these areas). Notice the saturated colors in the middle of the black text. You mentioned that you have color fringing problems with 9 point sizes, but this font is about 12pt and the problem doesn't look like color fringing (i.e., the coloring isn't light nor just on the fringes, see http://typekit.files.wordpress.com/2010/10/gdi-cleartype.png for what I understand color fringing to look like). Maybe something else is going on here? ... snip ... Dan Yes. There was a bug there. It only happened for curve segments shorter than one pixel, affecting only very small point sizes. Thanks for pointing it out! The sample I prepared today clearly shows that the bug was fixed. Cheers, Juan Vuletich ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Morphic 3 defensive disclosure
Hi Dan, Quoting Dan Amelang daniel.amel...@gmail.com: Hi Juan, Thanks for the screenshots, that helps a lot! Now, it would be ideal to have a visual like this to for the comparison: http://typekit.files.wordpress.com/2013/05/jensonw-900.png. But, I know that you've got limited time to work on this, and such a thing wouldn't be very high priority. Maybe down the road. Yes, that would be cool. Maybe I find some time to do it in the soon. Also, comparing your renderer+stroke font to the recently open sourced Adobe font rasterizer would be interesting, too (http://blog.typekit.com/2013/05/01/adobe-contributes-cff-rasterizer-to-freetype/). As far as I can tell, Adobe's rasterizer is pretty much the the state-of-the-art rasterizer for outline font rasterization. If you're making the case that outline fonts are intrinsically unable to match the quality of your stroke font, this comparison would be a convincing way to do so. Yes, the CFF hinter does a great job. The difference between the 3 samples you is only in hinting. The three of them are drawn with whole pixel coverage AA. Hinting outlines is really hard. And very specific to not only to text but to a particular font specification: Hinting TTF and CFF requires 2 different algorithms. Besides, it is slow (really slow). Because of this, once drawn, the glyphs are usually cached for subsequent use. But this means that you need to draw glyphs at integer pixel coordinates, so you can reuse the cached rasterized glyphs. All this goes against several of my objectives. I want that: - Nothing is forced on a pixel grid. Any glyph can be drawn at any float coordinates anytime, without performance penalty. This precludes the use of a cache of rasterized glyphs. - The same algorithm is used for graphics and text. I don't want complex code that specific to TTF hinting. So, for TTF, I do no hinting at all! My TTF samples look reasonably good because (these are the focus of my defensive disclosure, and the heart of my engine): - I use something better than pixel coverage: prefiltering. - I sample at the subpixel position, not at whole pixels. So, I'm not claiming that my StrokeFont looks better than Adobe's CFF sophisticated hinting. I say that my StrokeFonts look better than TTF without any hinting at all, i.e. that my engine does a better job at StrokeFonts than it can do at TTF; and better than, for example, Apple, that doesn't do hinting either. I believe that Adobe's CFF hinting, but rasterizing with prefiltering and subpixel sampling (like I do) would give the best results of all. (if we restrict to pixel grid for glyph position, and admit having comples, text specific code). Going back to the topic of Morphic 3 rendering TrueType fonts, I'm attaching a few unfiltered zooms from your M3-TTF.png (your more recent M3-TTF-5.png looks the same in these areas). Notice the saturated colors in the middle of the black text. You mentioned that you have color fringing problems with 9 point sizes, but this font is about 12pt and the problem doesn't look like color fringing (i.e., the coloring isn't light nor just on the fringes, see http://typekit.files.wordpress.com/2010/10/gdi-cleartype.png for what I understand color fringing to look like). Maybe something else is going on here? Yes. Those look like bugs, and I'll look into them. Those need to be fixed! I'm attaching a sample of color fringes from M3-TTF.png, and the somewhate better M3-TTF-5.png to show what I meant. Back to your comments...I also like the idea of having a single rasterizer for text and general graphics. At least one that can be just parametrized or extended to handle text nicely as needed. Yes, there is no question that one can improve on the visual output of the popular rasterizers (cairo, skia, antigrain, qt, etc.). The question has always been at what cost to software complexity and at what cost to performance. Agreed. And I add to complexity and performace, the desire to draw glyphs not only at integer pixel positions, as I said above. I wasn't able to mentally separate your rasterization code from the rest of the Morphic 3 code (I'm not a big Smalltalker, so maybe it's just me), so I couldn't evaluate the complexity cost. It also looked like there were several optimizations mixed in that could have thrown off my understanding. It is not just you, you don't need to be polite! The engine is for a Morphic UI, and handles the nested coordinate systems, possible clipping to the owner's shape, and the identification of the morph at any pixel (to dispatch Morphic events). Besides, it is an early stage, full of nearly repeated code and experiments. It is even full of comments in Spanish that were meant to be transient, and just for me! It is far from the mean code quality of Cuis, for example. To get faster to the relevant parts, try following this with the debugger: (Morphic3Canvas onForm: Display) into: self runningWorld; intoLocation: (MatrixTransform2x3
Re: [fonc] Morphic 3 defensive disclosure
- I use something better than pixel coverage: pre filtering. I’m actually really curious about this. Is there a version of this paper that you own copyrights to that you could point us to? http://ip.com/IPCOM/000232657 Would you be interested in creating a clean, totally not optimized (and thus slow), stand alone version of the rasterizer just for exposition purposes? Something for people like me to learn from? Again, I know you have very limited time. No rush. Yes, I could do that. The features provided would be just drawing some shapes or glyphs, not unlike the snippet above, but trimmed of all superfluous Morphic stuff and experiments. Just give me a few days and I'll prepare it, in addition to fixing the saturated color pixels bug you mentioned. I’d also add that for a newcomer, it might even help your rasterization ideas spread more. Much of the discussion here http://www.jvuletich.org/Morphic3/Morphic3-201006.html starts with a discussion about improving on morphic, priming me to think about GUI toolkits and problems that arise there. Much of the meat of the content is about the rasterization ideas, which in my mind are quite different. e.g. you could build many things on the new rasterizer and you could build a new guy toolkit on many different rasterizers :) shawn ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Morphic 3 defensive disclosure
Hi Dan, (redending without attachs) Quoting Dan Amelang daniel.amel...@gmail.com: Hi Juan, Glad that you're making progress! One question: how hard would it be to use a TrueType font (or any fill-based font) with your rasterizer? And, I would be interested in comparing the visual results of rendering 1) a TrueType font via FreeType, 2) a TrueType font via your Morphic 3 rasterizer, 3) your stroke font via the Morphic 3 rasterizer. It is some work, as the TrueType font needs to be imported. I already did this for DejaVu, printing a text sample to pdf, then converting that to svg with Inkscape, and then loading the svg in Cuis / Morphic 3 and using a CodeGeneratingCanvas to write the Smalltalk code for me. https://dl.dropboxusercontent.com/u/13285702/M3-TTF.png is a sample image using just that font. And, I would be interested in comparing the visual results of rendering 1) a TrueType font via FreeType, 2) a TrueType font via your Morphic 3 rasterizer, 3) your stroke font via the Morphic 3 rasterizer. Taking a look at M3-TTF.png, and the original https://dl.dropboxusercontent.com/u/13285702/M3.png , and comparing with FreeType samples (for example, the regular Cuis fonts), I think that (sorted by visual quality): a) For pointSize =14 1) Morphic 3 / StrokeFont with autohinting 2) Feetype / TrueType with autohinting 3) Morphic 3 / TrueType (no autohinting possible yet) Note 1: For M3/TTF I could take the autohinting algorithm from Freetype, and quality would be at least on par with it, for point sizes = 9 Note 2: For point sizes 9 (fills less than one pixel), M3/TTF produces color fringes. I think this can be enhanced with some work. I didn't spend much time on these issues, as I focused on StrokeFonts, that give best results, at least for a programming environment. Applications might need TTF, and there are possible enhancements to be done. b) Rotated text. Here the difference in quality is rather small. 1) Morphic 3 / StrokeFont (autohinting off) 2) Feetype / TrueType 3) Morphic 3 / TrueType c) Point sizes 14. Here I think the three alternatives look really good, no autohinting is needed, and there is no clear winner. (Same would go for most point sizes on a Retina or other hi dpi display, such as phones.) I know option 3) produces the best quality, I'm just interested in the visual details. Such a comparison might also be helpful to showcase and explain your work to others. It is also worth noting that the usual Cairo + Freetype (or Cairo + Pango + Freetype) combo uses different algorithms for text and graphics, as Freetype can do much better than Cairo, but can not do general vector graphics. But Morphic 3 gives the same top quality for vector graphics too, as text is done simply by calling the svg like graphics primitives. Where Morphic 3 really stands out is when comparing against Cairo for drawing vector graphics! I hope this helps. Cheers, Juan Vuletich Dan On Wed, Sep 17, 2014 at 6:25 AM, J. Vuletich (mail lists) juanli...@jvuletich.org wrote: Hi Dan, Folks, I finally published the Morphic 3 code in its current state. It is still unfinished, and in need of cleanup. I hope you are still interested in this stuff. See http://jvuletich.org/pipermail/cuis_jvuletich.org/ 2014-September/001692.html I attached there a demo image with some SVG drawings, and some text at rather small sizes, and some rotated text too. This took me a lot of time, because for maximum text quality I had to design a new font, based on pen strokes (and not fills!). I based it on the technical lettering I learned at high school. I think I'm now close to the limit of what is possible on regular LCDs when trying to optimize crispness, absence of pixellation and absence of color fringes. What I need to do now is to fill in some details, then optimization and a VM plugin. Then it could become the default graphics engine for Cuis ( www.cuis-smalltalk.org ). Cheers, Juan Vuletich Quoting Dan Amelang daniel.amel...@gmail.com: Hi Juan, I think it's great that you are sharing your rasterization approach. So far it sounds pretty interesting. FWIW, after you've released the code, I would be interested in using this approach to create a higher quality, drop-in replacement for the current Rasterize stage in the Gezira rendering pipeline. Best, Dan On Tue, Dec 3, 2013 at 6:24 PM, J. Vuletich (mail lists) juanli...@jvuletich.org wrote: Hi Folks, The first defensive disclosure about Morphic 3 has been accepted and published at http://www.defensivepublications.org/publications/prefiltering- antialiasing-for-general-vector-graphics and http://ip.com/IPCOM/000232657 .. Morphic 3 is described at http://www.jvuletich.org/Morphic3/Morphic3-201006.html This paves the way for releasing all the code, as no one will be able to patent it. Cheers, Juan Vuletich ___ fonc mailing list fonc@vpri.org
Re: [fonc] Morphic 3 defensive disclosure
Hi Juan, Thanks for the screenshots, that helps a lot! Now, it would be ideal to have a visual like this to for the comparison: http://typekit.files.wordpress.com/2013/05/jensonw-900.png. But, I know that you've got limited time to work on this, and such a thing wouldn't be very high priority. Maybe down the road. Also, comparing your renderer+stroke font to the recently open sourced Adobe font rasterizer would be interesting, too ( http://blog.typekit.com/2013/05/01/adobe-contributes-cff-rasterizer-to-freetype/). As far as I can tell, Adobe's rasterizer is pretty much the the state-of-the-art rasterizer for outline font rasterization. If you're making the case that outline fonts are intrinsically unable to match the quality of your stroke font, this comparison would be a convincing way to do so. Going back to the topic of Morphic 3 rendering TrueType fonts, I'm attaching a few unfiltered zooms from your M3-TTF.png (your more recent M3-TTF-5.png looks the same in these areas). Notice the saturated colors in the middle of the black text. You mentioned that you have color fringing problems with 9 point sizes, but this font is about 12pt and the problem doesn't look like color fringing (i.e., the coloring isn't light nor just on the fringes, see http://typekit.files.wordpress.com/2010/10/gdi-cleartype.png for what I understand color fringing to look like). Maybe something else is going on here? Back to your comments...I also like the idea of having a single rasterizer for text and general graphics. At least one that can be just parametrized or extended to handle text nicely as needed. Yes, there is no question that one can improve on the visual output of the popular rasterizers (cairo, skia, antigrain, qt, etc.). The question has always been at what cost to software complexity and at what cost to performance. I wasn't able to mentally separate your rasterization code from the rest of the Morphic 3 code (I'm not a big Smalltalker, so maybe it's just me), so I couldn't evaluate the complexity cost. It also looked like there were several optimizations mixed in that could have thrown off my understanding. Would you be interested in creating a clean, totally not optimized (and thus slow), stand alone version of the rasterizer just for exposition purposes? Something for people like me to learn from? Again, I know you have very limited time. No rush. Dan On Thu, Sep 18, 2014 at 6:38 AM, J. Vuletich (mail lists) juanli...@jvuletich.org wrote: Hi Dan, Quoting Dan Amelang daniel.amel...@gmail.com: Hi Juan, Glad that you're making progress! One question: how hard would it be to use a TrueType font (or any fill-based font) with your rasterizer? It is some work, as the TrueType font needs to be imported. I already did this for DejaVu, printing a text sample to pdf, then converting that to svg with Inkscape, and then loading the svg in Cuis / Morphic 3 and using a CodeGeneratingCanvas to write the Smalltalk code for me. The attach is a sample image using just that font. And, I would be interested in comparing the visual results of rendering 1) a TrueType font via FreeType, 2) a TrueType font via your Morphic 3 rasterizer, 3) your stroke font via the Morphic 3 rasterizer. Taking a look at the attach, and the original attach in the mail linked below, and comparing with FreeType samples (for example, the regular Cuis fonts), I think that (sorted by visual quality): a) For pointSize =14 1) Morphic 3 / StrokeFont with autohinting 2) Feetype / TrueType with autohinting 3) Morphic 3 / TrueType (no autohinting possible yet) Note 1: For M3/TTF I could take the autohinting algorithm from Freetype, and quality would be at least on par with it, for point sizes = 9 Note 2: For point sizes 9 (fills less than one pixel), M3/TTF produces color fringes. I think this can be enhanced with some work. I didn't spend much time on these issues, as I focused on StrokeFonts, that give best results, at least for a programming environment. Applications might need TTF, and there are possible enhancements to be done. b) Rotated text. Here the difference in quality is rather small. 1) Morphic 3 / StrokeFont (autohinting off) 2) Feetype / TrueType 3) Morphic 3 / TrueType c) Point sizes 14. Here I think the three alternatives look really good, no autohinting is needed, and there is no clear winner. (Same would go for most point sizes on a Retina or other hi dpi display, such as phones.) I know option 3) produces the best quality, I'm just interested in the visual details. Such a comparison might also be helpful to showcase and explain your work to others. It is also worth noting that the usual Cairo + Freetype (or Cairo + Pango + Freetype) combo uses different algorithms for text and graphics, as Freetype can do much better than Cairo, but can not do general vector graphics. But Morphic 3 gives the same top quality for vector graphics too, as text is done simply by
Re: [fonc] Morphic 3 defensive disclosure
Hi Dan, Folks, I finally published the Morphic 3 code in its current state. It is still unfinished, and in need of cleanup. I hope you are still interested in this stuff. See http://jvuletich.org/pipermail/cuis_jvuletich.org/2014-September/001692.html I attached there a demo image with some SVG drawings, and some text at rather small sizes, and some rotated text too. This took me a lot of time, because for maximum text quality I had to design a new font, based on pen strokes (and not fills!). I based it on the technical lettering I learned at high school. I think I'm now close to the limit of what is possible on regular LCDs when trying to optimize crispness, absence of pixellation and absence of color fringes. What I need to do now is to fill in some details, then optimization and a VM plugin. Then it could become the default graphics engine for Cuis ( www.cuis-smalltalk.org ). Cheers, Juan Vuletich Quoting Dan Amelang daniel.amel...@gmail.com: Hi Juan, I think it's great that you are sharing your rasterization approach. So far it sounds pretty interesting. FWIW, after you've released the code, I would be interested in using this approach to create a higher quality, drop-in replacement for the current Rasterize stage in the Gezira rendering pipeline. Best, Dan On Tue, Dec 3, 2013 at 6:24 PM, J. Vuletich (mail lists) juanli...@jvuletich.org wrote: Hi Folks, The first defensive disclosure about Morphic 3 has been accepted and published at http://www.defensivepublications.org/publications/prefiltering-antialiasing-for-general-vector-graphics and http://ip.com/IPCOM/000232657 .. Morphic 3 is described at http://www.jvuletich.org/Morphic3/Morphic3-201006.html This paves the way for releasing all the code, as no one will be able to patent it. Cheers, Juan Vuletich ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Morphic 3 defensive disclosure
Hi Juan, Glad that you're making progress! One question: how hard would it be to use a TrueType font (or any fill-based font) with your rasterizer? And, I would be interested in comparing the visual results of rendering 1) a TrueType font via FreeType, 2) a TrueType font via your Morphic 3 rasterizer, 3) your stroke font via the Morphic 3 rasterizer. I know option 3) produces the best quality, I'm just interested in the visual details. Such a comparison might also be helpful to showcase and explain your work to others. Dan On Wed, Sep 17, 2014 at 6:25 AM, J. Vuletich (mail lists) juanli...@jvuletich.org wrote: Hi Dan, Folks, I finally published the Morphic 3 code in its current state. It is still unfinished, and in need of cleanup. I hope you are still interested in this stuff. See http://jvuletich.org/pipermail/cuis_jvuletich.org/ 2014-September/001692.html I attached there a demo image with some SVG drawings, and some text at rather small sizes, and some rotated text too. This took me a lot of time, because for maximum text quality I had to design a new font, based on pen strokes (and not fills!). I based it on the technical lettering I learned at high school. I think I'm now close to the limit of what is possible on regular LCDs when trying to optimize crispness, absence of pixellation and absence of color fringes. What I need to do now is to fill in some details, then optimization and a VM plugin. Then it could become the default graphics engine for Cuis ( www.cuis-smalltalk.org ). Cheers, Juan Vuletich Quoting Dan Amelang daniel.amel...@gmail.com: Hi Juan, I think it's great that you are sharing your rasterization approach. So far it sounds pretty interesting. FWIW, after you've released the code, I would be interested in using this approach to create a higher quality, drop-in replacement for the current Rasterize stage in the Gezira rendering pipeline. Best, Dan On Tue, Dec 3, 2013 at 6:24 PM, J. Vuletich (mail lists) juanli...@jvuletich.org wrote: Hi Folks, The first defensive disclosure about Morphic 3 has been accepted and published at http://www.defensivepublications.org/publications/prefiltering- antialiasing-for-general-vector-graphics and http://ip.com/IPCOM/000232657 .. Morphic 3 is described at http://www.jvuletich.org/Morphic3/Morphic3-201006.html This paves the way for releasing all the code, as no one will be able to patent it. Cheers, Juan Vuletich ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Morphic 3 defensive disclosure
Hi Gath, Stochastic sampling (1) is a method for trading aliasing for noise. Result are neither alias free nor noise free. But it allows using Ray Tracing and related techniques, and that is great for photorealistic rendering of 3D stuff. This the kinds of problems Pixar works on. OTOH, I focus in 2D vector graphics, and not in 3D rendering. And yes, common implementations of OpenGL and libraries such as Cairo and AGG don't do prefiltering (called 'Analytical Algorithms' by Cook). I hope this helps. Cheers, Juan Vuletich (1) http://www.cs.virginia.edu/~gfx/Courses/2003/ImageSynthesis/papers/Sampling/Stochastic%20Sampling%20in%20Computer%20Graphics.pdf Quoting Gath-Gealaich gath.na.geala...@gmail.com: On Tue, 03 Dec 2013 23:24:12 -0300 J. Vuletich (mail lists) juanli...@jvuletich.org wrote: Hi Folks, The first defensive disclosure about Morphic 3 has been accepted and published at http://www.defensivepublications.org/publications/prefiltering-antialiasing-for-general-vector-graphics and http://ip.com/IPCOM/000232657 .. Morphic 3 is described at http://www.jvuletich.org/Morphic3/Morphic3-201006.html On http://www.jvuletich.org/Morphic3/Morphic3-201006.html, you claim: Anti-aliasing is usually considered a technique to avoid stairway artifacts on rendered images. This is a simplistic view on the problem. Aliasing is a consequence of sampling continuous functions (images, photos, sound, etc). Makers of digital cameras and audio software know and use the theory behind it. You can read more at http://en.wikipedia.org/wiki/Nyquist–Shannon_sampling_theorem. Researches know all this. The best text books say it. However, existing graphics software completely ignore the theory. ... This allows for mathematically proved alias free rendering. As no existing application does this ... I'm sort of puzzled by this. I've always thought that this was the whole idea behind the stochastic sampling thingy that the ILM/Pixar people patented (http://www.google.com/patents/US4897806) in the 1980's to achieve mathematically proven alias-free rendering (as you said) of arbitrarily shaded arbitrary geometry (even shaded with non-analytical functions). Of course, it trades aliasing for noise, but I believe that you can have the noise arbitrarily low (and for animations, it may not matter all that much anyway since one can expect some grain or noisiness on live footage so completely noise-free sampling may even look unnatural). They certainly didn't ignore the problem; they had been studying numerous analytical and non-analytical solutions for a better part of the 1980s and then finally striked gold with stochastic sampling and PRMan. -- Gath ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc Cheers, Juan Vuletich ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Morphic 3 defensive disclosure
On Dec 6, 2013, at 6:58 AM, J. Vuletich (mail lists) juanli...@jvuletich.org wrote: Stochastic sampling (1) is a method for trading aliasing for noise. Result are neither alias free nor noise free. But it allows using Ray Tracing and related techniques, and that is great for photorealistic rendering of 3D stuff. This the kinds of problems Pixar works on. I’m actually curious to understand the distinction here between aliasing from rays sampling the 3d scene (geometry intersection, texture UV mapping, env lighting etc) and how that’s different from sampling a continuous function to figure out pixel coverage. shawn___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Morphic 3 defensive disclosure
Hi Shawn, It is not aliasing that is different, but the algorithms for rasterization. When doing ray tracing for a 3d scne, you don't have an analytical model of the function to be sampled. Quoting Shawn Morel shawnmo...@icloud.com: On Dec 6, 2013, at 6:58 AM, J. Vuletich (mail lists) juanli...@jvuletich.org wrote: Stochastic sampling (1) is a method for trading aliasing for noise. Result are neither alias free nor noise free. But it allows using Ray Tracing and related techniques, and that is great for photorealistic rendering of 3D stuff. This the kinds of problems Pixar works on. I?m actually curious to understand the distinction here between aliasing from rays sampling the 3d scene (geometry intersection, texture UV mapping, env lighting etc) and how that?s different from sampling a continuous function to figure out pixel coverage. shawn Cheers, Juan Vuletich___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Morphic 3 defensive disclosure
On Tue, 03 Dec 2013 23:24:12 -0300 J. Vuletich (mail lists) juanli...@jvuletich.org wrote: Hi Folks, The first defensive disclosure about Morphic 3 has been accepted and published at http://www.defensivepublications.org/publications/prefiltering-antialiasing-for-general-vector-graphics and http://ip.com/IPCOM/000232657 .. Morphic 3 is described at http://www.jvuletich.org/Morphic3/Morphic3-201006.html On http://www.jvuletich.org/Morphic3/Morphic3-201006.html, you claim: Anti-aliasing is usually considered a technique to avoid stairway artifacts on rendered images. This is a simplistic view on the problem. Aliasing is a consequence of sampling continuous functions (images, photos, sound, etc). Makers of digital cameras and audio software know and use the theory behind it. You can read more at http://en.wikipedia.org/wiki/Nyquist–Shannon_sampling_theorem. Researches know all this. The best text books say it. However, existing graphics software completely ignore the theory. ... This allows for mathematically proved alias free rendering. As no existing application does this ... I'm sort of puzzled by this. I've always thought that this was the whole idea behind the stochastic sampling thingy that the ILM/Pixar people patented (http://www.google.com/patents/US4897806) in the 1980's to achieve mathematically proven alias-free rendering (as you said) of arbitrarily shaded arbitrary geometry (even shaded with non-analytical functions). Of course, it trades aliasing for noise, but I believe that you can have the noise arbitrarily low (and for animations, it may not matter all that much anyway since one can expect some grain or noisiness on live footage so completely noise-free sampling may even look unnatural). They certainly didn't ignore the problem; they had been studying numerous analytical and non-analytical solutions for a better part of the 1980s and then finally striked gold with stochastic sampling and PRMan. -- Gath ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Morphic 3 defensive disclosure
Hi Juan, I think it's great that you are sharing your rasterization approach. So far it sounds pretty interesting. FWIW, after you've released the code, I would be interested in using this approach to create a higher quality, drop-in replacement for the current Rasterize stage in the Gezira rendering pipeline. Best, Dan On Tue, Dec 3, 2013 at 6:24 PM, J. Vuletich (mail lists) juanli...@jvuletich.org wrote: Hi Folks, The first defensive disclosure about Morphic 3 has been accepted and published at http://www.defensivepublications.org/publications/prefiltering-antialiasing-for-general-vector-graphics and http://ip.com/IPCOM/000232657 .. Morphic 3 is described at http://www.jvuletich.org/Morphic3/Morphic3-201006.html This paves the way for releasing all the code, as no one will be able to patent it. Cheers, Juan Vuletich ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Morphic 3 defensive disclosure
On 2013-12-03 11:24PM, J. Vuletich (mail lists) wrote: Hi Folks, The first defensive disclosure about Morphic 3 has been accepted and published at http://www.defensivepublications.org/publications/prefiltering-antialiasing-for-general-vector-graphics and http://ip.com/IPCOM/000232657 .. In figure 3, you need to use 2r or r/2 in some places; currently the diagram declares that r = 2r. --Josh ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Morphic 3 defensive disclosure
Hi Dan, I'd be delighted to help you do that! Cheers, Juan Vuletich Quoting Dan Amelang daniel.amel...@gmail.com: Hi Juan, I think it's great that you are sharing your rasterization approach. So far it sounds pretty interesting. FWIW, after you've released the code, I would be interested in using this approach to create a higher quality, drop-in replacement for the current Rasterize stage in the Gezira rendering pipeline. Best, Dan On Tue, Dec 3, 2013 at 6:24 PM, J. Vuletich (mail lists) juanli...@jvuletich.org wrote: Hi Folks, The first defensive disclosure about Morphic 3 has been accepted and published at http://www.defensivepublications.org/publications/prefiltering-antialiasing-for-general-vector-graphics and http://ip.com/IPCOM/000232657 .. Morphic 3 is described at http://www.jvuletich.org/Morphic3/Morphic3-201006.html This paves the way for releasing all the code, as no one will be able to patent it. Cheers, Juan Vuletich ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc Cheers, Juan Vuletich ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
Re: [fonc] Morphic 3 defensive disclosure
Hi Josh, I've checked it again just in case. The diagram says that (w-r) w (w+r) (w-r+r+r) = (w+r) I think your comment is not correct. Please take another look at the figure. Cheers, Juan Vuletich Quoting Josh Grams j...@qualdan.com: On 2013-12-03 11:24PM, J. Vuletich (mail lists) wrote: Hi Folks, The first defensive disclosure about Morphic 3 has been accepted and published at http://www.defensivepublications.org/publications/prefiltering-antialiasing-for-general-vector-graphics and http://ip.com/IPCOM/000232657 .. In figure 3, you need to use 2r or r/2 in some places; currently the diagram declares that r = 2r. --Josh ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc Cheers, Juan Vuletich ___ fonc mailing list fonc@vpri.org http://vpri.org/mailman/listinfo/fonc
