Rasterizer detect subpixel width lines when rendering to specified dpi with 1 bit per pixel 2 color bitmap

[Rob Davis-5 <te...@robertjdavis.co.uk>]

Is it possible for the batik PNG/bitmap rasteriser to inform the user/calling
code if it encounters a line that is subpixel in width and so would not
render - i.e. not appear? That is, will be omitted, missed out in the
resultant PNG image because it is too thin?

Does this feature already exist?

Perhaps some kind of Exception could be raised or interface/call back
method?

Could you outline what would be required to extend the batik classes that
are involved in this?

I'm particularly interested in two-tone - i.e. black and white only, no
gray/grey shades/levels. This means there would be no anti-aliasing.

I'm guessing that the anti-aliasing engine in batik is used to give very
thin lines lighter shades of grey - so the fact that it knows enough to do
this, perhaps this part of the code could be used to raise an exception with
the knowledge that anti-aliasing is not wanted.

This thread relates to my previous discussion about Chinese characters and
minimal dpi rendering for them in a monochrome bi-level 2 color only
environment. A good solution was offered by using a very complex Chinese
character as a benchmark. See:

http://www.nabble.com/Chinese-characters---what%27s-the-smallest-recpmmended-dpi-resolution-rendering-to17425380.html#a17503472

However, what about a more general solution that could cope with any
scenario of thin lines and detect if they would be missing from the
resultant bitmap output?

Perhaps even a solution could suggest a minimum dpi for the SVG for all
lines to be visible in a 2 colour, 1 bit per pixel bitmap?


-- 
View this message in context: http://www.nabble.com/Rasterizer-detect-subpixel-width-lines-when-rendering-to-specified-dpi-with-1-bit-per-pixel-2-color-bitmap-tp18384830p18384830.html
Sent from the Batik - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

Re: Rasterizer detect subpixel width lines when rendering to specified dpi with 1 bit per pixel 2 color bitmap

[Helder Magalhães <he...@gmail.com>]

> > Is it possible for the batik PNG/bitmap rasteriser to inform the user/calling
> > code if it encounters a line that is subpixel in width and so would not
> > render - i.e. not appear? That is, will be omitted, missed out in the
> > resultant PNG image because it is too thin?
> > Does this feature already exist?

Have you taken a look at the non scaling stroke property [1] of SVG
1.2? This may help you achieve the desired behavior, independently of
the rasterizer tricks described within this thread. ;-)

Unfortunately, I've just checked that Batik currently (using the trunk
version) doesn't appear to support it -- backed up by the SVG 1.2
status page [2] also, where this isn't stated anywhere... :-|


> OpenCV could be used to compare low resolution renders of an SVG against a
> high resolution render of an SVG. Tolerances could be fine tuned and applied
> so that irrelevant errors and differences are ignored and reports of missing
> lines are the things that the user gets to know about.

Have you taken a look into Batik's regard (test infrastructure) [3]?
With a few (potential) modifications, it could be used to accomplish
this purpose also: using a different resolution (probably a much
higher one) for comparison could help catching cases like the ones
being described in this thread...


Hope this helps,

 Helder Magalhães


[1] http://www.w3.org/TR/SVGTiny12/painting.html#NonScalingStroke
[2] http://xmlgraphics.apache.org/batik/dev/svg12.html
[3] http://xmlgraphics.apache.org/batik/dev/test.html#regard

---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

Re: Rasterizer detect subpixel width lines when rendering to specified dpi with 1 bit per pixel 2 color bitmap

[Rob Davis-5 <te...@robertjdavis.co.uk>]

Thanks Thomas for replying - my thoughts below:


thomas.deweese wrote:
> 
> ...to write a new rasterizer that looked for this sort of case...
> 
> ...You might be able to do something with machine vision algorithms to
> construct a
> 'stroked' version of the glyph (rendered at a higher resolution)
> and then try to match that against your low res version.  But that
> would be a significant research project....
> 

I think OpenCV looks very promising: this is an open source, free, computer
vision software library.
http://SourceForge.net/projects/opencvlibrary
The library is written in C and C++ and runs under Linux, Windows and Mac OS
X. There is active development on interfaces for Python, Ruby, Matlab, and
other languages. Not Java yet though.

There is also an O'Reilly book that has been published in September 2008:
OpenCV, by Dr. Gary Rost Bradski, Adrian Kaehler. It looks very
comprehensive.
http://oreilly.com/catalog/9780596516130/
ISBN 10: 0-596-51613-4 | ISBN 13: 9780596516130

OpenCV could be used to compare low resolution renders of an SVG against a
high resolution render of an SVG. Tolerances could be fine tuned and applied
so that irrelevant errors and differences are ignored and reports of missing
lines are the things that the user gets to know about.

If I get an opportunity to look into this further I'll let you know.

-- 
View this message in context: http://www.nabble.com/Rasterizer-detect-subpixel-width-lines-when-rendering-to-specified-dpi-with-1-bit-per-pixel-2-color-bitmap-tp18384830p20974109.html
Sent from the Batik - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org

Re: Rasterizer detect subpixel width lines when rendering to specified dpi with 1 bit per pixel 2 color bitmap

[th...@kodak.com]

Hi Rob,

Rob Davis-5 <te...@robertjdavis.co.uk> wrote on 12/09/2008 05:56:33 AM:

> Is it because:
> - People are too busy

  One vote!

