I have a lot of images that taken by my Digital camera with very high resolution 3000 * 4000 and it takes a lot of Hard disk space, I used Photoshop to open each Image and re-size it o be with small resolution, but it needs a lot of time and effort
I think that I can write simple program that open the folder of images and read each file and get it's width and height and if it's very high change it and overwrite the image with the small one.
Here some code I use in a Java-EE project (should work in normal application to:
int rw = the width I needed;
BufferedImage image = ImageIO.read(new File(filename));
ResampleOp resampleOp = new ResampleOp(rw,(rw * image.getHeight()) / image.getWidth() );
resampleOp.setFilter(ResampleFilters.getLanczos3Filter());
image = resampleOp.filter(image, null);
File tmpFile = new File(tmpName);
ImageIO.write(image, "jpg", tmpFile);
The resample filter comes from java-image-scaling library. It also contains BSpline and Bicubic filters among others if you don't like the Lanczos3. If the images are not in sRGB color space Java silently converts the color space to sRGB (which accidentally was what I needed).
Also Java loses all EXIF data, thought it does provide some (very hard to use) methods to retrieve it. For color correct rendering you may wish to at least add a sRGB flag to the file. For that see here.
+1 to what some of the other folks said about not specifically needing Java for this, but I imagine you must have known this and were maybe asking because you either wanted to write such a utility or thought it would be fun?
Either way, getting the image file listing from a dir is straight forward, resizing them correctly can take a bit more leg work as you'll notice from Googling for best-practices and seeing about 9 different ways to actually resize the files.
I wrote imgscalr to address this exact issue; it's a dead-simple API (single class, bunch of static methods) and has some good adoption in webapps and other tools utilizing it.
Steps to resize would look like this (roughly):
Get file list
BufferedImage image = ImageIO.read(files[i]);
image = Scalr.resize(image, width);
ImageIO.write(image);
There are a multitude of "resize" methods to call on the Scalr class, and all of them honor the image's original proportions. So if you scale only using a targetWidth (say 1024 pixels) the height will be calculated for you to make sure the image still looks exactly right.
If you scale with width and height, but they would violate the proportions of the image and make it look "Stretched", then based on the orientation of the image (portrait or landscape) one dimension will be used as the anchor and the other incorrect dimension will be recalculated for you transparently.
There are also a multitude of different Quality settings and FIT-TO scaling modes you can use, but the library was designed to "do the right thing" always, so using it is very easy.
You can dig through the source, it is all Apache 2 licensed. You can see that it implements the Java2D team's best-practices for scaling images in Java and pedantically cleans up after itself so no memory gets leaked.
Hope that helps.
You do not need Java to do this. It's a waste of time and resources. If you have photoshop you can do it with recording actions: batch resize using actions
AffineTransformOp offers the additional flexibility of choosing the interpolation type, as shown here.
You can individually or batch resize with our desktop image resizing application called Sizester. There's a full functioning 15-day free trial on our site (www.sizester.com).
Related
I am trying to write a SWT component, that is able to take and draw an instance of java.awt.BufferedImage. My problem is that SWT's Image and AWT's BufferedImage are incompatible: SWT components can't draw java.awt.Image, AWT/Swing components can't draw org.eclipse.swt.graphics.Image.
There are several approaches that try to solve this problem in other ways (which also may have some variations, but basically there are these two):
Convert between SWT Image and AWT BufferedImage
Swing/SWT Integration
They all have shortcomings and didn't satisfy my expectations:
The first approach, to convert an SWT Image to a BufferedImage, results in poor performance for large images due to the creation of a new RGB instance for every Pixel.
The second approach has several shortcomings in usability. See the "workarounds" at the end of the linked article.
This lead to the conclusion that I'd try my best to write a component (based on org.eclipse.swt.widgets.Canvas or org.eclipse.swt.widgets.Composite) which allows to draw a BufferedImage directly without any conversion of images.
My approach was to draw it pixel by pixel. Therefore I simply had to get an instance of GC, walk the source BufferedImage line by line, left-to-right and drawing the corresponding Color using GC.setForeground(Color color) and GC.drawPoint(int x, int y).
First, I created a new instance of Color for every pixel, which uses quite a lot of memory and adds an additional delay, since new Color acquires system resources and creating a new object for every pixel also takes its time.
Then I tried to pre-load all possible (24 bit) Colors into an array before drawing the image. This lead to an explosion of memory usage (>= 600 MB), which was clear before I was trying it, but I had to verify it.
Caching only the used Colors also lead to more memory consumption than would have been required.
I think there has to be a more low-level approach that doesn't require that much memory, since SWT is able to draw whole (SWT) Images without consuming that much memory.
I would appreciate any ideas or solutions.
I found out there's a way to "convert" an BufferedImage to an Image by using the original image's data buffer if it is 24 bit RGB. This is possible, since the image formats are compatible.
final BufferedImage original = ImageIO.read(new File("some-image.jpg");
final PaletteData palette =
new PaletteData(0x0000FF, 0x00FF00, 0xFF0000);
// the last argument contains the byte[] with the image data
final ImageData data = new ImageData(original.getWidth(), original.getHeight(),
24, palette, 4,
((DataBufferByte) original.getData().getDataBuffer()).getData());
final Image converted = new Image(getDevice(), data);
This way, one doesn't have to create thousands of new objects. This approach comes with the disadvantage that one needs to ensure that the original image is of type RGB 24 bit. Otherwise the image has to be converted to this format.
After that, an image can be drawn with the following code:
// get the GC of your component
gc.drawImage(image, 0, 0);
Probably other bit depths can be converted in a similar way, but this is all I need for the moment.
I'm working on a project, a client-server application named 'remote desktop control'. What I need to do is take a screen capture of the client computer and send this screen capture to the server computer. I would probably need to send 3 to 5 images per second. But considering that sending BufferedImage directly will be too costly for the process, I need to reduce the size of the images. The image quality need not to be loss less.
How can I reduce the byte size of the image? Any suggestions?
You can compress it with ZIP very easily by using GZIPInputStream and its output counterpart on the other end of the socket.
Edit:
Also note that you can create delta images for transmission, you can use a "transpartent color" for example (magic pink #FF00FF) to indicate that no change was made on that part of the screen. On the other side you can draw the new image over the last one ignoring these magic pixels.
Note that if the picture already contains this color you can change the real pink pixels to #FF00FE for example. This is unnoticable.
An other option is to transmit a 1-bit mask with every image (after painting the no-change pixels to an arbitrary color. For this you can change the color which is mostly used in the picture to result in the best compression ratio (optimal huffman-coding).
Vbence's solution of using a GZIPInputStream is a good suggestion. The way this is done in most commercial software - Windows Remote Desktop, VNC, etc. is that only changes to the screen-buffer are sent. So you keep a copy on the server of what the client 'sees', and with each consecutive capture you calculate what is different in terms of screen areas. Then you only send these screen areas to the client along with their top-left coords, width, height. And update the server copy of the client 'view' with just these new areas.
That will MASSIVELY reduce the amount of network data you use, while I have been typing this answer, only 400 or so pixels (20x20) are changing with each keystroke. This on a 1920x1080 screen is just 1/10,000th of the screen, so clearly worth thinking about.
The only expensive part is how you calculate the 'difference' between one frame and the next. There are plenty of libraries out there to do that cheaply, most of them very mathematical (discrete cosine transform type stuff, way over my head), but it can be done relatively cheaply.
See this thread for how to encode to JPG with controllable compression/quality. The slider on the left is used to control the level.
Ultimately it would be better to encode the images directly to a video codec that can be streamed, but I am a little hazy on the details.
One way would be to use ImageIO API
ImageIO.write(buffimg, "jpg", new File("buffimg.jpg"));
As for the quality and other parameters- I'm not sure, but it should be possible, just dig deeper.
i want to write a mapviewer, i must to work small tile of big map image file and there is need to tiling the big image, the problem now is to tiling big image to small tiles (250 * 250 pixel or like this size)
so on, i used ImageMagic program to do it but there was problem
now is any other programing method or application that do tiling?
can i do it with JAI in java? how?
Have you tried doing it in java yourself? I tried this with (WARNING, big image, can crash your browser, use "save as...") this image. Needed to run with extra memory though (-Xmx400M).
public class ImageTile {
public static void main(String[] args) throws IOException {
Dimension tileDim = new Dimension(250, 250);
BufferedImage image = ImageIO.read(new File(args[0]));
Dimension imageDim = new Dimension(image.getWidth(), image.getHeight());
for(int y = 0; y < imageDim.height; y += tileDim.height) {
for(int x = 0; x < imageDim.width; x += tileDim.width) {
int w = Math.min(x + tileDim.width, imageDim.width) - x;
int h = Math.min(y + tileDim.height, imageDim.height) - y;
BufferedImage tile = image.getSubimage(x, y, w, h);
ImageIO.write(tile, "JPG", new File("tile-"+x+"-"+y+".jpg"));
}
}
}
}
For the large images sizes like you have, you will be best served with lossless editing of the JPEG files. Not only is this faster, since the image doesn't need to be rendered, but it also preserves quality, since the image is not recompressed.
Lossless editing works on blocks, typically 16px square. While restrictive for some applications, this seems a good fit for mapping. You could implement tiling at different zoom levels by first losslessly cropping the image to sized pieces. (This is quick an efficient since the image is not rendered.) This gives you tiles for full-zoom. To create lower-levels of zoom, combine 2x2 tiles and scale these down to the size of 1 tile. The next level uses 4x4 tiles, and 8x8 and so on, each time scaling down to one tile. At some point when the number of tiles beecomes too large, you can choose to use zoomed tiles as the base resource. For example, at zoom level 8, that would require 256x256 tiles. This might be too much to handle, so you could use 16x16 tiles from zoom level 4.
Wikipedia has more on lossless editing, and links to some implementing libraries.
imagemagick does tiling using -tile. It's more of a repitition of an image, but might be useful esp. since youre already using it. However If you mean generated seamless tiling I'm not sure if imagemagick can do that or not.
GDAL comes with a script called gdal2tiles.py that does exactly what you want, including formatting the tiles for use with Google Maps, OpenLayers, etc.
There seems to be an newer version of GDAL2Tiles as well.
How about a megatexture with an r-tree for efficient access? Apparently it can use images 128000x128000 pixels.
JAI is platform dependent and seems like a dead project today.
I advise using the open-source program imagemagick. Although it is platform dependent, it is available for the same platforms as JAI, but with full community support.
The trick about large images about imagemagick is using its "stream"-command instead of the convert command. Stream only reads the relevant portion of the image and saves the extracted part as raw data. You then need "convert" to save the small raw data as jpeg.
Example to save a tile from large.jpeg of size 800x600 from position 0x0 to tile.jpeg:
stream -extract 800x600+0+0 large.jpeg tile.rgb
convert -depth 8 -size 800x600 rgb:tile.rgb tile.jpeg
(When running on windows, be sure to use ImageMagick's convert.exe, as there is a windows command named "convert".)
When working with TIFF-images only, apache Sanselan could be the right choice - it is a pure-java imaging lib. Also, JAI seems to contain a platform independent codec for TIFF.
I'm trying to create thumbnails for uploaded images in a JRuby/Rails app using the Image Voodoo plugin - the problem is the resized thumbnails look like... ass.
It seems that the code to generate the thumbnails is absolutely doing everything correctly to set the interpolation rendering hint to "bicubic", but it isn't honoring them on our dev environment (OS X), or on the production web server (Linux).
I've extracted out the code to generate the thumbnails, rewritten it as a straight Java app (ie kicked off from a main() method) with the interpolation rendering hint explicitly set to "bicubic", and have reproduced the (lack of) bicubic and bilinear resizing.
As expected on both OS X and Linux the thumbanils are ugly and pixelated, but on Windows, it resizes the images nicely with bicubic interpolation used.
Is there any JVM environment setting and/or additional libraries that I'm missing to make it work? I'm doing a lot of banging of head against wall for this one.
I realize this question was asked a while ago, but incase anyone else is still running into this.
The reason the thumbnails look like ass are caused by two things (primarily the first one):
Non-incremental image scaling in Java is very rough, throws a lot of pixel data out and averages the result once regardless of the rendering hint.
Processing a poorly supported BufferedImage type in Java2D (typically GIFs) can result in very poor looking/dithered results.
As it turns out the old AreaAveragingScaleFilter does a decent job of making good looking thumbnails, but it is slow and deprecated by the Java2D team -- unfortunately they didn't replace it with any nice out-of-the-box alternative and left us sort of on our own.
Chris Campbell (from the Java2D team) addressed this a few years ago with the concept of incremental scaling -- instead of going from your starting resolution to the target resolution in one operation, you do it in steps, and the result looks much better.
Given that the code for this is decently large, I wrote all the best-practices up into a library called imgscalr and released it under the Apache 2 license.
The most basic usage looks like this:
BufferedImage img = ImageIO.read(...); // load image
BufferedImage scaledImg = Scalr.resize(img, 640);
In this use-case the library uses what is called it's "automatic" scaling mode and will fit the resulting image (honoring it's proportions) within a bounding box of 640x640. So if the image is not a square and is a standard 4:3 image, it will resize it to 640x480 -- the argument is just it's largest dimension.
There are a slew of other methods on the Scalr class (all static and easy to use) that allow you to control everything.
For the best looking thumbnails possible, the command would look like this:
BufferedImage img = ImageIO.read(...); // load image
BufferedImage scaledImg = Scalr.resize(img, Method.QUALITY,
150, 100, Scalr.OP_ANTIALIAS);
The Scalr.OP_ANTIALIAS is optional, but a lot of users feel that when you scale down to a small enough thumbnail in Java, some of the transitions between pixel values are a little too discrete and make the image look "sharp", so a lot of users asked for a way to soften the thumbnail a bit.
That is done through a ConvolveOp and if you have never used them before, trying to figure out the right "kernel" to use is... a pain in the ass. That OP_ANTIALIAS constant defined on the class it the best looking anti-aliasing op I found after a week of testing with another user who had deployed imgscalr into their social network in Brazil (used to scale the profile photos). I included it to make everyone's life a bit easier.
Also, ontop of all these examples, you might have noticed when you scale GIFs and some other types of images (BMPs) that sometimes the scaled result looks TERRIBLE compared to the original... that is because of the image being in a poorly supported BufferedImage type and Java2D falling back to using it's software rendering pipeline instead of the hardware accelerated one for better supported image types.
imgscalr will take care of all of that for you and keep the image in the best supported image type possible to avoid that.
Anyway, that is a REALLY long way of saying "You can use imgscalr to do all that for you and not have to worry about anything".
maybe is this a solution for you:
public BufferedImage resizeImage(BufferedImage source, int width, int height)
{
BufferedImage result = new BufferedImage(widht, height, BufferedImage.TYPE_INT_ARGB);
Graphics g = result.getGraphics();
g.drawImage(source, 0, 0, widht, height, null);
g.dispose();
return result;
}
In the end, upgrading to the latest version of ImageVoodoo seemed to improve quality.
Looking through the source code, it looks like they're doing some funky AWT rendering, and then pulling that out. Nasty, but it seems to work.
Still not as good as ImageMagick, but better than it was.
#Riyad, the code for incremental scaling isn't "decently large", it's quite small (As you can see from a post back in 2007, http://today.java.net/pub/a/today/2007/04/03/perils-of-image-getscaledinstance.html#creating-scaled-instances) having a library that gives other options might be useful, but making a library to use a library is nonsense.
Well I've written a basic lossless jpeg joiner thing in java now but I'd like to compare the files it produces with the original files.
I can only compare so much in a hex editor, does anyone know of an easy way, software or java based (preferably software as I dont feel like any more coding for now!) that I can compare two images and produce a "difference map" of where the pixels aren't the same?
Thanks.
Thanks for the suggestions.
I tried the Gimp approach first which works well except when the difference between the images are very small. I couldn't find an "enhance differences" option to make the differences obvious and the histogram also only gives a rough representation of the differences.
In the end I used ImageMagick something I'd installed a while ago and forgot all about. Creating a difference/comparison image is as easy as typing:
compare first.jpg second.png difference.gif
in the command line.
It's all nicely explained here.
TortoiseIDiff is a free image diff viewer:
http://tortoisesvn.tigris.org/TortoiseIDiff.html
It is part of TortoiseSVN, but can be used without Subversion.
Depending on your project, not all files which are under version
control are text files. Most likely you will have images too, for
example screenshots and diagrams for the documentation/helpfile.
For those files it's not possible to use a common file diff tool,
because they only work with text files and diff line-by-line. Here is
where the Tortoise Image Diff tool (TortoiseIDiff) comes to the
rescue. It can show two images side-by-side, or even show the images
over each other alpha blended.
You could do a lot worse than Perceptual Diff.
The best approach would be to use Pix for windows (comes with the DirectX SDK). Supports Bitmap, PNG and Jpeg...Enjoy!
Use an image editor like Photoshop or the Gimp or whatever, which has multiple layers. Create an image where each source image in a separate layer.
At this point, you can visually compare the images by toggling the top layer's visibility off and on.
In most decent editors, you can also set the top layer to "difference" mode. Now each image pixel's value is the absolute difference of the pixel values in the underlying images. You can use e.g. a histogram tool to see if the images are identical. If they're identical, then all the pixel values will be exactly 0.
For stuff like this, I love the netpbm/pbmplus toolkit. You can use djpeg and pnmtoplainpnm to convert each image into a simple ASCII format. You then just read both files and emit a new image which shows where pixels differ. You could, for example, compute the Euclidean distance in RGB space between old and new pixels and emit a white pixel for zero difference, light gray for a small difference, darker for larger differences, and so on. The ASCII format is simple and is well documented on the man pages, and all the standard viewer programs can view it directly.
The latest version of Araxis Merge will do image diffs ( http://www.araxis.com/merge/topic_comparing_image_files.html ).
Unfortunately it's not a free app so whether or not you're willing to pay for it is another thing...
There's also a convenient web app called Resemble.js, which analyzes and compares images pixel by pixel. The different pixels in the images (if any) are highlighted with pink or yellow color depending on your preference.