Re: [JAVA2D] createCompatibleImage: why is it faster than creating a Buffered image?

[Jim Graham]

I think I've discovered at least one problem that you are running into - 
we don't have an optimized loop to convert from 1-bit binary images to 
INT_RGB images.  Further, the general code that gets used doesn't take 
the best advantage of the existing optimized loops that do exist.


We only have a loop to convert from 1-bit to INT_ARGB so if you 
drawImage directly to an INT_RGB image then it will have to do a slower 
work-around technique.


To find this out (I thought this had been mentioned a couple of years 
ago on some forum, but I can't seem to find it with a search), there is 
a hidden utility in the JDK where you can get the system to print out 
the supported loops.  It was originally designed so that you could just 
execute:


  % java sun.java2d.loops.GraphicsPrimitiveMgr list

and it would print out all of the built-in rendering loops in the 
system.  Unfortunately we broke this at some point and so now it 
generates an error that a required native method isn't found.  The 
workaround is still simple - compile and run the following very short 
program and it will do the same thing:


  public class GPMgr {
public static void main(String argv[]) {
  java.awt.Toolkit.getDefaultToolkit();
  sun.java2d.loops.GraphicsPrimitiveMgr.main(argv);
}
  }
  % javac GPMgr.java
  % java GPMgr list

I grepped for Blit and ByteBinary and discovered that there are only 
convert (Blit(XX, SrcNoEa, YY)) loops for 1-bit to ARGB.  The thing that 
surprised me, though, was that it took 4 times longer even despite the 
workarounds.  I quickly ran a trace on copying a 1-bit image to INT_RGB 
and discovered that it ends up using a loop called 
OpaqueCopyAnyToIntArgb which is a Java loop that uses a couple of 
method calls per pixel.  There are faster ways it could do this, even 
without creating a specific loop for this case, but it will take a bit 
of elbow grease as the logic in that part of the system is a little 
obscure...


...jim

===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.

Re: [JAVA2D] createCompatibleImage: why is it faster than creating a Buffered image?

[Jim Graham]

jav...@javadesktop.org wrote:

- let us know what image formats you are seeing in the loaded image and
which Reader is loading it so we can consider adding loops that deal
with that format more directly (or modifying our format detection code
to recognize it if there is something amiss with our classifications).
We do already have support for a fair number of binary image formats
so I'm curious as to what the exact specifics of the format are and why
they fail to trigger our existing optimized binary format loops. This
should probably be done through the bug tracking system to keep records
of the issue...
Your comment above seem to indicate that you have optimized loops for reading binary images directly in compatible BufferedImages. Is that correct? 


There are 2 issues here:

- What do you have to do to use a 1-bit image loaded from disk efficiently

- How can you efficiently convert it into an efficient format if just 
using the loaded 1-bit image is slow


The first question basically depends on the image reader using only 
methods that avoid tainting the image so that the returned BufferedImage 
can be managed.  I'm not sure why that is not happening without further 
investigation, but maybe Dmitri or Chris know what is going on there off 
the top of their heads.


As to the second question, when I looked at the support we had it was 
pretty sketchy in the Blit support department (see my previous message 
where I listed the available loops and then looked at what got used by 
the drawImage call).  We have routines for rendering to 1-bit images, 
but we only have a couple of conversion routines for blitting from 1-bit 
to another format (to ARGB and back to be specific).  So, there is room 
for improvement there (both in avoiding the very general 
OpaqueCopyAnyToArgb loop and possibly in adding a few more Blit 
converters for the format).



If yes, then my simple most important question would be:
What is the method to read a binary image from a file fast and have a 
compatible BI in memory? My tests indicate that saving a RGB BI in the BMP 
format will do the trick, but here is the catch:


For now it seems you have to do some conversion and it looks like you've 
finally arrived at a decent way of doing that short of not having to do 
it in the first place.


I think it's worth filing a bug on the conversion process (really a 
drawImage should have done the trick without too much fuss, but you had 
to work around that).


We should probably also investigate why the 1-bit image is not being 
managed so that you don't need any conversion at all.  Is it a bug in 
the reader, or in our image management (caching) code?


