Re: [JAVA2D] Availability of PhotoComposite API with hardware accelaration
Hi Vince, I know this is probably not what you are looking for (and it certainly isn't hardware accelerated). Oh, and you proably already knew about it.. But given the lack of response on this topic, I'll post it anyway. ;-) Romain Guy did some work on advanced blending modes for photo compositing. You can find it here: http://www.curious-creature.org/2006/09/20/new-blendings-modes-for-java2d/ Best regards, .k On 3. okt.. 2008, at 17.39, [EMAIL PROTECTED] wrote: Hi everyone, I am looking periodically at the status of RFE 6541868 (Synopsis RFE: hardware acceleration for advanced blending modes (aka PhotoComposite) ) and other related RFEs. With all the progress made within java 6 update 10 about the Direct3D and OpenGL pipelines, I was wondering when we could expect to see the hardware-accelerated PhotoComposite API. Now that java GUI can benefit by default from these pipelines, it would be seriously cool to be able to bring more advanced blending effects than the current Porter-Duff rules implementation in the AlphaComposite API. Does any of you guys have news on this ? Cheers. Vince. [Message sent by forum member 'vync79' (vync79)] http://forums.java.net/jive/thread.jspa?messageID=303194 = = = = = == To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Long-running rendering ...was Re: Drawing to an off screen buffer
Hi Chris, You might want to take a look at the Task class from Swing Application Framework. It is a great abstraction for long-running operations in general. It's basically a fancy SwingWorker, with support for a nice publish/process-protocol, which I think you could use for your drip- feed mechanism. Not really sure it fits your needs, but I think it's worth looking into. Best regards, -- Harald K On 25. sep.. 2008, at 22.34, [EMAIL PROTECTED] wrote: I'm starting think my problem is knowing what solution applies to my situation. There are plenty of solutions for handling long-running tasks in Swing. (SwingWorker, etc.) There are solutions for double buffering for animations (BufferStrategy). But, I don't think either of those apply to long-running rendering tasks. Maybe a solution to that would be to drip-feed little subtasks onto the event queue such that there is only one rendering task on the queue at a time and user events will be interleaved in the queue between rendering tasks. Any other ideas or examples for maintaining a responsive UI in the presence of long-running rendering tasks? Thanks, -chris [Message sent by forum member 'cbare' (cbare)] http://forums.java.net/jive/thread.jspa?messageID=301678 = = = = = == To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] LinearGradientPaint not accurate?
Hi Steve, Thanks a lot for the response! At first my colors were fully opaque. And for some reason it just don't work.. I actually ended up doing something similar to what you describe. I first fill the component with a solid, opaque color (the background), then I do a fade from the opaque bright color to the same bright, but transparent color. It's probably slower than the all opaque version, but at least I get the effect I want. :-) Best regards, -- Harald K On 17. sep.. 2008, at 16.42, [EMAIL PROTECTED] wrote: Do you use only fully opaque painting when drawing in your ComponentUIs ? As I'm not fully aware with performance in terms of opacity, I can't say it will always be a better idea to go for opacity tricks. However, here is my thought about a way to do such an effect (linear aqua gloss) : Just create a gradient, going for the brightest color you want to see on your..glare to the same color, but with transparent opacity : From RGB(255,255,255,255) to RGB(255,255,255,0) for example. The coordinates of this gradient are (if vertical) : (0,0) to (0, component height) Then fill a gradient rectangle using these coordinates (still an example) : (0,0) to (0, component height / 2 ) It usually works quite well on simple glass effects. You could also fill any other shape, for example something a bit rounded to add shape to your pane or button. Whether you want to do aqua painting or linear gradient painting, some parts or others of this technique should work better for you. Let me know about it, Cheers, Steve [Message sent by forum member 'artscoop' (artscoop)] http://forums.java.net/jive/thread.jspa?messageID=299842 = = = = = == To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] LinearGradientPaint not accurate?
Hi,
I've been doing some fun wor,k creating cusomt UI delegates for Swing
lately. And I've come across an issue with LineGradientPaint, where I
want to create a gradient from some color (say white) to the
background color of my component, to create a typical gloss effect.
However, I find that no matter what I do, the gradient will never end
at the background color (it's always slightly off, enough to make a
visual artifact). I'm wondering if there is a reason for this? I
suspect there might be some hardware or native code acceleration
tricks going on here, that approximate colors? Is there a way or hint
to make it more accurate (I tried setting the rendering hint
COLOR_RENDERING to QUALITY with no success)?
My code looks something like this:
int x, y, w, h; // Bounds of my component
Graphics2D g;
Color background = getBackground();
g.setPaint(new LinearGradientPaint(x, y, x, y + h - 1, new float[] {.
2f, .5f}, new Color[] {Color.WHITE, background}));
g.fillRect(x, y, w, h);
My background color is 0xE8E8E8 (RGB), but the gradient fades from
0xFF to 0xEE halfway through, and then continues with that
color.
PS: I'm using Java 6 for Mac OS X, which may have their own
optimizations. I'll ask in a Mac forum as well, but want to know if
this is a general problem first.
Best regards,
--
Harald K
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Dynamics of acceleration of BufferedImages (managed images)
Hi, On 10. sep.. 2008, at 14.12, [EMAIL PROTECTED] wrote: 2) When using ImageIO, sticking a BufferedImage into the params object (forcing the ImageIO to use the supplied BI instead of allocating itself), will this permanently defeat acceleration for this BI instance? (Basically, does ImageIO access the data buffer? If it does, is there some magic there that could internally tell the system to re-copy the data buffer to VRAM?) As a writer of several 3rd party plugins for use with ImageIO, I can only tell you that this is up to the plugin. The behaviour is probably the same, regardless of passing a destination image or not (but again, that might be up to the plugin). I think however that it is possible to stick to only performing operations on the Raster and thus preserving the accelerated version. My own plugins don't behave well in this area, and this is something I plan to fix when time permits. The plugins supplied by the JDK and maybe even JAI ImageIO should behave this way (preserve acceleration). Somebody, please correct me if I'm wrong. :-) Best regards, -- Harald K === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] drawimage on a bilevel image does not work
Hi, You can't do an alpha-blended composition of two bi-level images, as a bilevel image has only two levels, either completely white or completely black. So you first have to create a new temporary true color BufferedImage (any of the TYPE_INT_RGB or TYPE_3/4BYTE_RGB/BGR will probably do fine), and then draw both your images into that. Use alpha only for the second image. Good luck! ;-) -- Harald K On 4. aug.. 2008, at 17.50, [EMAIL PROTECTED] wrote: I am trying to add one image above another image. And tried alpha from 0 to 1, they all did not work. So what's right way to do this? [Message sent by forum member 'jiezhang' (jiezhang)] http://forums.java.net/jive/thread.jspa?messageID=291351 = = = = = == To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Any way to make ANTIALIAS only use one color
Once again, this time to the list.. ;-) On 2. aug.. 2008, at 00.24, Jim Graham wrote: Since it doesn't seem to be working well with your particular colormap, my suggestion is to not use Antialiasing - or to come up with a better selection of colors in your colormap that provide enough intermediate colors for the AA algorithm to do its job... One thing you could try, is creating an intermediate image in full RGB (copy the indexed image first), then render text with antialiasing to the intermediate image. Then either create a new indexed image from that (might end up with a different color map), or paint the image back to the original indexed image. It usually gives a better result. -- Harald K === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Join images (tiles) with low memory footprint
Hi, The quick answer is you can't do that with one large BufferedImage because, as it name suggests, it's buffered (in memory). It might be that you could use some kind of RenderedImage though. I suggest you search the JAI/ImageIO mailing list archives, or ask the list. They probably have some ideas how you can do just that. Best regards, .k On 11. juli. 2008, at 15.24, [EMAIL PROTECTED] wrote: I have the following problem: I try to join many tile images into a big image using BufferedImage and then storing it as PNG or JPG. Memory usage is linear - for 4000x4000 pixel result image (16,000,000 pixel) I need 16 times more memory than for a 1,000,000 pixel image. Do you know a method of joining small images into a large image using a constant memory footprint? Any hints will be appreciated. Best, Marcin [Message sent by forum member 'mgryszko' (mgryszko)] http://forums.java.net/jive/thread.jspa?messageID=285971 = = = = = == To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] is it possible?
On 10. juli. 2008, at 11.18, [EMAIL PROTECTED] wrote:
but i want to Draw it
Try something like:
@Override
protected void paintComponent(Graphics g) {
...
String html = ...;
JLabel label = new JLabel(html);
label.setBounds(getBounds());
label.setVisible(true);
label.paint(g);
...
}
Feels a little hackish, but should work...
.k
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
Re: [JAVA2D] Pushing int[] pixel data into Image
Hmmm.. According to some very naive and simple tests, creating and drawing a BufferedImage is faster than creating and drawing an Image from a MemoryImageSource, at least on my Mac. The time creating the image from a preallocated int array is really neglible in both cases though. So I'd make some application-specific benchmarks before I would take that advice for fact. The new (compared to ImageSource) BufferedImage API is also more likely to use a native code/HW accelerated code path from what I understand. The difference in steps is't that great. In the sample code below, it's 6 vs 7 lines of code to create the image (naive way). But yes, the extra flexibility you get from BufferedImage/Raster probably comes with some cost when it comes to complexity (or maybe just learning curve). int w; int h; int[] rgb = new int[w * h]; // ... create some fancy image directly to the byte array ... DirectColorModel cm = (DirectColorModel) ColorModel.getRGBdefault(); // MemorImageSource vesion MemoryImageSource source = new MemoryImageSource(w, h, cm, rgb, 0, w, null); Image image = Toolkit.getDefaultToolkit().createImage(source); // BufferedImage version DataBufferInt buffer = new DataBufferInt(rgb, w * h); WritableRaster raster = Raster.createPackedRaster(buffer, w, h, w, cm.getMasks(), null); image = new BufferedImage(cm, raster, cm.isAlphaPremultiplied(), null); To replace a region of the image, you would probably create a new Raster for your subregion and use raster.setRect(x, y, subregion). But if you really like, you could simply manipulate the rgb int array directly. Not sure that's much faster though. Best regards, -- Harald K On 6. juli. 2008, at 06.28, Ken Warner wrote: The absolute fastest way is to first stay away from BufferedImage. Use MemoryImageSource. It's real easy to use -- as opposed to BufferedImage which nobody really understands and takes 10 steps to do one simple thing. Make an image using MemoryImageSource then use BufferStrategy (not BufferedImage) to render to the screen. [EMAIL PROTECTED] wrote: I have an int array where each element represents the RGB value for a pixel and I need to push that data into an image buffer (which is preferably a VolatileImage but may be a BufferedImage if using a VI for this is not possible) such that a subregion of the image buffer takes on the pixels in the int array. What's the best way to achieve this in the absolute fastest possible way? = = = = = == To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help. === To unsubscribe, send email to [EMAIL PROTECTED] and include in the body of the message signoff JAVA2D-INTEREST. For general help, send email to [EMAIL PROTECTED] and include in the body of the message help.
[JAVA2D] ColorConvertOp with non-ICC color space
Hi everyone,
Sorry for cross-posting. I guess this belongs to the Java2D list, but
my assumption is that someone in the imageio-community is more likely
to have run into this problem before, and have some hints.
I'm currently writing an ImageIO plugin for Photoshop Document format
(PSD). I'm running into a problem when I try to run a ColorConvertOp
with a non-ICC (CMYK) color space (my own custom class). Does anyone
have some hints on how to make this work? Or is this a JDK bug?
The exception I get is this:
java.lang.IllegalArgumentException: Component index out of range: +
component
at java.awt.color.ICC_ColorSpace.getMinValue(ICC_ColorSpace.java:522)
at java.awt.image.ColorConvertOp.nonICCBIFilter(ColorConvertOp.java:
790)
at java.awt.image.ColorConvertOp.filter(ColorConvertOp.java:260)
at
com
.twelvemonkeys
.imageio.plugins.psd.PSDImageReader.main(PSDImageReader.java:491)
To me, it seems like a bug in ColorConvertOp, as my custom color space
has same number of components as the embedded ICC color profile in the
PSD, and running the CCOp on the ColorSpace created from that ICC
profile works fine.
There's at least a bug in the code that creates the exception message
(end quote in wrong place), that makes me worried this code might
never be tested..
// From ColorConvertOp:
public float getMinValue(int component) {
if ((component 0) || (component this.getNumComponents() -
1)) {
throw new IllegalArgumentException(
Component index out of range: + component);
}
...
The code I use to convert looks like this:
...
BufferedImage image = psdImageReader.read(0);
if (image.getColorModel().getColorSpace().getType() ==
ColorSpace.TYPE_CMYK) {
ColorConvertOp op = new
ColorConvertOp(ColorSpace.getInstance(ColorSpace.CS_sRGB), null);
image = op.filter(image, new
BufferedImage(image.getWidth(), image.getHeight(),
BufferedImage.TYPE_4BYTE_ABGR_PRE));
}
My custom color space class looks like this (not complete yet, but
enough to make it work):
final class CMYKColorSpace extends ColorSpace {
CMYKColorSpace() {
super(ColorSpace.TYPE_CMYK, 4);
}
public float[] toRGB(float[] colorvalue) {
return new float[] {
(1 - colorvalue[0]) * (1 - colorvalue[3]),
(1 - colorvalue[1]) * (1 - colorvalue[3]),
(1 - colorvalue[2]) * (1 - colorvalue[3])
};
}
public float[] fromRGB(float[] rgbvalue) {
// Compute CMY
float c = 1 - rgbvalue[0];
float m = 1 - rgbvalue[1];
float y = 1 - rgbvalue[2];
// Find K
float k = Math.min(c, Math.min(m, y));
// Convert to CMYK values
return new float[] {(c - k), (m - k), (y - k), k};
}
public float[] toCIEXYZ(float[] colorvalue) {
throw new UnsupportedOperationException(Method toCIEXYZ not
implemented); // TODO: Implement
}
public float[] fromCIEXYZ(float[] colorvalue) {
throw new UnsupportedOperationException(Method fromCIEXYZ
not implemented); // TODO: Implement
}
}
Best regards,
--
Harald K
===
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message signoff JAVA2D-INTEREST. For general help, send email to
[EMAIL PROTECTED] and include in the body of the message help.
