You are viewing a plain text version of this content. The canonical link for it is here.
Posted to batik-dev@xmlgraphics.apache.org by Thomas E Deweese <th...@kodak.com> on 2001/04/24 23:53:26 UTC
About my commit
Hi all,
I've just committed the new Image Tag handling stuff (it was large
enough to fail so the header is attached at the end of the message)
It now takes about a page of code to add a new Codec to Batik. I'm
going to be working on adding the true SPI part that tracks down jars
that have classes they want to register with the ImageTagRegistry.
This will allow people to add new formats without touching one line of
Batik Code. Does anyone have good examples of how this is done in
general, I was under the impression that there was a standard way of
doing this but I can't track down any documentation on it now.
To People using URL's in Batik, I'd like to suggest switching to
the batik.util.ParsedURL class where convenient. It offers some nice
things like auto detection and decoding of GZIP streams on openStream.
It's designed _not_ to throw Malformed URL errors all over the place
(it has a 'complete' method to check if the URL "looks good", and the
'getURL' and 'openStream' methods can of course throw errors). It's
also extensible (it supports the data protocol through this).
For those that will complain that some of the images are now dark
most of those images had a gamma tag of approximately 4.4, we had been
displaying them as if the tag were 2.4, in reality for most of these
images the gamma was 2.2 (Some widely used software had a bug where it
wrote out gamma tags 1/2 of what it was supposed to...).
Things to check and get back to me on:
--------------------------------------
Weird images, I've check all the images I could track down but
it's possible that some strange images may still throw the new
ImageTag stuff for a loop.
Speed Issues, I had to add some format conversions to keep
Graphics2D from spilling it's guts in a few places. I don't think
these introduced significant slow downs but if you feel it did let me
know, and I try and look at it. These extra conversions in a few
places are balanced by the fact that in most cases we avoid at least
one extra conversion (in general it should be a win).
Hard edges on images. Many images now come in with no alpha
channel (JPEG and many PNGs) because of this the Affine operation now
clips it's requests for source data to the sources bounds (before it
would pad out the source with transparent black). The result is that
where these elements used to have an anti-aliased edge (bi-linear
interpolation with the pad region) it is now a hard clip. I can go
back to the old way by forcing the image to always have an Alpha
channel if people prefer this.
---
Log:
1) Added new ImageTagRegistry as the way raster images are loaded.
2) Fixed a "blur" bug in DisplacementMapOp (really a premultipy bug).
3) Fixed a 'linear' bug in DisplacementRable8bit
4) A Bunch of work to support the new SampleModels coming in from
potential Image sources.
5) PNG now pays attention to gamma settings.
Modified: samples/tests feDisplacementMap.svg png.png toBeProfiled.png
sources/org/apache/batik/apps/svgbrowser
JSVGViewerFrame.java
sources/org/apache/batik/bridge SVGFeImageElementBridge.java
SVGImageElementBridge.java
sources/org/apache/batik/ext/awt/image GraphicsUtil.java
URLImageCache.java
sources/org/apache/batik/ext/awt/image/codec PNGRed.java
sources/org/apache/batik/ext/awt/image/renderable
ColorMatrixRable8Bit.java
DiffuseLightingRable8Bit.java
DisplacementMapRable8Bit.java TileRable8Bit.java
sources/org/apache/batik/ext/awt/image/rendered
AffineRed.java CompositeRed.java
DisplacementMapOp.java MultiplyAlphaRed.java
TranslateRed.java
sources/org/apache/batik/ext/awt/image/spi
AbstractRegistryEntry.java ImageTagRegistry.java
JPEGRegistryEntry.java
MagicNumberRegistryEntry.java PNGRegistryEntry.java
StreamRegistryEntry.java URLRegistryEntry.java
sources/org/apache/batik/gvt PatternPaintContext.java
RasterImageNode.java
sources/org/apache/batik/util ParsedURL.java
Added: sources/org/apache/batik/ext/awt/image/renderable
ProfileRable.java
sources/org/apache/batik/ext/awt/image/rendered
FormatRed.java
sources/org/apache/batik/ext/awt/image/spi
JDKRegistryEntry.java
Removed: sources/org/apache/batik/ext/awt/image/renderable
RasterRable.java
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: About my commit
Posted by Thomas E Deweese <th...@kodak.com>.
>>>>> "VH" == Vincent Hardy <vh...@eng.sun.com> writes:
VH> Thomas, Thomas E Deweese wrote:
>>
>>
>> Hard edges on images. Many images now come in with no alpha
>> channel (JPEG and many PNGs) because of this the Affine operation
>> now clips it's requests for source data to the sources bounds
>> (before it would pad out the source with transparent black). The
>> result is that where these elements used to have an anti-aliased
>> edge (bi-linear interpolation with the pad region) it is now a hard
>> clip. I can go back to the old way by forcing the image to always
>> have an Alpha channel if people prefer this.
VH> If I understand you properly, I think I would rather have the
VH> alpha channel. However, is there a specific example I should look
VH> at to make sure I understand the change?
Sure, take a look at samples/tests/image.svg Now rotate it.
In particular you will notice that the edge between the SVG image
and the PNG (where the SVG has shadow), and the black around the JPEG
are "stair steppy".
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org
Re: About my commit
Posted by Vincent Hardy <vh...@eng.sun.com>.
Thomas,
Thomas E Deweese wrote:
>
>
> Hard edges on images. Many images now come in with no alpha
> channel (JPEG and many PNGs) because of this the Affine operation now
> clips it's requests for source data to the sources bounds (before it
> would pad out the source with transparent black). The result is that
> where these elements used to have an anti-aliased edge (bi-linear
> interpolation with the pad region) it is now a hard clip. I can go
> back to the old way by forcing the image to always have an Alpha
> channel if people prefer this.
If I understand you properly, I think I would rather have the alpha
channel. However, is there a specific example I should look at to
make sure I understand the change?
Thanks.
V.
---------------------------------------------------------------------
To unsubscribe, e-mail: batik-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: batik-dev-help@xml.apache.org