Develop Reference

javaxt.io.Image doubles in size when using saveAs()

In an application, I need to use javaxt.io.Image to rotate the image and then save it into a new file. This is the code:
Image image = new Image(input);
image.rotate();
image.saveAs(output);
While the image does lose the EXIF rotation, which is the reason I needed this functionality, the image almost doubles in size. input.jpg is at 2.8MB, while output.jpg becomes 4.3MB. I couldn't find a parameter or function for compression in javaxt.io.Image.
Did I miss a step or is this behaviour wanted by the library? What would be the most efficient way to re-reduce the size?

As Thomas commented, I missed the function setOutputQuality(float quality) in the library documentation. Using that enables you to compress your images.

Change the format of an Image in java without saving

I would like to read an image and then change its format but without saving it.
For example I can read the image like this
BufferedImage img=ImageIO.read(new File(fileName));
Then I want to change the format of img, for example from jpeg to png.
The only way I found is to use ImageIO.read to write and then read the new image, but it does seem to be an efficient way to do it.

When you "read" the image via
BufferedImage img=ImageIO.read(new File('myimage.png'));
you are not only reading but also decoding it, i.e., transforming the raw bytes in the (say) PNG format to some "RAW" format that your aplication or API can manipulate (or display) - in this case, a BufferedImage. Once this is done, the fact that this image came from a PNG file is forgotten. To read it as PNG and save it as JPEG you need to decode it (as PNG) and then code it (as JPG).
I would like to read an image and then change its format but without saving it.
The "format" of the image (in the PNG/JPEG sense) gives you a way of packing an image in a sequence of bits. So, your desire makes little sense. At most, you could store those bits in memory (what for?), but that would be the same as "saving it" (to memory instead of disk).

Efficient way to send an image over socket in Java

I'm a bit of a Java noob, and I have read some basics about sockets and I can successfully send images over socket using ImageIO, but I want to reduce the amount of data that is sent. Ultimately I want the image (screen capture) to be send as fast as possible with the smallest possible file size.
Right now, I have imageIO set up as such;
DataInputStream in=new DataInputStream(client.getInputStream());
DataOutputStream out = new DataOutputStream(client.getOutputStream());
ImageIO.write(captureImg(),"JPG",client.getOutputStream());
And the receiver:
BufferedImage img=ImageIO.read(ImageIO.createImageInputStream(server.getInputStream()));
File outputfile = new File("Screen"+(date.toString())+".jpg");
ImageIO.write(img, "jpg", outputfile);
In case you're wondering, this is my method that is used to take the image.
Rectangle screenRect = new Rectangle(Toolkit.getDefaultToolkit().getScreenSize());
BufferedImage capture = new Robot().createScreenCapture(screenRect);
I have heard about Byte arrays, where you can send the bytes then draw the image at the other end. However I'm not sure if this is more efficient.
Any help would be greatly appreciated, please ask if you would like me to add any extra info or code for the byte array!
Thanks.
EDIT: Patrick:
ByteArrayOutputStream bScrn = new ByteArrayOutputStream();
ImageIO.write(captureImg(), "JPG", bScrn);
byte imgBytes[] = bScrn.toByteArray();
out.write((Integer.toString(imgBytes.length)).getBytes());
out.write(imgBytes,0,imgBytes.length);

