it seems my texture loader doesnt work anymore when run in a 64bit environment. im not sure if the cause is the 64bit VM itself or if the file lying on a 64bit filesystem.
the image to load is a RGBA png file, it shows up correctly on 32bit windows systems, but on my 64bit win7 some color channels seem flipped.
here is my code:
InputStream is = Thread.currentThread().getContextClassLoader()
.getResourceAsStream(path);
BufferedImage bi = ImageIO.read(is);
is.close();
byte[] databytes = ((DataBufferByte) bi.getRaster().getDataBuffer()).getData();
ByteBuffer data = ByteBuffer.allocateDirect(databytes.length);
data.order(ByteOrder.nativeOrder());
data.put(databytes, 0, databytes.length);
data.rewind();
IntBuffer texb = IntBuffer.allocate(1);
binding.genTextures(1, texb);
binding.bindTexture(binding.TEXTURE_2D(), texb.get(0));
binding.texParameter(binding.TEXTURE_2D(), binding.TEXTURE_MIN_FILTER(),
binding.LINEAR());
binding.texParameter(binding.TEXTURE_2D(), binding.TEXTURE_MAG_FILTER(),
binding.LINEAR());
binding.texParameter(binding.TEXTURE_2D(), binding.TEXTURE_WRAP_S(),
binding.CLAMP());
binding.texParameter(binding.TEXTURE_2D(), binding.TEXTURE_WRAP_T(),
binding.CLAMP());
binding.texEnvi(binding.TEXTURE_ENV(), binding.TEXTURE_ENV_MODE(),
binding.MODULATE());
binding.texImage2D(binding.TEXTURE_2D(), 0, binding.RGBA(), bi.getWidth(),
bi.getHeight(), 0, binding.RGBA(), binding.UNSIGNED_BYTE(), data);
does anyone know what could be wrong? thanks!
actually it turned out a problem with the latest update java6 u18 which contained some changes to bufferedimage and had nothing to do with 64bit VMs
Related
I'm trying to get base64 code from an image. There is no problem with the base64 image in Windows 10, but in Linux the image changes. Here is my code;
BufferedImage img = ImageIO.read(file);
BufferedImage image = new BufferedImage(img.getWidth(), img.getHeight(), BufferedImage.TYPE_INT_RGB);
image.createGraphics().drawImage(img, 0, 0, Color.WHITE, null);
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ImageIO.write(image, "jpeg", baos);
encodedFile = new String(Base64.getEncoder().withoutPadding().encode(baos.toByteArray()), "UTF-8");
On different operating systems, byteArray has different results.
If the java has a large image (like 1920x1080) on the Linux operating system, the image changes (some pixels shift and some pixels appear to have a yellow filter). Oddly enough it works fine in small image (602x339). I use java 8.
One of the wrong converted image
I want to change jpeg image density from 96 to 100 dpi and bit depth should be 8 bit.
I'm using below code.
BufferedImage bufferedImage = new BufferedImage(width, height, BufferedImage.TYPE_BYTE_GRAY);
JPEGImageEncoder jpegEncoder = JPEGCodec.createJPEGEncoder(os1);
JPEGEncodeParam jpegEncodeParam = jpegEncoder.getDefaultJPEGEncodeParam(bufferedImage);
jpegEncodeParam.setDensityUnit(JPEGEncodeParam.DENSITY_UNIT_DOTS_INCH);
jpegEncoder.setJPEGEncodeParam(jpegEncodeParam);
jpegEncodeParam.setQuality(0.40f, true);
jpegEncodeParam.setXDensity(100);
jpegEncodeParam.setYDensity(100);
jpegEncoder.encode(bufferedImage, jpegEncodeParam);
bufferedImage.flush();
It's working fine but in this code Java API showing warning message that is Access restriction: The type 'JPEGImageEncoder' is not API (restriction on required library ...). and Maven build also by this.
Also tried ImageIO library but It only helps in bit depth and not able to change dpi.
I am trying to use a BitmapRegionDecoder to load parts of a large Bitmap image in Android but am stuck because the BMP file format is not supported(only JPG and PNG).
Is is possible to "transcode" a bitmap image into JPG or PNG (compression doesn't really matter) without loading the entire image into memory?
Something like
FileOutputStream fos = new FileOutputStream(pngFile);
byte[] buffer = new byte[1024];
int bytesRead;
while ((bytesRead = bmpInputStream.read(buffer)) > 0) {
// Process bytes to PNG format
fos.write(buffer, 0, bytesRead);
}
Managed to do it using this PNGJ library , written in pure Java so usable in android, and which allows to write PNG files line by line without loading the whole image into memory.
I'm a beginner in Java and a geomatics student.
I'am using IntelliJ.
I would like to create a TIFF from a BufferedImage.
This is my code :
byte[] buffer = new byte[width * height];
ColorSpace cs = ColorSpace.getInstance( ColorSpace.CS_GRAY );
int[] nBits = { 8 };
ColorModel cm = new ComponentColorModel( cs, nBits, false, true,Transparency.OPAQUE, DataBuffer.TYPE_BYTE );
SampleModel sm = cm.createCompatibleSampleModel( width, height );
DataBufferByte db = new DataBufferByte( buffer, width * height );
WritableRaster raster = Raster.createWritableRaster( sm, db, null);
BufferedImage result = new BufferedImage( cm, raster, false , null );
File outputfile = new File( "saved.png" );
ImageIO.write( result, "png", outputfile );
A raster .png is create and it works well. But I want to create a .TIFF and ImageIO.write don't create TIFF (only png,bmp and jpeg). So I download the JAI (Java Advanced Imaging) here : http://download.java.net/media/jai/builds/release/1_1_3/
I upload it on my project and on Maven, but I don't know how to make a tiff simply... I try some snippets that I found on the internet but it don't work..
TIFFEncodeParam params = new TIFFEncodeParam();
FileOutputStream os = new FileOutputStream("PingsTiff.tiff");
javax.media.jai.JAI.create("encode", result, os, "TIFF", params);
The "TIFFEncodeParam" and "media" is not recognized...and I'm a real noob at programming..
Thanks
First of all, JAI comes with a set of ImageIO plugins, that will allow you to use ImageIO.write to write in TIFF format. But it requires the jai_imageio.jar to be on class path. I guess this is the JAR you are missing.
Also, the code you posted should work, if you have the imports and dependencies set up correctly. It's a little tricky because some parts of JAI requires native libraries that needs to be installed using the installer, and in the correct JRE, etc. Because of this, it's not a perfect fit with Maven (although certainly doable).
However, as you see from the download link in your question, JAI is a pretty much dead project (the latest update is from 2006).
Because of this lack of updates, bug fixes and support, along with the native parts and the license issues, I set up an open source project, aimed to provide at least as good file format support as JAI, with no native requirements and released under BSD license.
You can read about it, and the TIFF plugin in particular at the project home page. A little further down the page is down is download links, Maven dependency information etc.
When you have declared dependency on the TIFF plugin, you should be able to write your TIFF using plain ImageIO like this:
File outputfile = new File("saved.tif");
if (!ImageIO.write(result, "TIFF", outputfile)) {
// Beware, write is a boolean method, that returns success!
System.err.println("Could not write " + outputfile.getAbsolutePath() + " in TIFF format.");
}
I have the following java code, which writes an image to a byte array then back into an image:
BufferedImage bi = ImageIO.read(new File("1.png"));
ByteArrayOutputStream baos = new ByteArrayOutputStream();
ImageIO.write(bi,"png",baos);
byte[] img = baos.toByteArray();
ByteArrayInputStream bais = new ByteArrayInputStream(img);
BufferedImage bif = ImageIO.read(bais);
On OS X, this works perfectly fine, but on Ubuntu, bif (the final image) becomes null at the end, meaning there is a problem reading from the ByteArrayInputStream. I'm using the oracle jdk in both cases and don't know what's going on.
Edit: More evidence that I'm going insane: I printed the img byte array to a file using a FileOutputStream on Ubuntu and OSX, then diffed the two files, and they are exactly the same. This means either the ByteArrayInputStream is different or (more likely) the second ImageIO.read isn't working for some reason.
Ubuntu server is usually running in headless mode which can cause problems with java image manipulation.
http://www.oracle.com/technetwork/articles/javase/headless-136834.html
Try tweaking your jvm start-up settings to allow running headless and it should fix it.