Снова трудо-выебудни

Повозившись сначала с libpng (формат простой и если следовать заложенным там идеям, то как бы и ничего так), а затем в libtiff (формат, как мы знаем, весьма развесистый)....

Я начинаю понимать популярность всяких OpenImageIO, FreeImage, ну на худой конец стандартных кодеков типа Qt-шных (говоришь ему read("file.png") оно само разберется что и куда).

Потому что та же libtiff - это, на самом деле, тихий ужас:

  • Есть TIFFReadRGBAImageOriented, которая может многое (Grayscale, RGB, Lab, CMYK - все вернет в виде RGBA). Правда с Lab/CMYK оно делает это как-то криво...., а какие-нибудь 12-битные RGB или 16-bit FP вовсе не умеет.
    Правда интерфейс там такой, что если исходный TIFF повернут на 90 градусов, результат TIFFReadRGBAImageOriented вас сначала огорчит, а потом (когда поймете отчего он такой) позабавит.
  • Поэтому есть TIFFReadSсanline - и можно читать по строчкам.
    Правда бывают TIFF-файлы, где строчек нет, а есть тайлы
  • Поэтому есть TIFFReadTile и можно читать тайлы.... ну уже криво, тайлу надо давать буфер под тайл, поместить его прямо в выходной растр нельзя, придется копировать.
    Правда бывают файлы, где цветовые компоненты записаны отдельно....
    Правда бывают файлы с тегом TIFFTAG_IMAGEDEPTH (про который я вообще не нашел ничего вменяемого за две минуты - и успокоился)

И вот не знать бы этих всех подробностей бы.....

И это как бы не говоря о том, что для striped/tiled tiffs конечно бы декодировать их многопоточно бы (чего libtiff не умеет).

Ну то есть мы тут все привыкли, что в RAW - бардак, ну OK. Но, э, если смотреть на "индустриальный стандарт" (TIFF и libtiff как имплементацию) - ну тоже невозможно сказать что все хорошо, ну то есть для чтения FP16-tiled-RGB tiff придется самому написать большую гору кода.

Comments

libtiff это же, по сути, парсер… А ты хочешь полной интерпретации :-)

Для меня загадка отчего есть частично работающий TIFFReadRGBAImage
Но нету всегда работающего TIFFReadImage (который бы собрал тайлы в буфер, например, но не интерпретировал бы)

[разводит руками]
Мне тоже это кажется нелогичным. Ладно, недоделан верхний слой - но нет среднего!

А глобально я вот еще не понимаю: вот на дворе 2019-й год. Даже в сраном телефоне 4-ядерный процессор.
TIFFы - все (*) либо striped, либо tiled.
Где, сука, многопоточный распаковщик?

(*) на самом деле не все, но вот libtiff по-умолчанию пишет striped, т.е. подавляющее большинство.

у libtiff вообще всё хорошо, я смотрю
указано
Master Download Site: ftp.remotesensing.org , directory pub/libtiff
даже хост не резолвится

Ну если поискать, удается найти куда они переехали.

То что гугл показывает старый домик - это проблема скорее гугла, чем libtiff

Но вообще, это все беда, конечно.

Для таких основополагающих штук - должен ну вот хоть Apache Foundation прибегать, ну либо кто-то подобный (IBM, Redhat), потому что вообще опенсорц имеет тенденцию к диссипации.

я тут случайно столкнулся с netbeans, его как-то сильно покорежило в процессе переезда на Apache Foundation - отвалились целые куски, потерялся установщик и всё в таком духе. и это после выхода двух мажорных версий.

Поди то, что с неподходящей лицензией - отпало?

Установщик там был довольно ужасненький, самописная такая рукопашная попытка сделать коммерчески-выглядящее кроссплатформенное хоть что-то. Инсталляторы наверное всегда ужасны, конечно.. но честный jar был бы куда приличнее. Если так и получилось, это даже хорошо.

> результат TIFFReadRGBAImageOriented вас сначала огорчит, а потом (когда поймете отчего он такой) позабавит.
а что там происходит? :)

Там смотрите, вы передаете width, height, buffer, желаемую ориентацию (допустим, хотим =1 т.е.оригинальную как в файле).
Поскольку с заданными width,height повернуть ничего нельзя.... оно возвращает зеркалированный (относительно вертикальной оси) файл. Смешно, да.

Add new comment