There already has been an extensive discussion in the comments, but to summarize a few points that I find important:
You have a trade-off between several criteria:
Minimize network traffic
Minimize CPU load
Maximize image quality
You can reduce the network traffic with a high image compression. But this will increase the CPU load and might reduce the image quality.
Whether it reduces the image quality depends on the compression type: For JPG, you can make the image arbitrarily small, but the quality of the image will then be ... well, arbitrarily bad. For PNG, the image quality will stay the same (since it is a lossless compression), but the CPU load and the resulting image size may be greater.
The option of ZIPping the image data was also mentioned. It is true that ZIPping the JPG or PNG data of an image will hardly reduce the amount of data (because the data already is compressed). But compressing the raw image data can be a feasible option, as an alternative to JPG or PNG.
Which compression technique (JPG, PNG or ZIP) is appropriate also depends on the image content: JPG is more suitable for "natural" images, like photos or rendered images. These can withstand a high compression without causing artefacts. For artifical images (like line drawings), it will quickly cause undesirable artefacts, particularly at sharp edges or when the image contains texts. In contrast to that: When the image contains large areas with a single color, then a compression like PNG (or ZIP) can reduce the image size due to the "run length compression" nature of these compression methods.
I already made some experiments for such an image transfer quite a while ago, and implemented it in a way that easily allowed tweaking and tuning these parameters and switching between the different methods, and comparing the speed for different application cases. But from the tip of my head, I can not give a profound summary of the results.
BTW: Depending on what you actually want to transfer, you could consider obtaining the image data with a different technique than Robot#createScreenCapture(Rectangle). This method is well-known to be distressingly slow. For example, when you want to transfer a Swing application, you could let your application directly paint into an image. Roughly with a pattern like
BufferedImage image = new BufferedImage(w,h,type);
Graphics g = image.getGraphics();
myMainFrame.paint(g);
g.dispose();
(This is only a sketch, to show the basic idea!)
Additionally, you could consider further options for increasing the "percieved speed" of such an image transfer. For example, you could divide your image into tiles, and transfer these tiles one after another. The receiver will possibly appreciate it if the image would at least be partially visible as quickly as possible. This idea could be extended further. For example, by detecting which tiles have really changed between two frames, and only transfer these changed tiles. (This approach could be extended and implemented in a rather sophisticated way, by detecting the "minimum regions" that have to be transferred)
However, for the case that you first want to play around with the most obvious tuning parameter: Here is a method that allows writing a JPG image with a quality value between 0.0 and 1.0 into an output stream:
public static void writeJPG(
BufferedImage bufferedImage,
OutputStream outputStream,
float quality) throws IOException
{
Iterator<ImageWriter> iterator =
ImageIO.getImageWritersByFormatName("jpg");
ImageWriter imageWriter = iterator.next();
ImageWriteParam imageWriteParam = imageWriter.getDefaultWriteParam();
imageWriteParam.setCompressionMode(ImageWriteParam.MODE_EXPLICIT);
imageWriteParam.setCompressionQuality(quality);
ImageOutputStream imageOutputStream =
new MemoryCacheImageOutputStream(outputStream);
imageWriter.setOutput(imageOutputStream);
IIOImage iioimage = new IIOImage(bufferedImage, null, null);
imageWriter.write(null, iioimage, imageWriteParam);
imageOutputStream.flush();
}

Java JPG To Png

I am using a common format all over application for images as png.Any jpg image uploaded still gets saved as png using code as below.
java.awt.image.BufferedImage bufferedImage = ImageIO.read(jpgImagePAth);
if(!IsExtensionPng(jpgImagePath)){
ImageIO.write(bufferedImage, "png", new File(pptFolder, justNamePng));
}
But this preserves alpha even though it was not there in the jpg so makes a 2MB Image 7MB and 6MB to 16MB . Is there anyway to save png without maintaining the alpha ?
The reason I need to conver to PNG is that later on when I add text on image it looses the actual resolution. I already tried loseless JPEG which didnt fix it.

It's not the alpha channel that is causing the file size to grow, it's the file type. JPG uses lossy compression; PNG is lossless compression. In other words, JPG is throwing out some data to reduce the size of the file. That's why you get to choose a "quality" level when saving to JPG - that determines how much is thrown out.
How do you know you're getting the alpha channel anyway? If you still want PNG and want to be sure you're dropping the alpha channel, set the image type to BufferedImage.TYPE_RGB, e.g.
BufferedImage bi = new BufferedImage(width, height, BufferedImage.TYPE_BYTE_RGB);
You'll have to get the graphics object associated with your new BufferedImage and copy the jpg onto it, then write it out. This question isn't quite the same as yours but has sample code you may find useful.
Paul

I don't know exactly in what situation you are. But I should keep JPEG JPEG. The only advantage of converting JPEG to PNG is wasting hdd space.

Crop Bitmap without reading entire Bitmap first

I have a very large image and I only want to display a section the size of the display (no scaling), and the section should just be the center of the image. Because the image is very large I cannot read the entire image into memory and then crop it. This is what I have so far but it will give OutOfMemory for large images. Also I don't think inSampleSize applies because I want to crop the image, not lower the resolution.
Uri data = getIntent().getData();
InputStream is = getContentResolver().openInputStream(data);
Bitmap bitmap = BitmapFactory.decodeStream(is, null, null);
Any help would be great?

You can do this in 2 steps:
get the size of the bitmap, by using inJustDecodeBounds=true .
use BitmapRegionDecoder to decode just the part you want to .
The downside ? it works only from API 10 (but it's already the majority...).

I agree that the easiest way is to break the image up into many smaller tiled images and to just load the appropriate ones to make the image you are after.
However, if you do not want to do that, you may be forced to look into the encoding of the jpeg itself.
What you could do is something along the lines of copying the header from the file into a new file, and then extracting just the pixels you want in order to create a new file. Then reloading the new file will allow you to have just the subset of the image you are looking to work with, and all the regular java functionality and classes will be equally available for you to use.
I know it isn't necessarily an elegant or simple solution, however it does guarantee that you will be able to use the original java functionality which you expect to be able to use.

I think you're approaching the problem from the wrong direction.
If the bitmap is already so large it can't be loaded as a single continuous image, why store it as a single image? Slice it into tiles then load the center tile/tiles and act upon those.