0

I have a webapp running on Java 6 in Tomcat 6. ImageIO.read is returning null.

It attempts to retrieve tiff images from a computer on the same [Windows] network. To do this, I use JCIFS as auth, and jai to read the images.

In QA, this works, I retrieve and display the TIFs. In production, it does not.

I am able to access the images and it correctly retrieves the file paths.

Here is the error from the log:

2013-11-18 11:06:47,405 [webapp] INFO  [http-8080-6] 
ScannedService.getScannedDocuments(66) | Customer.java 
get files at Paths[smb://sharedDrived/path/1HK01001.TIF]

2013-11-18 11:06:47,421 [webapp] INFO  [http-8080-6] 
ScannedDocument.<init>(32) | ScannedDocument.java 
constructor, image value: null

The null is what is returned by:

ImageIO.read(smbStream);

Why that line is returning null?

Eric Leschinski
  • 146,994
  • 96
  • 417
  • 335
Gavin Fitzgerald
  • 396
  • 1
  • 4
  • 14
  • You probably have a faulty installation of jai-imageio, if you know the file is a valid TIFF file and `ImageIO.read(...)` returns `null`. Can you dump the contents of the file, and read it from other software, or look at it in a hex editor, to determine if it is valid? – Harald K Nov 18 '13 at 16:30
  • In QA, the application shows the small sample of TIFFs fine. In Production we can open any of the large number of tiffs in windows photo viewer etc. I'm looking at TIFF validators right now, JHOVE seems to open the QA files fine anyway, but not the most inuitive of tools. Trying LibTiff.Net now. – Gavin Fitzgerald Nov 18 '13 at 17:46

1 Answers1

1

The reason ImageIO.read returns null, is that no ImageReader plugin claims to be able to read it (otherwise, unless input is null, a read is attempted using the first plugin that claims it can read the input, and you either get an image or an exception is thrown).

This can be caused by two things. Either there is no plugins installed (discovered by ImageIO). Or the input is corrupted so that it's not recognized. You seem to have done enough debugging/testing to determine that the latter is not the issue here. So I still think the problem is with the installation of jai-imageio, or possibly that the JAI plugins are not discovered by ImageIO.

You can try (either in your application's start-up, or every time you get a null image) to print all the formats supported by ImageIO (using ImageIO.getReaderFormatNames()) to the debug log, and see if TIFF is listed.

Note that if you provide the jai-imageio JARs as part of your web application (in WEB-INF/lib), the plugins are not automatically discovered after a re-deploy, unless you do ImageIO.scanForPlugins(). In that case, I suggest you read Deploying the plugins in a web app.

Eric Leschinski
  • 146,994
  • 96
  • 417
  • 335
Harald K
  • 26,314
  • 7
  • 65
  • 111
  • Firstly, thank you. In my dev environment `ImageIO.getReaderFormatNames()` returns the same list before and after the scan operation. It includes TIF and its variations in the 26/28 formats, depending on the JAI library. I've moved from net.java.dev.jai-imageio to geotk-coverageio, but am kind of stuck without a way of replicating the problem in DEV or QA, because both libraries work with the three sample images. – Gavin Fitzgerald Nov 19 '13 at 10:11
  • @GavinFitzgerald I was more interested in getting the debug logging from the prod environment, as that would tell you something about the state of the installation and help replicating it. I don't think there's anything wrong with the libraries in general, nor the images. – Harald K Nov 19 '13 at 11:43
  • Between changing the ImageIO library to geotk and running 'ImageIO.scanForPlugins()' the problem is solved! Thank you for your suggestions @haraldK. I'd be happier if we had a correct environment in which the issue was replicatable, because I'm afraid of more got'chas when it comes to working with this legacy data and content, but still, happy to have this problem hounding me no longer. – Gavin Fitzgerald Nov 20 '13 at 09:05