We Keep Coding

Should I convert BufferedImage.TYPE_4BYTE_ABGR to BufferedImage.TYPE_3BYTE_BGR?

I am working on image interpolation for which I am using bi-cubic interpolation to double the resolution of image in java using AffinedTransformOp.I used BufferedImage of TYPE_4BYTE_ABGR while doing up-scaling. When I tried to save back my upscale image using ImageIO.write then I found that openjdk does not support jpeg encoding for TYPE_4BYTE_ABGR so I converted this up-scaled image from TYPE_4BYTE_ABGR to TYPE_3BYTE_BGR. When I saved it in folder then found that the memory taken by this upscale image is way less(about half time) than the memory taken by original image.
So I assume that the original(input) image is represented by four channels ARGB while upscale(output) image is taking 3 channels RGB and that's why getting less memory.
Now my question is that should I use this conversion?
Is there some information that is getting lost?
Does quality of image remains same?
P.S: I've read from the documentation of ImageIO that when we convert ARGB to RGB than the alpha value gets premultiplied to RGB values and I think it should not affect the quality of the image.

I solved my problem and hope to share my answer. Actually the type of my original image was Grayscale and the color space of my original image was grey (meaning only one channel with 8 bits) with quality of 90.Problem arised when I used TYPE_4BYTE_ABGR for the upscaling instead of using TYPE_BYTE_GRAY. Secondly when you try to save this image in a file in jpeg format ImageIO.write uses compression of 75 by default so the image size will get small. You should use the compression factor which suits you or you should save it in PNG format. You can view information about your image by using identify -verbos image.jpg in linux and can see the color space, image type and quality etcYou can check this post to see how to set your compression quality manually in ImageIO.

Java ImageIO Grayscale PNG Issue

I have a grayscale image ("lena" actually) which I want to experiment with. I got it as a 512x512 PNG file with 216 shades of gray.
What happens is, when I read it with Java ImageIO, like that:
String name = args[0];
File fi = new File(name);
BufferedImage img = ImageIO.read(fi);
I get a BufferedImage with only 154 colours! I only realized this, cause my processed images which looked sallow, lacking deep black.
Even more irritating, when I use XnView convert the PNG to a GIF, which is a lossless procedure in this case, read the GIF with above code, I get all 216 colours in my BufferedImage.
Is there some kind of documentation or description, what happens to my PNG, when ImageIO reads it? Are there settings to fix that? I did these experiments on a fairly recent JDK1.8. It is just that my trust in Java PNG support is lost now and I will use coloured PNG later.

