>>>>> "JA" == Jeff Adams <[EMAIL PROTECTED]> writes:
>> As a followup, is the smoothing of all JPEGs part of the SVG spec?
No, however using "high quality interpolators" for bitmap data is
encouraged by the SVG spec.
>> In this case I might be generically generating JPEGs of small or
>> large sizes and by default I'd like to not have them "smoothed".
>> The Adobe SVG plugin has a "High quality" switch that turns this
>> off, is there a way I can turn this off with Batik, or more useful,
>> is there something in the spec that I can add to my svg creation
>> (done dynamically) that can request the smoothing be off for all
>> plugins by default?
I'm guessing that this actually turns on bi-cubic interpolation.
>> I do not want to generate separate rects because this explodes the
>> SVG sizes when the image is larger... I also think the same
>> smoothing happens for embedded PNGs when I tested it a few months
>> back.
JA> Sorry about asking this too soon as I do not know why I did not
JA> see this the first time but using the attribute
JA> image-rendering="optimizeSpeed" to <image> will change the default
JA> smoothing of JPEGs
This tells Batik to use Nearest Neighbor Interpolation for bitmap
data.
JA> I notice the spec talks as if one always wants this on bitmap
JA> data, and technically optimizeSpeed doesn't guarantee the
JA> interpolation doesn't occur in a user agent..
Interpolation always occurs in the user agent. what you really
want is to be able to say exactly what form of interpolation takes
place for bitmap data. This is problematic.
JA> Maybe the set of users wanting exact display of bitmap pixels is
JA> small?
The only way to get "exact display of bitmap pixels" is to have
the size of the bitmap in pixels match the display size in pixels. As
SVG is "resolution independent" this practically speaking is
impossible (you may get it for most screen displays but when you print
it won't be true - or if it is the image will be tiny).
Let's take some examples:
If we have a 4x4 bitmap what do you want to do when it needs to
fill a 12x12 screen area?
Presumably you want each pixel replicated two be 3x3.
What if it's a 10x10 pixel area?
Two colums get replicated twice and two get replicated three
times? Clearly this doesn't fit your "exact display" criteria...
So you see the problem is some form of interpolation must happen.
You seem to want what is called Nearest Neighbor (no blending occurs
between pixels) most images look better with bi-linear or bi-cubic.
The rendering hints are our way of allowing authors to control this.
It's a sticky wicket how many ways do you want to force implementors
to interpolate, Nearest Neighbor, bi-linear, bi-cubic, truncated sinc,
'PostScript', etc... There are so many interpolation methods
available each of which is tailored for a particular situation that a
standard can't really pick an choose. So we offer a loose control to
let authors give some indication of the intent of the rendering.
So, Nearest Neighbor is pretty easy to implement and I would guess
that most implementations that have multiple bitmap resamplers
available will have Nearest Neighbor and will map it to optimizeSpeed
(I know of examples in OpenGL where because resampling is done in
hardware bi-linear was just as fast as Nearest Neighbor so the
'optimizeSpeed' equivilent was mapped to bi-linear, so this probably
won't be fool proof).
I might also point out that for 'exact display of bitmap pixels'
JPEG is a lousy choice.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
