Как Java загружает собственные NSImages?

Question

Я читал инструменты для разработчиков OS X Java, чтобы помочь сделать мое приложение более «родным» с операционной системой. Я нашел что-то интересное в этом section. (Курсив мой)

Чтобы загрузить разрешение независимого TIFF, ICNS, или в формате PDF файла из папки ресурсов вашего пакета приложения в приложение Java, используйте getImage() метод java.awt.Toolkit. Строка, которую вы передаете в getImage(), имеет форму "NSImage://MyImage". Не включайте расширение файла изображения. Также имейте в виду, что 2D-рендер Sun отключен, когда коэффициент масштабирования пользовательского интерфейса не имеет значения 1.0. Используйте инструмент Quartz renderer, чтобы ваши изображения масштабировались плавно.

Будучи знакомым с javax.imageio, это является полной неожиданностью, поскольку я не знал другого способа загрузить другие типы файлов в изображения. Особенно с устаревшей платформой и абсолютно никакой поддержкой для файлов, таких как .tiff. Например, быстрый тест на моем компьютере дает мне это:

Supported read formats: [jpg, bmp, gif, png, wbmp, jpeg] 
Supported write formats: [jpg, bmp, gif, png, wbmp, jpeg] 
'JPEG' reader: com.sun.imageio.plugins.jpeg.JPEGImageReader@5e9f23b4 
'JPEG' reader: com.sun.imageio.plugins.jpeg.JPEGImageWriter@378fd1ac 

Я попытался загружая простой .tiff изображение и испытания это:

 
static Image n; 

public static void main(String[] args) { 
    JFrame f = new JFrame(); 
    JPanel p = new JPanel() { 
     @Override 
     public void paintComponent(Graphics graphics) { 
      graphics.drawImage(n, 0, 0, null); 
     } 
    } 
    f.add(p); 
    n = Toolkit.getDefaultToolkit().getImage(("/Users/zinedine/Desktop/test_image.tiff"); 
    f.setVisible(true) 
} 

Это дает ничего:

Я попробовал еще раз: на этот раз добавив изображение в базовую папку моего проекта java и набрав его как строку: "NSImage://test_image.tiff". Как и все, что я делаю, это не работает.

Однако, если я изменить свою причудливую строку пути к NSImage один, таких как "NSImage://NSApplicationIcon" ...

Он работает. Я быстро просмотрел поиск NSImage и нашел его. Похоже, тип файла для этих изображений: .png. Это отвратительно, так как я ожидал, что из него выйдет правильный образ. Имейте в виду, я тоже ожидал этого: если он ожидает аргументы формы "NSImage://something", тогда он может просто игнорировать что-либо еще.

Очевидно, что у меня есть несколько вопросов:

• Каким Toolkit загрузить изображение? Если я пытаюсь загрузить .tiff изображение с моего рабочего стола, это то, что я получу, если я называю .toString():

  sun.awt.image.ToolkitImage@25f38edc // Also can't be cast to java.awt.BufferedImage 
  

• ли читатели (и авторы, если таковые имеются) часть общественного API? Другими словами, я могу назвать что-то, чтобы загрузить мой .tiff файл в Image (который я могу затем бросить в `BufferedImage?

• А потом снова, если читатели/писатели являются частью API, почему Безразлично» t пакет javax.imageio найти их?

Это может выглядеть, как горсть, (да, я прошу прощения за губит свой день по этому вопросу), но мне, это выглядит, как и следовало ожидать, но в то же время ошибочного поведения. Бонусные отметки: Есть ли дружественные (например, Open Source) изображения api (не JAI), которые могут обрабатывать файлы .tiff (и другие)?

Answer 1

Здесь вы задаете несколько вопросов, но я сделаю все возможное, чтобы все это интерпретировать. :-)

Использование Toolkit для загрузки изображений (java.awt.Image и друзей) является частью «старого» асинхронного API-интерфейса для создания изображений/изображений для потребителей и может показаться немного неудобным для работы. Это абсолютно нормально для загрузки упакованных значков и аналогичных, но менее подходящих для загрузки больших изображений, предоставленных пользователем, поскольку у вас нет отслеживания хода, небольшая обратная связь с ошибками, если что-то пойдет не так и т. Д.

Эти изображения также намного меньше полезный, чем BufferedImage, если вы хотите выполнять любые манипуляции с изображениями. Вы не можете отдать их на BufferedImage, но вы можете «преобразовать» их, нарисуя их на BufferedImage.

Класс Toolkit является абстрактным, и вы получаете конкретный пример с использованием Toolkit.getToolkit(). Этот конкретный экземпляр является специфичным для платформы и заканчивается использованием системных вызовов для большинства методов, таких как загрузка изображений.

Реализация Apple Java имеет некоторые дополнительные функции, например, позволяет загружать изображения системы Apple с использованием специальной схемы URI. Похоже, что он также может загружать связанные изображения таким образом, используя соглашение об именах @2x и даже многомасштабные TIFF или масштабируемые PDF-файлы в OS X для независимой от разрешения графики для вашего приложения.

Обратите внимание, что для этого вам необходимо упаковать приложение в виде пакета приложений и поместить изображения в папку «Ресурсы» (то есть Contents/Resources) пакета. И вы должны ссылаться на изображения, используя его базовое имя, без расширения. Насколько я знаю, вы не можете использовать эту функцию для чтения случайных файлов TIFF, не упакованных с вашим приложением (то есть с предоставленным пользователем контентом).

Кроме того, эта функция специфичны для Apple, JRE, и будет работать только на собственном JRE Apple, и на OS X. Это не является частью общественного Java API, и он не будет работать кросс-платформенный. Я рекомендую использовать функциональность экономно и только для лучшей интеграции системы (т. Е. Сделать ваше приложение более родным) в OS X.

Чтобы прочитать (и написать) любой TIFF (или любой другой формат для этого) , вы должны использовать ImageIO и некоторые правильные плагины. По какой-то причине JRE не поставляется с плагинами для формата TIFF, но существует несколько сторонних плагинов.

Если вы не хотите использовать JAI (через jai_imageio.jar), я могу порекомендовать свои собственные TwelveMonkeys library which supports TIFF наряду с несколькими другими форматами. Он использует деловую лицензию BSD с открытым исходным кодом.

Есть также Apache Commons Imaging, iCafe и, возможно, другие, которые могут читать/писать TIFF, но у них есть свои собственные API-интерфейсы, которые делают их менее гибкими и более проприетарными IMO.