Welcome to Java's "great" world of implicit color management!
For Java (at least ImageIO) everything internally is sRGB and it implicitely does color management, which often is quite counter-productive for what one actually wants to do.
For gray scale images, at least using ImageIO with most readers and at least for gray scale images without an embedded ICC profile (I haven't tested others yet), Java automatically "assigns" an ICC profile with WhitePoint=D50, Gamma=1.0. I stumbled across this as well.
And then, when you access pixels (I assume you use img.getRGB() or something similar?), you actually access sRGB values (Java's default color space on Windows).
The result is, when converting to sRGB, which has a gamma of ~2.2 (sRGB's gamma is actually a bit more complicated, but close to 2.2 overall), this affectively applies a gamma correction with (1/Gamma)=2.2 to the image, (a) making your image appear "light", and (b) due to the gamma correction from 256 to 256 discrete values, you also effectively loose some of your shades of gray.
You also can see the effect if you access your BufferedImage's data in different ways:
a) access the profile:
ColorSpace colorSpace = img.getColorModel().getColorSpace();
if ( colorSpace instanceof ICC_ColorSpace ) {
ICC_Profile profile = ((ICC_ColorSpace)colorSpace).getProfile();
if ( profile instanceof ICC_ProfileGray ) {
float gamma = ((ICC_ProfileGray)profile).getGamma();
system.out.println("Gray Profile Gamma: "+gamma); // 1.0 !
}
}
b) access some pixel values in different ways ...
//access sRGB values (Colors translated from img's ICC profile to sRGB)
System.out.println( "pixel 0,0 value (sRGB): " + Integer.toHexString(img.getRGB(0,0)) ); // getRGB() actually means "getSRGB()"
//access raw raster data, this will give you the uncorrected gray value
//as it is in the image file
Raster raster = image.getRaster();
System.out.println( "pixel 0,0 value (RAW gray value): " + Integer.toHexString(raster.getSample(0,0,0)) );
If your pixel (0,0) is not by chance 100% black or 100% white, you will see that the sRGB value is "higher" than the gray value, for example gray = d1 -> sRGB = ffeaeaea (alpha, Red, Green, Blue).
From my point of view, it does not only reduce your gray levels, but also makes your image lighter (about the same as applying gamma correction with 1/gamma value of 2.2). It would be more logical if Java for gray images without embedded ICC Profile either translates gray to sRGB with R=G=B=grayValue or would assign an ICC Gray Profile WhitePoint=D50, Gamma=2.2 (at least on Windows). The latter still would make you loose a couple of gray tones due to sRGB not being exactly Gamma 2.2.
Regarding why it works with GIF: the GIF format has no concept of "gray scales" or ICC profiles, so your image is a 256 color palette image (the 256 colors happen to be 256 shades of gray). On opening a GIF, Java assumes the RGB values are sRGB.
Solution:
Depending on what your actual use case is, the solution for you might be that you access the Raster data of each of your image's pixel (gray=raster.getSample(x,y,0)) and put it into an sRGB image setting R=G=B=gray. There might be an more elegant way, though.
Regarding your trust in java or PNG:
I'm struggling with java ImageIO in many ways due to the implicite color conversions it does. The idea is to have color management built in without the developers need much knowledge about color management. This works to some extend as long as you work with sRGB only (and your input is sRGB, too, or has no color profile and thus could legitimately considered to be sRGB). Trouble starts if you have other color spaces in your input images (for example AdobeRGB). Gray is another thing as well, especially the fact that ImageIO assumes an (unusual) Gray Profile with Gamma=1.0. Now to understand what ImageIO is doing, you don't only need to know your ABC in color management, but also need to figure out what java is doing. I didn't find this info in any documentation! Bottom line: ImageIO does things that certainly could be considered correct. It's just often not what you expect and you might to dig deeper to find out why or to change the behaviour if it isn't what you want to do.

Somehow you have converted the image from a linear grayscale (gamma=1.0) to an sRGB grayscale (gamma=1/2.2). This can be demonstrated with GraphicsMagick. Start with Lenna.png downloaded from Wikipedia, then remove the sRGB chunk to create lena.png, then
gm convert lena.png -colorspace gray -depth 8 -strip lena-gray.png
lena-gray.png has 216 colors
gm convert lena-gray.png -gamma 2.2 -depth 8 -strip lena-gray-gm22.png
lena-gray-gm22.png has 154 colors and appears washed-out or faded.
I'm using a recent beta of graphicsmagick (version 1.4) with libpng-1.6.17.
To count the colors I used ImageMagick:
identify -verbose file.png | grep Colors
I used
pngcheck -v file.png
to verify that Lenna.png contains IHDR, sRGB, IDAT, and IEND chunks, while lena-gray.png and lena-gray-gm22.png contain only IHDR, IDAT, and IEND chunks.

Java: How to work with CMYK image?

I know that RGB is for monitors and CMYK is for printing, but I want to work with CMYK without any conversions. I want to upload a CMYK image (jpeg) and print it. But when I used
com.sun.image.codec.jpeg.JPEGImageDecoder decoder = JPEGCodec.createJPEGDecoder(is);
return decoder.decodeAsBufferedImage();
I got an inversed colors image. How can I get the same image in CMYK?

There reason your colors are inverted is that you have a special variant of a CMYK JPEG image, namely Adobe CYYK. The strange colors are due to an old Photoshop bug (CMYK values are inverted) that has now become a de-facto standard that's handled by most JPEG software (except Java).
A proper CMYK conversion (handling different variants, using proper color profile etc.) can be found in: https://stackoverflow.com/a/12132630/413337.

Java: Taking a Image and turning it into Black in White with RGB

So I am doing a group project for my programming class, we are makeing a photo editing program and one of my parts of the program is taking the image and turning it into black and white using rgb. I was wondering what would be the best value or way in RGB to achieve black and white?

I would recommend letting the Java 2D library worry about the conversion:
create a greyscale BufferedImage (BufferedImage.TYPE_BYTE_GRAY);
get a graphics context by createGraphics()
ensure that colour rendering is accurate on that graphics context: call setRenderingHint(RenderingHints.KEY_COLOR_RENDERING, RenderingHints.VALUE_COLOR_RENDER_QUALITY)
draw the colour image you want to "convert" to the graphics context
If you do the conversion "manually" and you want to do it as accurately as possible, then you need to take into account that the eye is more sensitive to certain colour components than others. (If you want a "rough and ready" conversion, you can average the colour components, but this isn't strictly speaking the most accurate conversion.)

For each pixel, you can convert the RGB to HSB (using Color.RGBtoHSB), set the saturation to 0, and convert back to a Color instance using Color.getHSBColor.

Wikipedia actually has a good piece about how to perform the transformation once you have the RGB colors.

Hey , this page has many Java Image filters which are freely available for download.All filters are standard Java BufferedImageOps and can be plugged directly into existing programs.The GrayscaleFilter can convert the image to black and white

Using java.awt.image.ColorConvertOp with a gray destination ColorSpace is very efficient. There's an excellent example here.

An easy way (tool?) to compare images pixel for pixel in different formats?

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.