Невозможно прочитать изображения в формате tiff с сетевого ПК с Windows, используя JCIFS и jai imageio

У меня есть веб-приложение, работающее на Java 6 в Tomcat 6. ImageIO.read возвращает значение null.

Он пытается получить изображения в формате TIFF с компьютера в той же сети [Windows]. Для этого я использую JCIFS в качестве авторизации и jai для чтения изображений.

В QA это работает, я извлекаю и отображаю TIF. В производстве его нет.

Я могу получить доступ к изображениям, и он правильно извлекает пути к файлам.

Вот ошибка из лога:

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

Нуль - это то, что возвращается:

ImageIO.read(smbStream);

Почему эта строка возвращает ноль?


person Gavin Fitzgerald    schedule 18.11.2013    source источник
comment
Вероятно, у вас возникла ошибка при установке jai-imageio, если вы знаете, что файл является допустимым файлом TIFF и ImageIO.read(...) возвращает null. Можете ли вы сбросить содержимое файла и прочитать его из другого программного обеспечения или просмотреть его в шестнадцатеричном редакторе, чтобы определить, является ли оно действительным?   -  person Harald K    schedule 18.11.2013
comment
В QA приложение отлично показывает небольшую выборку TIFF. В производстве мы можем открыть любой из большого количества tiff-файлов в средстве просмотра фотографий Windows и т. Д. Я сейчас смотрю на валидаторы TIFF, JHOVE, похоже, в любом случае отлично открывает файлы QA, но не самый интуитивный из инструментов. Попробуйте LibTiff.Net сейчас.   -  person Gavin Fitzgerald    schedule 18.11.2013


Ответы (1)


Причина, по которой ImageIO.read возвращает null, заключается в том, что ни один плагин ImageReader не утверждает, что может его прочитать (в противном случае, если ввод не является null, попытка чтения выполняется с использованием первого плагина, который утверждает, что может прочитать ввод, и вы либо получаете изображение, либо выбрасывается исключение).

Это может быть вызвано двумя вещами. Либо плагины не установлены (обнаружено ImageIO). Или ввод поврежден так, что он не распознается. Похоже, вы провели достаточно отладки/тестирования, чтобы определить, что последнее здесь не проблема. Поэтому я все еще думаю, что проблема связана с установкой jai-imageio или, возможно, с тем, что плагины JAI не обнаруживаются ImageIO.

Вы можете попробовать (либо при запуске вашего приложения, либо каждый раз, когда вы получаете изображение null) распечатать все форматы, поддерживаемые ImageIO (используя ImageIO.getReaderFormatNames()), в журнал отладки и посмотреть, есть ли в списке TIFF.

Обратите внимание, что если вы предоставляете JAR-файлы jai-imageio как часть своего веб-приложения (в WEB-INF/lib), плагины не обнаруживаются автоматически после повторного развертывания, если только вы не сделаете ImageIO.scanForPlugins(). В этом случае я предлагаю вам прочитать Развертывание плагинов в веб-приложение.

person Harald K    schedule 19.11.2013
comment
Во-первых, спасибо. В моей среде разработки ImageIO.getReaderFormatNames() возвращает один и тот же список до и после операции сканирования. Он включает в себя TIF и его варианты в форматах 26/28, в зависимости от библиотеки JAI. Я перешел с net.java.dev.jai-imageio на geotk-coverageio, но не могу воспроизвести проблему в DEV или QA, потому что обе библиотеки работают с тремя примерами изображений. - person Gavin Fitzgerald; 19.11.2013
comment
@GavinFitzgerald Меня больше интересовало получение журнала отладки из среды prod, так как это могло бы рассказать вам кое-что о состоянии установки и помочь его воспроизвести. Я не думаю, что что-то не так ни с библиотеками, ни с изображениями. - person Harald K; 19.11.2013
comment
Между заменой библиотеки ImageIO на geotk и запуском ImageIO.scanForPlugins() проблема решена! Спасибо за ваши предложения @haraldK. Я был бы счастлив, если бы у нас была правильная среда, в которой проблема была бы воспроизведена, потому что я боюсь большего количества ошибок, когда дело доходит до работы с этими устаревшими данными и контентом, но все же я рад, что эта проблема преследует меня. больше никогда. - person Gavin Fitzgerald; 20.11.2013