Hi Folks,
I'm new to this list and community, and I hope this is interesting for you.
I am developing a novel way to do anti aliased 2d graphics that breaks away from pixel coverage and super sampling, while being simpler and providing higher quality. Please take a look at http:www.jvuletich.org , especially at the samples.
Comments welcome.
Cheers, Juan Vuletich
Juan Vuletich wrote:
I am developing a novel way to do anti aliased 2d graphics that breaks away from pixel coverage and super sampling, while being simpler and providing higher quality. Please take a look at http:www.jvuletich.org , especially at the samples.
This does look interesting, but I would be interested in the actual method used (the mathematics). I've been thinking about solving the seams issue myself as well and would definitely be interested in seeing something that solves it go into Inkscape.
Also, have you taken gamma into account? Below is a link to a site which explains why this important in (re)sampling a picture: http://www.4p8.com/eric.brasseur/gamma.html Inkscape doesn't take it into account btw. (although I guess it could do so for anti-aliasing and resampling bitmaps).
BTW, why is there also a color difference between your images and Inkscape.
On Wed, 02 Jun 2010 11:36:44 -0300 Juan Vuletich <juan@...2357...> wrote:
Hi Folks,
I'm new to this list and community, and I hope this is interesting for you.
I am developing a novel way to do anti aliased 2d graphics that breaks away from pixel coverage and super sampling, while being simpler and providing higher quality. Please take a look at http:www.jvuletich.org , especially at the samples.
Comments welcome.
Cheers, Juan Vuletich
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
When it comes to output quality in provided samples, your method is quite impressive (at least for me). Straight lines (black to white) look very smooth.
I didn't even notice before that you normally get those "tinted" black-white edges. I guess it has something to do with order of colors in "hardware pixels" (RGB), and your method uses some sort of subpixelrendering to compensate, right? While this is nice for on-the-fly rendering, wouldn't it make rasterized images "incompatible" with displays using other ordering of subpixels (or print)?
Jasper van de Gronde wrote:
Juan Vuletich wrote:
I am developing a novel way to do anti aliased 2d graphics that breaks away from pixel coverage and super sampling, while being simpler and providing higher quality. Please take a look at http:www.jvuletich.org , especially at the samples.
This does look interesting, but I would be interested in the actual method used (the mathematics). I've been thinking about solving the seams issue myself as well and would definitely be interested in seeing something that solves it go into Inkscape.
Well, the mathematics is the sampling theorem. As I say in my page, what is needed is to model the image as a function of (x, y) where x and y are reals (and not integers). That function needs to be filtered to honor the sampling theorem before sampling. I'm also sampling at (approximate) subpixel positions.
Also, have you taken gamma into account? Below is a link to a site which explains why this important in (re)sampling a picture: http://www.4p8.com/eric.brasseur/gamma.html Inkscape doesn't take it into account btw. (although I guess it could do so for anti-aliasing and resampling bitmaps).
I don't think gamma is that important for anti aliasing and it can be incorporated into the low pass filter anyway. I do think gamma is important for resampling bitmap images, but haven't done bitmaps yet.
BTW, why is there also a color difference between your images and Inkscape.
There should be none. Where do you see it?
Thanks, Juan Vuletich
Radek wrote:
On Wed, 02 Jun 2010 11:36:44 -0300 Juan Vuletich <juan@...2357...> wrote:
Hi Folks,
I'm new to this list and community, and I hope this is interesting for you.
I am developing a novel way to do anti aliased 2d graphics that breaks away from pixel coverage and super sampling, while being simpler and providing higher quality. Please take a look at http:www.jvuletich.org , especially at the samples.
Comments welcome.
Cheers, Juan Vuletich
Inkscape-devel mailing list Inkscape-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/inkscape-devel
When it comes to output quality in provided samples, your method is quite impressive (at least for me). Straight lines (black to white) look very smooth.
Thanks :)
I didn't even notice before that you normally get those "tinted" black-white edges.
Oh, I see them very clearly every time my mac boots on the apple logo!
I guess it has something to do with order of colors in "hardware pixels" (RGB), and your method uses some sort of subpixelrendering to compensate, right?
Right. More precisely, I sample the image at the correct places (the position of the subpixels).
While this is nice for on-the-fly rendering, wouldn't it make rasterized images "incompatible" with displays using other ordering of subpixels (or print)?
The geometry of the pixels (i.e. the sample positions) is a parameter to the rasterized. It is pretty easy to adapt it to any target or turn it off completely. However, for regular LCDs, it is best to use it as in the samples.
Cheers, Juan Vuletich
It does look very impressive. I too have a question regarding subpixel rendering. Since the comparison images on your website do use subpixel rendering, but the Inkscape versions shown side-by-side don't, it doesn't seem like it's a fair comparison.
Could you tweak your program to turn off subpixel rendering, and give us the same samples with subpixel turned off in both?
Very nice results on the adjacent polygons, by the way!
- Bryan
Juan Vuletich wrote:
Well, the mathematics is the sampling theorem. As I say in my page, what is needed is to model the image as a function of (x, y) where x and y are reals (and not integers). That function needs to be filtered to honor the sampling theorem before sampling. I'm also sampling at (approximate) subpixel positions.
I understand, but in principle that's what every rasterizer does. Well, not all do it as correctly or precisely as they could, but the principle is the same. From what I can see you seem to be doing it quite precisely, but this is definitely not trivial, at least if you also want it to be fast. Thus my question about the precise method used.
Also, you show a demo of an image where the seams are not shown. Did you render the all objects to the same buffer or are you able to composite them seamlessly (without having problems with overlaps). And in either case, how did you make this efficient.
BTW, why is there also a color difference between your images and Inkscape.
There should be none. Where do you see it?
For example the lion demo on your site. The two versions have very clearly different colors on my monitor. (Perhaps there's an issue with gamma or color profile settings...)
Bryan Hoyt | Brush Technology wrote:
It does look very impressive. I too have a question regarding subpixel rendering. Since the comparison images on your website do use subpixel rendering, but the Inkscape versions shown side-by-side don't, it doesn't seem like it's a fair comparison.
But then, fair comparison would be to turn on subpixel rendering on Inkscape. Can that be done?
Could you tweak your program to turn off subpixel rendering, and give us the same samples with subpixel turned off in both?
How can I claim mi technique is better if I disable its advantages? If I did as you say, someone could say, "hey Inkscape does just only 1 pixel wide anti aliasing. could you tweak your filter to do that, to do a fair comparison?" Then, my results would be exactly those of Inkscape, and I'd kill all the progress I did!
Very nice results on the adjacent polygons, by the way!
- Bryan
Thanks!
Cheers, Juan Vuletich
Jasper van de Gronde wrote:
Juan Vuletich wrote:
Well, the mathematics is the sampling theorem. As I say in my page, what is needed is to model the image as a function of (x, y) where x and y are reals (and not integers). That function needs to be filtered to honor the sampling theorem before sampling. I'm also sampling at (approximate) subpixel positions.
I understand, but in principle that's what every rasterizer does. Well, not all do it as correctly or precisely as they could, but the principle is the same.
I believe that existing rasterizers for 2d graphics use either pixel coverage or super sampling. Please point me to some reference if I'm wrong.
Applying a real filter to a continuous ("analog") function and then sampling is something quite different.
From what I can see you seem to be doing it quite precisely, but this is definitely not trivial, at least if you also want it to be fast. Thus my question about the precise method used.
No, it is not trivial. It took me about a year to come up with the basic ideas, and about 2 additional years to reach the current status. This is the result of 3 years of unpaid work, and even if I want it all to be eventually in the public domain / MIT license (as appropriate), first I need: 1) Publish it with proper author attribution. It might be in a good magazine, or it might be as a Ph.D. thesis. Both require the work to be unpublished before. 2) Secure it in the public domain, so "bad guys" can't patent it. 3) Make some money, to be able to keep working on interesting stuff. This could be done by selling consulting services to someone interested in my work, provided they don't want to restrict what I can do with it.
When I have these worked out (and I welcome help and suggestions from you guys!), I'll be able to make it all available without restrictions.
Also, you show a demo of an image where the seams are not shown. Did you render the all objects to the same buffer or are you able to composite them seamlessly (without having problems with overlaps). And in either case, how did you make this efficient.
I rendered all the objects to an intermediate buffer and later I clean it. This is another part that should be properly published before fully disclosing it.
BTW, why is there also a color difference between your images and Inkscape.
There should be none. Where do you see it?
For example the lion demo on your site. The two versions have very clearly different colors on my monitor. (Perhaps there's an issue with gamma or color profile settings...)
Oh, yes! I needed to check the numeric values. It seems my rgb values are slightly higher. I was using float arithmetic when blending, but recently did an integer only version for speed. It seems I wasn't careful enough when rounding. Thanks for pointing it out! I hope to fix the bug and the samples tomorrow.
Cheers, Juan Vuletich
On Thu, Jun 3, 2010 at 12:06, Juan Vuletich <juan@...2357...> wrote:
rendering, but the Inkscape versions shown side-by-side don't, it doesn't
seem like it's a fair comparison.
But then, fair comparison would be to turn on subpixel rendering on Inkscape. Can that be done?
I don't believe it can be done.
Could you tweak your program to turn off subpixel rendering, and give us
the same samples with subpixel turned off in both?
How can I claim mi technique is better if I disable its advantages? If I did as you say, someone could say, "hey Inkscape does just only 1 pixel wide anti aliasing. could you tweak your filter to do that, to do a fair comparison?" Then, my results would be exactly those of Inkscape, and I'd kill all the progress I did!
Sorry, it sounds like I misunderstood the intent of your algorithm -- I understood it as having advantages for non-subpixel rendering, and the subpixel stuff was just an extra bonus. But it sounds like the subpixel rendering is the main advantage of your algorithm. Is that right?
You did mention "The geometry of the pixels (i.e. the sample positions) is a parameter to the rasterized. It is pretty easy to adapt it to any target or turn it off completely". In light of how I now understand it, turning off subpixel geometry would mean turning off your algorithm altogether.
However, it would be nice to see subpixel rendering in Inkscape, so I applaud your project.
However, I believe many people use Inkscape for creating, not primarily for viewing, and fairly often for exporting (at least, that's how I use it). When you're creating an image file for other people to view, you generally want it be compatible with all types of screens. I use Inkscape mostly for web work, which means I can't use subpixel rendering at all. So I guess that means I can't really benefit from your rendering technique?
Good work, and don't take my questions as criticisms!
- Bryan
Juan Vuletich wrote:
... I believe that existing rasterizers for 2d graphics use either pixel coverage or super sampling. Please point me to some reference if I'm wrong.
Applying a real filter to a continuous ("analog") function and then sampling is something quite different.
Not really. Pixel coverage is just applying a very simple filter. Super sampling is approximating such a simple filter. Admittedly they might not be the best filters possible, but for vector graphics it often doesn't make sense to use filters of very high orders, as that usually introduces ringing. Note that Inkscape could do with a slightly better filter though. It more or less uses a box filter now, using a tent function would probably be better (no ringing, smoother result).
For most renderers the main problem is combining different layers in such a way that no seams appear. I've thought of some solutions that involve adding another channel that more explicitly records the shapes. And if you do super sampling all the way the problem is also reduced. But if you have a method that can eliminate the seams which has the following properties I'll be first in line to see it implemented in Inkscape: - No seams! - Allow compositing AFTER rasterizing, still without seams. - Rasterization not much slower than normal rasterization. - Compositing not much slower than normal compositing. - No or very little additional memory usage.
As for subpixel rendering with Inkscape, you could just export to an image with three times the width and apply some postprocessing. Not perfect, but it would allow a more or less fair comparison.
Bryan Hoyt | Brush Technology wrote:
On Thu, Jun 3, 2010 at 12:06, Juan Vuletich <juan@...2357... mailto:juan@...2357...> wrote:
rendering, but the Inkscape versions shown side-by-side don't, it doesn't seem like it's a fair comparison. But then, fair comparison would be to turn on subpixel rendering on Inkscape. Can that be done?I don't believe it can be done.
Could you tweak your program to turn off subpixel rendering, and give us the same samples with subpixel turned off in both? How can I claim mi technique is better if I disable its advantages? If I did as you say, someone could say, "hey Inkscape does just only 1 pixel wide anti aliasing. could you tweak your filter to do that, to do a fair comparison?" Then, my results would be exactly those of Inkscape, and I'd kill all the progress I did!Sorry, it sounds like I misunderstood the intent of your algorithm -- I understood it as having advantages for non-subpixel rendering, and the subpixel stuff was just an extra bonus. But it sounds like the subpixel rendering is the main advantage of your algorithm. Is that right?
Ok. Did it. Take a look at http://www.jvuletich.org/Morphic3/tigerWholePixel.png . I think it is closer to the subpixel rendered version than to Inkscape.
But I did something else. I opened the web page on several displays. Tried it in 3 LCD screens, with both DVI and VGA interfaces, and at native resolution and at lower resolution. In all cases the subpixel rendered version shows less pixellation and less color artifacts. Then I tried on 2 15" CRT screens, one Trinitron and the other regular, at 1024x768 and at 800x600. The whole pixel version looks consistently better than the Inkscape rendering, although both show some colored shadows that are due to the misalignment between logical pixels, the display's color mask and the actual colored phosphor on the screen. The subpixel version looks less pixellated and also with a slight colored shadow, but in different places. Overall, I find the subpixel version to also look better in these 2 CRT displays! Finally, I tried on an OLPC XO, both in color and b/w modes. There, all alternatives look equally good and it is hard to declare a winner.
So I say that given that the majority of displays sold and in use are RGB LCDs, given that it makes sense to obtain the highest possible quality from the best and most used displays, and given that the subpixel version looks better even in CRTs and doesn't hurt in the XO; it is advisable to use the subpixel version on any display, at least as a default.
When hardware can tell us about the physical geometry of the pixels, then software might make a better choice automatically.
You did mention "The geometry of the pixels (i.e. the sample positions) is a parameter to the rasterized. It is pretty easy to adapt it to any target or turn it off completely". In light of how I now understand it, turning off subpixel geometry would mean turning off your algorithm altogether.
Well, no. My algorithms allows for easily using different filters and different pixel geometries. So, even if using a 1 pixel step filter and no subpixel position, and giving similar results to conventional renderers, it would still be using different algorithms. BTW, in my work, all coordinates are float, and it supports subpixel positioning with float precision, regardless of the sampling grid and the filter. I'm not sure if Inkscape does this. AGG claims to do it.
However, it would be nice to see subpixel rendering in Inkscape, so I applaud your project.
However, I believe many people use Inkscape for creating, not primarily for viewing, and fairly often for exporting (at least, that's how I use it). When you're creating an image file for other people to view, you generally want it be compatible with all types of screens. I use Inkscape mostly for web work, which means I can't use subpixel rendering at all. So I guess that means I can't really benefit from your rendering technique?
Well, as I said before, I believe subpixel rendering is better on almost all displays in use, and should be generally adopted. Even if you decide to turn it off, my filter gives better results (as shown by tigerWholePixel.png), and you also have the seam removal from polygon edges (as shown by the last Clinton image).
Good work, and don't take my questions as criticisms!
- Bryan
Thanks. I welcome criticism too!
Cheers, Juan Vuletich
Jasper van de Gronde wrote:
Juan Vuletich wrote:
... I believe that existing rasterizers for 2d graphics use either pixel coverage or super sampling. Please point me to some reference if I'm wrong.
Applying a real filter to a continuous ("analog") function and then sampling is something quite different.
Not really. Pixel coverage is just applying a very simple filter. Super sampling is approximating such a simple filter.
Right. I also say that in my web page.
Admittedly they might not be the best filters possible, but for vector graphics it often doesn't make sense to use filters of very high orders, as that usually introduces ringing. Note that Inkscape could do with a slightly better filter though. It more or less uses a box filter now, using a tent function would probably be better (no ringing, smoother result).
A lot of experimenting showed me that the shape of the filter is not that important for most images. It does come into play for synthetic images created especially to show aliasing effects. (And as you say, ringing effects would be much worse than lack of smoothness). What is really important for vector graphics is the spatial size of the pixel, related to the "cutoff frequency" (even if step filters don't have a real cutoff frequency). Both pixel coverage and super sampling produce a filter that is one pixel in size. This is not low enough to avoid aliasing, as it doesn't take into account the Kell factor.
For most renderers the main problem is combining different layers in such a way that no seams appear. I've thought of some solutions that involve adding another channel that more explicitly records the shapes. And if you do super sampling all the way the problem is also reduced. But if you have a method that can eliminate the seams which has the following properties I'll be first in line to see it implemented in Inkscape:
- No seams!
- Allow compositing AFTER rasterizing, still without seams.
- Rasterization not much slower than normal rasterization.
- Compositing not much slower than normal compositing.
- No or very little additional memory usage.
My technique has most those properties. But it does need extra memory.
As for subpixel rendering with Inkscape, you could just export to an image with three times the width and apply some postprocessing. Not perfect, but it would allow a more or less fair comparison.
Indeed. You can also look at http://www.jvuletich.org/Morphic3/tigerWholePixel.png , as a said in another response 10 minutes ago.
Cheers, Juan Vuletich
Thanks! Yes, the whole-pixel version still looks better than Inkscape's current rendering.
- Bryan
Juan Vuletich wrote:
... A lot of experimenting showed me that the shape of the filter is not that important for most images. It does come into play for synthetic images created especially to show aliasing effects. (And as you say, ringing effects would be much worse than lack of smoothness). What is really important for vector graphics is the spatial size of the pixel, related to the "cutoff frequency" (even if step filters don't have a real cutoff frequency). Both pixel coverage and super sampling produce a filter that is one pixel in size. This is not low enough to avoid aliasing, as it doesn't take into account the Kell factor.
Makes sense, although I guess there is a fine line between making the image just smooth enough to avoid visual artifacts and simply blurring the image a little.
...
- No seams!
- Allow compositing AFTER rasterizing, still without seams.
- Rasterization not much slower than normal rasterization.
- Compositing not much slower than normal compositing.
- No or very little additional memory usage.
My technique has most those properties. But it does need extra memory.
I guess we'll have to be a bit patient then. BTW, the extra memory can be a problem, unless it's a really, really small overhead.
Let us know when you've got some more details to look at.
Jasper van de Gronde wrote:
Juan Vuletich wrote:
... A lot of experimenting showed me that the shape of the filter is not that important for most images. It does come into play for synthetic images created especially to show aliasing effects. (And as you say, ringing effects would be much worse than lack of smoothness). What is really important for vector graphics is the spatial size of the pixel, related to the "cutoff frequency" (even if step filters don't have a real cutoff frequency). Both pixel coverage and super sampling produce a filter that is one pixel in size. This is not low enough to avoid aliasing, as it doesn't take into account the Kell factor.
Makes sense, although I guess there is a fine line between making the image just smooth enough to avoid visual artifacts and simply blurring the image a little.
Indeed! I use to play a lot with the size of the filter on different LCD screens. In fact, in my samples, you can see a bit ot pixellation in the whiskers of the lion. The filter that makes that disappear makes all the image too blurry.
...
- No seams!
- Allow compositing AFTER rasterizing, still without seams.
- Rasterization not much slower than normal rasterization.
- Compositing not much slower than normal compositing.
- No or very little additional memory usage.
My technique has most those properties. But it does need extra memory.
I guess we'll have to be a bit patient then. BTW, the extra memory can be a problem, unless it's a really, really small overhead.
Let us know when you've got some more details to look at.
Will do. Thanks for all your feedback!
Cheers, Juan Vuletich
2010/6/2 Juan Vuletich <juan@...2357...>:
I am developing a novel way to do anti aliased 2d graphics that breaks away from pixel coverage and super sampling, while being simpler and providing higher quality. Please take a look at http:www.jvuletich.org , especially at the samples.
Comments welcome.
Would it be possible to integrate those algorithms into Cairo?
My GSoC project this year involves porting the rendering system to Cairo, so if those algorithms were integrated into it, all applications that use Cairo would benefit - not only Inkscape.
Regards, Krzysztof
Krzysztof Kosiński wrote:
2010/6/2 Juan Vuletich <juan@...2357...>:
I am developing a novel way to do anti aliased 2d graphics that breaks away from pixel coverage and super sampling, while being simpler and providing higher quality. Please take a look at http:www.jvuletich.org , especially at the samples.
Comments welcome.
Would it be possible to integrate those algorithms into Cairo?
My GSoC project this year involves porting the rendering system to Cairo, so if those algorithms were integrated into it, all applications that use Cairo would benefit - not only Inkscape.
Regards, Krzysztof
Yes, eventually I hope that will happen. It can't be done right now, as I'm working publishing the ideas and algorithms with proper attribution (ideally in a journal paper). I'm also trying to find a way to cash in some of the 3 years of work I invested in it. Ideas are welcome!
Cheers, Juan Vuletich
participants (5)
-
Bryan Hoyt | Brush Technology -
Jasper van de Gronde -
Juan Vuletich -
Krzysztof Kosiński -
Radek