> Rob Davis-5 wrote:
> > 
> > Is it possible for the batik PNG/bitmap rasteriser to inform the
> > user/calling code if it encounters a line that is subpixel in width 
and so
> > would not render - i.e. not appear? That is, will be omitted, missed 
out
> > in the resultant PNG image because it is too thin?
> > 
> > Does this feature already exist?

   No.

> > Perhaps some kind of Exception could be raised or interface/call back
> > method?
> > 
> > Could you outline what would be required to extend the batik classes 
that
> > are involved in this?

   There are two cases to consider.  The first is the fairly easy one
which is where the 'line' is drawn as the stroke on an object.  Knowing
that the line in this case will be <1 pixel is simply a matter of
multiplying the stroke width by the square root of the determinate of
the user-space to device-space affine transform (the drawing transform
for the line).  This could probably be added to 
batik.gvt.StrokeShapePainter
in it's paint method.

   The second case is where part of a piece of a path is small/narrow
enough that it will render as <1 pixel wide/high.  This would be
very difficult to detect.  The easiest way (which is like saying
the easiest way to clime Mt. Everest) would be to write a new rasterizer
that looked for this sort of case.

> > I'm particularly interested in two-tone - i.e. black and white only, 
no
> > gray/grey shades/levels. This means there would be no anti-aliasing.
> > 
> > I'm guessing that the anti-aliasing engine in batik is used to give 
very
> > thin lines lighter shades of grey - so the fact that it knows enough 
to do
> > this, perhaps this part of the code could be used to raise an 
exception
> > with the knowledge that anti-aliasing is not wanted.

    We use the Java 2D rasterizer, so we don't really know what it's 
doing.
And in anycase if you are rendering with anti-aliasing on there are always 

anti-aliased pixels and it doesn't really indicate a problem (for example 
at
the tips of characters).

> > This thread relates to my previous discussion about Chinese characters 
and
> > minimal dpi rendering for them in a monochrome bi-level 2 color only
> > environment. A good solution was offered by using a very complex 
Chinese
> > character as a benchmark. See:
> > 
> > http://www.nabble.com/Chinese-characters---what%27s-the-smallest-
> recpmmended-dpi-resolution-rendering-to17425380.html#a17503472
> > 
> > However, what about a more general solution that could cope with any
> > scenario of thin lines and detect if they would be missing from the
> > resultant bitmap output?

    So unfortunately characters fall into the second case above.
I am not aware of any algorithm that can do this.  You might be
able to do something with machine vision algorithms to construct a
'stroked' version of the glyph (rendered at a higher resolution)
and then try to match that against your low res version.  But that
would be a significant research project....

> > Perhaps even a solution could suggest a minimum dpi for the SVG for 
all
> > lines to be visible in a 2 colour, 1 bit per pixel bitmap?

    See above...

Re: Rasterizer detect subpixel width lines when rendering to specified dpi with 1 bit per pixel 2 color bitmap

[Rob Davis-5 <te...@robertjdavis.co.uk>]

No replies to this thread. This is unusual for the thriving and frequently
updated batik forum!

Is it because:
- I have asked something very obvious
- I have asked something that people would not find useful. (Surely not!)
- This is already been worked on
- This is an incredibly good idea and someone is going to patent it!?
- People are too busy

I'd like to help with a solution; from my posting history you'll see that I
try to post answers to my own problems and also help others.

In general thanks for all your support!



Rob Davis-5 wrote:
> 
> Is it possible for the batik PNG/bitmap rasteriser to inform the
> user/calling code if it encounters a line that is subpixel in width and so
> would not render - i.e. not appear? That is, will be omitted, missed out
> in the resultant PNG image because it is too thin?
> 
> Does this feature already exist?
> 
> Perhaps some kind of Exception could be raised or interface/call back
> method?
> 
> Could you outline what would be required to extend the batik classes that
> are involved in this?
> 
> I'm particularly interested in two-tone - i.e. black and white only, no
> gray/grey shades/levels. This means there would be no anti-aliasing.
> 
> I'm guessing that the anti-aliasing engine in batik is used to give very
> thin lines lighter shades of grey - so the fact that it knows enough to do
> this, perhaps this part of the code could be used to raise an exception
> with the knowledge that anti-aliasing is not wanted.
> 
> This thread relates to my previous discussion about Chinese characters and
> minimal dpi rendering for them in a monochrome bi-level 2 color only
> environment. A good solution was offered by using a very complex Chinese
> character as a benchmark. See:
> 
> http://www.nabble.com/Chinese-characters---what%27s-the-smallest-recpmmended-dpi-resolution-rendering-to17425380.html#a17503472
> 
> However, what about a more general solution that could cope with any
> scenario of thin lines and detect if they would be missing from the
> resultant bitmap output?
> 
> Perhaps even a solution could suggest a minimum dpi for the SVG for all
> lines to be visible in a 2 colour, 1 bit per pixel bitmap?
> 
> 
> 

-- 
View this message in context: http://www.nabble.com/Rasterizer-detect-subpixel-width-lines-when-rendering-to-specified-dpi-with-1-bit-per-pixel-2-color-bitmap-tp18384830p20912483.html
Sent from the Batik - Users mailing list archive at Nabble.com.


---------------------------------------------------------------------
To unsubscribe, e-mail: batik-users-unsubscribe@xmlgraphics.apache.org
For additional commands, e-mail: batik-users-help@xmlgraphics.apache.org