In any case, you shouldn't have to resort to BMP to work around this - 
we're so close, let's look at closing the gap on a 1-bit TIFF.



So, instead of trying to find out what is the best way to convert, it would be 
better to know what is optimized and how to use it! I understand that in the 
general case, the average jdk developer does not need to know what you optimize 
and what not, but it would be a great idea to publicize this info (even 
unofficial, i understand that you wouldn't want to write this in stone).


I think my previous message mentioned some tools for programmers to get 
a glimpse into what we've targetted with direct implementations vs. what 
we do with general workaround code...


...jim

===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.

Re: [JAVA2D] createCompatibleImage: why is it faster than creating a Buffered image?

[java2d]

Hello Jim,
you have provided here so much valuable information that i doubt if i have 
found that before all in one place, THANK YOU.

Let me come to some specifics:
 What is the image format you are using in the TIFF file and what are the
parameters of the *Models it uses to represent it in memory? (Before
 you start converting it.)
I am actually using tif file (group 4 fax encoding, 1bpp) that i save with 
ImageIO.write in the first place.
Reading back this file (with ImageIO.read) produces the following image: 
bufferedim...@19f1bac: type = 12 IndexColorModel: #pixelBits = 1 numComponents 
= 3 color space = java.awt.color.icc_colorsp...@d1e832 transparency = 1 
transIndex   = -1 has alpha = false isAlphaPre = false BytePackedRaster: width 
= 2528 height = 3188 #channels 1 xOff = 0 yOff = 0


Concerning the code optimization you suggested:
You were absolutely correct: the fastest and most efficient way is to use the 
getPixels() on the source raster and the setDataElements on the destination 
raster (with a new BI(TYPE_INT_RGB). This produces directly a manageable image 
in a very fast way. And i do read-write in a single line per time, so i reuse 
the same int[] buffer for reading and writing (and more, the black pixels are 
copied as they are, i don't even have to change the buffer values). (The 
drawImage method takes always 50% more).

 - let us know what image formats you are seeing in the loaded image and
 which Reader is loading it so we can consider adding loops that deal
 with that format more directly (or modifying our format detection code
 to recognize it if there is something amiss with our classifications).
 We do already have support for a fair number of binary image formats
 so I'm curious as to what the exact specifics of the format are and why
 they fail to trigger our existing optimized binary format loops. This
 should probably be done through the bug tracking system to keep records
 of the issue...
If you bare with me a little more, i would need your advice and clarification.
Please, read this scenario:
What i do in my app is get some images from a scanner (mostly binary images, 
but also gray and rgb), save them in a tif file, and then display them one by 
one. Since scanning is slow (well, 50pages-per-min maximum for now), i do have 
time while the scanner is doing it's job to do many things (e.g. pre-optimize 
images for later display). Your comment above seem to indicate that you have 
optimized loops for reading binary images directly in compatible 
BufferedImages. Is that correct? 
If yes, then my simple most important question would be:
What is the method to read a binary image from a file fast and have a 
compatible BI in memory? My tests indicate that saving a RGB BI in the BMP 
format will do the trick, but here is the catch:
Suppose a binary image of 3000X3000 pixels: in a tif file, it will take 50K on 
disc and 40ms to read back the tif file (plus another 200ms to convert to 
compatible in memory). If the same binary image is pre-converted to RGB and 
saved to a BMP, it will take about 30MB on disk and about 500ms to re-load in a 
already compatible BI, so the whole thing will not be faster (due to heavy disk 
io).

So, instead of trying to find out what is the best way to convert, it would be 
better to know what is optimized and how to use it! I understand that in the 
general case, the average jdk developer does not need to know what you optimize 
and what not, but it would be a great idea to publicize this info (even 
unofficial, i understand that you wouldn't want to write this in stone).

Costas
[Message sent by forum member 'csterg' (csterg)]

http://forums.java.net/jive/thread.jspa?messageID=349916

===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.

Re: [JAVA2D] createCompatibleImage: why is it faster than creating a Buffered image?

[java2d]

Thank you for all your answers, there is one question not answered yet:

Is it possible to create a BufferedImage with a custom DataBuffer that can be 
put in the video-cache?

Costas
[Message sent by forum member 'csterg' (csterg)]

http://forums.java.net/jive/thread.jspa?messageID=349659

===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.

Re: [JAVA2D] createCompatibleImage: why is it faster than creating a Buffered image?

[Jim Graham]

jav...@javadesktop.org wrote:

Thank you Dmitri for your answer.
Let me just say a bit more of the problem and why i go to this method:

My goal is to find the faster way to load an image from the disk (a tif file, 
either binary or colored) and display it on the screen in a compatible way 
(e.g. fast to redraw, pan, zoom, etc).

From all the reading i have done, i have concluded that i need to:
1. Load the image with ImageIO
2. Convert it to compatible
3. Display.

1. Converting an image to a compatible one is always faster with  a ColorConverOp than with a g.drawImage. At times the speed is the same, but in general, the ColorConverOp is always a bit faster. 


Both ColorConvertOp and drawImage have a set of image formats that they 
handle directly with optimized loops (all native code), and other 
formats that they use generalized code that may be as slow as making a 
method call per pixel.  You seem to be running into cases where CCO has 
optimized loops, but drawImage does not.  We tend to look to add loops 
for drawImage to handle common image formats that come up for our 
developers, but we need to avoid adding too many special case loops and 
bloating the JDK.



What is really interesting is this: if an images already uses a 
SinglePixelPackedSampleModel then the ColorConvertOp is significantly faster 
(more than 50%).


What is the image format you are using in the TIFF file and what are the
parameters of the *Models it uses to represent it in memory?  (Before 
you start converting it.)



2. So the question remains:
  a. Is it faster to convert directly to compatible using g.drawImage, or
  b. is it faster to create an unmanageable image with a 
SinglePixelPackedSampleModel and then use the ColorConvertOp to make a 
compatible out of it?


g.drawImage() has optimized loops to convert from some common image 
formats to destination images in some other common image formats.  If 
you fall into one of those categories then it makes sense to use that.


ColorConvertOp also has its own set of loops as well.

With respect to SPPSM, it isn't so much about that particular sample 
model than about which parameters you use with it.  When we classify an 
image internally we examine not just the type of the SampleModel and 
ColorModel, but what masks, offsets, and other parameters they use.


g.drawImage() is one of the simplest techniques, and for occasional use, 
or for use at application startup for most image sizes any potential 
performance issues with that technique are probably not noticeable. 
But, if you are doing this to a lot of images on the fly, then it is 
worth optimizing this step some more (and pushing to have the internal 
drawImage() code support it more directly as well).



This is why i use it.


Empirical results are often the best guide here, but let me present some 
rules of thumb which might help make the choices easier (to make, or at 
least easier to understand) and point out some potential other alternatives.


First, some details about the implementation:

- If you grab the DataBuffer from an image, it becomes unmanageable in 
JDK 6 and prior.  This would recommend using the various WritableRaster 
methods to write data to the images if you want to remain manageable, or 
using a conversion process.  This is also true if you have a DataBuffer 
and make a BufferedImage out of it.


- In JDK 7 and beyond we now track the pixels at the DataBuffer level so 
you can grab the DataBuffer and use its methods to modify or access an 
image, as long as you don't grab the array itself from the DataBuffer. 
For instance, creating a DataBuffer using your own array automatically 
disqualifies the image from being manageable.  This gets you much closer 
to the raw data without disrupting the cache management, but only works 
on JDK 7 and forward.


- Manageable images, as you seem to already be aware, can be hardware 
accelerated via cached copies kept in VRAM on platforms that support it, 
so it is good to use techniques that maintain that property if they work 
well enough, otherwise doing what works best even if it defeats image 
management and using the old convert to a compatible image after the 
fact technique becomes necessary.


- As I stated above, drawImage has a matrix of optimized from/to image 
format pairs it supports well for doing software copies and conversions. 
 These copies are going to be slower than a hardware copy, but much 
faster than the code that deals with arbitrary from/to images which 
often breaks down to a per-pixel method call.


- Also, as stated earlier, ColorConvertOp also has a matrix of from/to 
formats, but it is implemented using an entirely different system than 
drawImage and so the matrix is unrelated.  This Op may also need to 
resort to per-pixel method calls if you fall outside its matrix.


- The most likely candidates for support in the matrices above would be 
the formats created using the new BufferedImage(w,h,TYPE_FOO) 
constants.  It looks 

Re: [JAVA2D] createCompatibleImage: why is it faster than creating a Buffered image?

[java2d]

 The first thing that you will have to understand is
 that Java is going to be slower than anything except maybe Flash.
  If your goal s to be as fast as C, C++, C# or .Net then you should
 find another goal
 because it is already a given that Java will be slower.
You mix up runtime enviroments and languages. However nice try. 

  But your experiments are important because they will
 reveal the flaws and
 inconsistencies in Java2D, BufferedImage and ImageIO.
Just because their design is too flexible for you to understand, doesn't mean 
its flawed.

- Clemens
[Message sent by forum member 'linuxhippy' (linuxhippy)]

http://forums.java.net/jive/thread.jspa?messageID=349645

===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.

Re: [JAVA2D] createCompatibleImage: why is it faster than creating a Buffered image?

[Ken Warner]

Last time I looked, both C and C++ had runtime code -- I suppose
one could dispute that that code created a runtime environment.  I
wouldn't argue with that.

And if the design of an API is so complex that the average programmer can't
understand how to use it is the hallmark of good design -- well then you win --
BufferedImage great design.

jav...@javadesktop.org wrote:

The first thing that you will have to understand is
that Java is going to be slower than anything except maybe Flash.
If your goal s to be as fast as C, C++, C# or .Net then you should
find another goal
because it is already a given that Java will be slower.


You mix up runtime enviroments and languages. However nice try. 


  But your experiments are important because they will


reveal the flaws and
inconsistencies in Java2D, BufferedImage and ImageIO.


Just because their design is too flexible for you to understand, doesn't mean 
its flawed.

- Clemens
[Message sent by forum member 'linuxhippy' (linuxhippy)]

http://forums.java.net/jive/thread.jspa?messageID=349645

===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.



===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.

Re: [JAVA2D] createCompatibleImage: why is it faster than creating a Buffered image?

[java2d]

Thank you Dmitri for your answer.
Let me just say a bit more of the problem and why i go to this method:

My goal is to find the faster way to load an image from the disk (a tif file, 
either binary or colored) and display it on the screen in a compatible way 
(e.g. fast to redraw, pan, zoom, etc).

From all the reading i have done, i have concluded that i need to:
1. Load the image with ImageIO
2. Convert it to compatible
3. Display.

Point 2 is what takes more time (since i don't think i can optimize the time 
for reading).
Here are some benchmarks:

1. Converting an image to a compatible one is always faster with  a 
ColorConverOp than with a g.drawImage. At times the speed is the same, but in 
general, the ColorConverOp is always a bit faster. 
What is really interesting is this: if an images already uses a 
SinglePixelPackedSampleModel then the ColorConvertOp is significantly faster 
(more than 50%).

2. So the question remains:
  a. Is it faster to convert directly to compatible using g.drawImage, or
  b. is it faster to create an unmanageable image with a 
SinglePixelPackedSampleModel and then use the ColorConvertOp to make a 
compatible out of it?

It seems that method-b is between 2-3 times faster than method-a for colored 
images! This is very impressive for me!
For binary images, both methods provide similar results, but again method-b 
tends to be a bit faster (about 10%-20%).

This is why i use it.

My original thought was this then:
Since with the second method it is possible to create an image with the exact 
same characteristics of a compatible, why do i need to go through the step of 
converting to a compatible one? You answered to me on that one: because the 
image is not manageable!

So, i tried to modify my code and instead of creating the DataBuffer myself, i 
use the WriteableRaster to set the pixel values: but it seems that the time 
needed for the 'setSamples' method is bigger than method-b. So, it seems that 
no-matter what i do, still the fastest way is to create the DataBuffer myself 
and then convert to compatible image with the ColorConvertOp.

It would be great if i could find a way to create a compatible image with my 
own DataBuffer that is also manageable (without another conversion/step). Is 
there a solution to this?

Excuse me if some of the above comments are incorrect, but i am new to Java2D 
programming. Also, i would GREATLY appreciate if there is yet another method to 
do what i want (e.g. load and display an image) in a faster way. To be honest i 
am creating an app here and i compare it with the speed of others that are 
written in native code (or even .NET) and mine is much slower. It's hard to 
accept that i cannot do with Java what others are doing with c or .net,

By the way: i have also tried caching the compatible image to the disk, but 
this is not faster: an image of 300dpi takes more time to read from a file.
Another question comes in mind here: is there a format (like tif or jpg) in 
which i can save an image and then read-it back and still be 'compatible' 
without another conversion? I tried saving it as a .bmp but the size of it 
(30MB) makes it much slower to read...



Thank you for your advice,
Costas
[Message sent by forum member 'csterg' (csterg)]

http://forums.java.net/jive/thread.jspa?messageID=349536

===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.

Re: [JAVA2D] createCompatibleImage: why is it faster than creating a Buffered image?

[Ken Warner]

The first thing that you will have to understand is that Java is
going to be slower than anything except maybe Flash.  If your goal
is to be as fast as C, C++, C# or .Net then you should find another goal
because it is already a given that Java will be slower.

Another way to display an image is the use of MemoryImageSource and
BufferStrategy which can be very useful for animations but not necessarily
faster in loading since the only way to load a tif image is with ImageIO
and BufferedImage.

But your experiments are important because they will reveal the flaws and
inconsistencies in Java2D, BufferedImage and ImageIO.  Note them down
carefully.

A complete study of all the various pathways an image can take from disk to 
display along with timings for each pathway would be an even more valuable

task than the task you are currently attempting.

Making a catalog of all the ways Java can make an image and the pitfalls
and workarounds necessary for many of those paths would make a very valuable
white paper.  It will not be an easy task.

If you work on a task like that, don't forget to look carefully at
ImageReadParam and how that can be used and how it can lead to a multitude of
dead ends.

It is no small task to do this but you will learn a lot and that knowledge
will be valuable.

jav...@javadesktop.org wrote:

Thank you Dmitri for your answer.


Excuse me if some of the above comments are incorrect, 

but i am new to Java2D programming. Also, i would GREATLY appreciate if there is
yet another method to do what i want (e.g. load and display an image) in a 
faster way.
To be honest i am creating an app here and i compare it with the speed of others 
that

are written in native code (or even .NET) and mine is much slower.

It's hard to accept that i cannot do with Java what others are doing with c or 
.net,

===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.

Re: [JAVA2D] createCompatibleImage: why is it faster than creating a Buffered image?

[Dmitri Trembovetski]

  Could you please show the code which creates the BufferedImage?

  Thanks,
Dmitri


jav...@javadesktop.org wrote:

Hi all,
I am trying to create a BufferedImage manually (e.g. via the constructor) and i 
am using the DirectColorModel and the SinglePixelPackedSampleModel. I am trying 
to find the optimal models in order to have an image that is rendered fast.
When i use the getDefaultConfiguration().createCompatibleImage method, i get an 
image with the exact same models.

My problem is that the BufferedImage i create myself does not render as fast as 
the compatible one. I have compared every little detail between the 2, yet the 
compatible always renders much faster. Do i miss something?

Of course, it's simple to make convert my BufferedImage to a compatible one 
with an extra step, but this is exactly what i want to avoid (to speed up 
display).

Can anyone give me some hint here? Is there some special accelleration 
connected with the images that are created through the 'createCompatibleImage' 
method?

Thanks,
Costas
[Message sent by forum member 'csterg' (csterg)]

http://forums.java.net/jive/thread.jspa?messageID=349338

===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.


===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.

Re: [JAVA2D] createCompatibleImage: why is it faster than creating a Buffered image?

[java2d]

Of course.
Here is a proc that converts a binary image to a compatible RGB:

  public static BufferedImage 
convertToSinglePixelPackedSampleModel_BINARY(BufferedImage image) {
int[] bitMasks = new int[]{0x00ff, 0xff00, 0x00ff};
SinglePixelPackedSampleModel sampleModel = new 
SinglePixelPackedSampleModel(DataBuffer.TYPE_INT, image.getWidth(),
image.getHeight(), bitMasks);
int[] pixels = image.getRaster().getPixels(0, 0, image.getWidth(), 
image.getHeight(), (int [])null);

for(int i=0; ipixels.length; i++)
  if (pixels[i] == 1)
pixels[i] = 0x00ff;

DataBufferInt d = new DataBufferInt(pixels, pixels.length);
WritableRaster destRaster = Raster.createWritableRaster(sampleModel, d, 
null);

ICC_ColorSpace colorSpace = new 
ICC_ColorSpace(ICC_Profile.getInstance(ColorSpace.CS_sRGB));
ColorModel colorModel = new DirectColorModel(colorSpace, 24, bitMasks[0], 
bitMasks[1], bitMasks[2], 0, false, DataBuffer.TYPE_INT);
image = new BufferedImage(colorModel, destRaster, false, null);
return image;
  }


Now, here is the code that converts to compatible image:
   public static BufferedImage toCompatibleImage(final BufferedImage image) {
 long now = System.currentTimeMillis();
 final BufferedImage compatible = GraphicsEnvironment
 .getLocalGraphicsEnvironment()
 .getDefaultScreenDevice()
 .getDefaultConfiguration()
 .createCompatibleImage(image.getWidth(), image.getHeight(), 
image.getTransparency());
ColorConvertOp op = new 
ColorConvertOp(image.getColorModel().getColorSpace(), 
compatible.getColorModel().getColorSpace(), null);
op.filter(image, compatible);
return compatible;
  }


If i take a binary image and convert it to RGB (first method), the 
BufferedImage i get is faster to render (of course), but still at least 4 times 
slower to render than in the case that i later convert to compatible image also.

The image before and after the conversion to compatible are identical.
What do i miss here?

Thank you,
Costas
[Message sent by forum member 'csterg' (csterg)]

http://forums.java.net/jive/thread.jspa?messageID=349435

===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.

Re: [JAVA2D] createCompatibleImage: why is it faster than creating a Buffered image?

[java2d]

Of course.
Here is a proc that converts a binary image to a compatible RGB:
[code]
  public static BufferedImage 
convertToSinglePixelPackedSampleModel_BINARY(BufferedImage image) {
int[] bitMasks = new int[]{0x00ff, 0xff00, 0x00ff};
SinglePixelPackedSampleModel sampleModel = new 
SinglePixelPackedSampleModel(DataBuffer.TYPE_INT, image.getWidth(),
image.getHeight(), bitMasks);
int[] pixels = image.getRaster().getPixels(0, 0, image.getWidth(), 
image.getHeight(), (int [])null);

for(int i=0; ipixels.length; i++)
  if (pixels[i] == 1)
pixels[i] = 0x00ff;

DataBufferInt d = new DataBufferInt(pixels, pixels.length);
WritableRaster destRaster = Raster.createWritableRaster(sampleModel, d, 
null);

ICC_ColorSpace colorSpace = new 
ICC_ColorSpace(ICC_Profile.getInstance(ColorSpace.CS_sRGB));
ColorModel colorModel = new DirectColorModel(colorSpace, 24, bitMasks[0], 
bitMasks[1], bitMasks[2], 0, false, DataBuffer.TYPE_INT);
image = new BufferedImage(colorModel, destRaster, false, null);
return image;
  }
[/code]

Now, here is the code that converts to compatible image:
[code]
   public static BufferedImage toCompatibleImage(final BufferedImage image) {
 long now = System.currentTimeMillis();
 final BufferedImage compatible = GraphicsEnvironment
 .getLocalGraphicsEnvironment()
 .getDefaultScreenDevice()
 .getDefaultConfiguration()
 .createCompatibleImage(image.getWidth(), image.getHeight(), 
image.getTransparency());
ColorConvertOp op = new 
ColorConvertOp(image.getColorModel().getColorSpace(), 
compatible.getColorModel().getColorSpace(), null);
op.filter(image, compatible);
return compatible;
  }
[/code]

If i take a binary image and convert it to RGB (first method), the 
BufferedImage i get is faster to render (of course), but still at least 4 times 
slower to render than in the case that i later convert to compatible image also.

The image before and after the conversion to compatible are identical.
What do i miss here?

Thank you,
Costas
[Message sent by forum member 'csterg' (csterg)]

http://forums.java.net/jive/thread.jspa?messageID=349437

===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.

Re: [JAVA2D] createCompatibleImage: why is it faster than creating a Buffered image?

[Dmitri Trembovetski]

  The problem with your first method is that you are creating the image with 
your own DataBuffer. This prohibits this image from ever being cached in video 
memory since we can not guarantee that the cache will be up to date with the 
original image. Thus the image is unmanageable.


  I'm not sure why you need to convert your original image in the first place, 
but there is much faster way to do it than your second method.
  Instead of doing the color convert op, just draw the src image into the 
destination:


[code]
  Graphics2D g = (Graphics2D)compatible.getGraphics();
  g.setComposite(AlphaComposite.Src);
  g.drawImage(image, 0, 0, null);
[/code]

  Thanks,
Dmitri


jav...@javadesktop.org wrote:

Of course.
Here is a proc that converts a binary image to a compatible RGB:

  public static BufferedImage 
convertToSinglePixelPackedSampleModel_BINARY(BufferedImage image) {
int[] bitMasks = new int[]{0x00ff, 0xff00, 0x00ff};
SinglePixelPackedSampleModel sampleModel = new 
SinglePixelPackedSampleModel(DataBuffer.TYPE_INT, image.getWidth(),
image.getHeight(), bitMasks);
int[] pixels = image.getRaster().getPixels(0, 0, image.getWidth(), 
image.getHeight(), (int [])null);

for(int i=0; ipixels.length; i++)
  if (pixels[i] == 1)
pixels[i] = 0x00ff;

DataBufferInt d = new DataBufferInt(pixels, pixels.length);
WritableRaster destRaster = Raster.createWritableRaster(sampleModel, d, 
null);

ICC_ColorSpace colorSpace = new 
ICC_ColorSpace(ICC_Profile.getInstance(ColorSpace.CS_sRGB));
ColorModel colorModel = new DirectColorModel(colorSpace, 24, bitMasks[0], 
bitMasks[1], bitMasks[2], 0, false, DataBuffer.TYPE_INT);
image = new BufferedImage(colorModel, destRaster, false, null);
return image;
  }


Now, here is the code that converts to compatible image:
   public static BufferedImage toCompatibleImage(final BufferedImage image) {
 long now = System.currentTimeMillis();
 final BufferedImage compatible = GraphicsEnvironment
 .getLocalGraphicsEnvironment()
 .getDefaultScreenDevice()
 .getDefaultConfiguration()
 .createCompatibleImage(image.getWidth(), image.getHeight(), 
image.getTransparency());
ColorConvertOp op = new 
ColorConvertOp(image.getColorModel().getColorSpace(), 
compatible.getColorModel().getColorSpace(), null);
op.filter(image, compatible);
return compatible;
  }


If i take a binary image and convert it to RGB (first method), the 
BufferedImage i get is faster to render (of course), but still at least 4 times 
slower to render than in the case that i later convert to compatible image also.

The image before and after the conversion to compatible are identical.
What do i miss here?

Thank you,
Costas
[Message sent by forum member 'csterg' (csterg)]

http://forums.java.net/jive/thread.jspa?messageID=349435

===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.


===
To unsubscribe, send email to lists...@java.sun.com and include in the body
of the message signoff JAVA2D-INTEREST.  For general help, send email to
lists...@java.sun.com and include in the body of the message help.