2019

Удивительное рядом, но оно запрещено!

После всех копаний в спецификациях TIFF более всего мне нравится следующий момент:

Вот есть многоканальный (к примеру, RGB) TIFF, так и пишем, 3 значения на пиксель. Или вот 4, потому что Альфа-канал:

  | 5)  PhotometricInterpretation = 2 => RGB
  | 8)  SamplesPerPixel = 4 => RGB + Alpha (не пробовал, но поди можно и больше)
  | 19) ExtraSamples = 0 => Unspecified data т.е. "это не прозрачность"

Дальше для каждого из каналов задается его формат и битность:
...

А если не кот, то кто?

Берем grayscale/floating point/32bit изображение.

И сохраняем его из фотошопа как 24 bit/floating point/TIFF:

Фотошоп, конечно, честно предупреждает, что хрен кто прочтет:

И ведь не врет. Открываем результат в IrfanView:

И наслаждаемся.

При этом:

  | 5)  PhotometricInterpretation = 1 => это Grayscale
  | 10) SamplesPerPixel =...

Если не Adobe то кот?

Базовый Gray/RGB TIFF сковал, полез смотреть всякую экзотику, начал, для начала, с grayscale.

ImageMagick в зубы и в таком вот духе:

for bit in 8 9 12 14 16 17 24 29 32; do convert AZ1I2270_gray.tif -depth $bit -define tiff:endian=msb -define quantum:format=signed -define quantum:polarity=min-is-white AZ1I2270_gray${bit}sint_msb_inv.tif ; done

Ну и смотреть, адобом и IrfanView, до других уж извините руки не доходят. Выглядит местами смешно (кликабельно):

...

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

Повозившись сначала с 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 придется самому написать большую гору кода.

Трудо-выебудни

А вот, например, Adobe Bridge:

  1. Читает TIFF-файлы (ура).
  2. Умеет их повернуть (тоже неплохо). Делает это сменой тега Orientation.
  3. Но: если в файле содержится несколько изображений (т.е. image pyramid в терминах фотошопа), то Orientation меняется только у IFD0.
  4. При этом стандарт конечно умалчивает "как правильно поворачивать TIFF", но поскольку в IFD1..n прочие описания изображения (ну там размер, BitsPerSample, etc) описывают данное "под"-изображение, логично думать что и Orientation там верный (если этот тег есть, понятно что если его нет, то надо
  5. ...

FastRawViewer 1.5 technology preview: кэширование превьюшек

До версии 1.4 включительно, FastRawViewer ничего не писал на диск (кроме XMP-файлов) и это было хорошо, потому что диски не замусоривались. При этом, превьюшки даже самых толстых RAW декодировались достаточно быстро с быстрых носителей и вменяемо быстро - с медленных (вроде одиночных HDD или флеш-карточек)

Однако времена меняются, потребности растут. В частности, запланированная поддержка форматов TIFF и PNG требует других решений: TIFF может занимать сотни мегабайт, быть запакован медленным упаковщиком и не содержать превьюшки. Декодирование его займет, соответственно, секунды (или...

Про Asus XG-U2008 (свитч)

Несколько месяцев назад я заменил старый добрый 8-портовый гигабитный DLink (не помню модели) на свитч Asus XG-U2008. 8 гигабитных портов + 2x10G

Не делайте так, дети. К гигабитным портам претензий нет, а вот с 10G засада: временами, как бы не раз в неделю, оно затыкается: лампочки горят, с точки зрения подключенных компьютеров все ОК, а вот байты не ходят. Лечится только передергом питания свитча.

Буду тратить денег на 5-портовый Netgear XS505M, дешевле вариантов не нашел.

Картинка - для привлечения внимания. Я на нее как посмотрю, так начинаю ржать.

Дама, сошедшая с экипажа, снижает необходимое тягловое усилие

Я пропустил анонс и увидел его только по трафику на www.libraw.org, а оказывается еще неделю назад Microsoft выпустил Raw Image Extension (Beta), замену многолетней боли Raw Codec Pack (в Win10 оно встроенное, но текущие версии не сильно лучше) вот с таким анонсом:

By installing the package, you will be able to view thumbnails and metadata of supported raw file formats right in Windows File Explorer or view images in the Photos app.

Пока не смотрел, оно требует...

FastRawViewer 1.4.11 Release

Мы собирались выпустить FastRawViewer 1.4.11 быстро, исправив там одну плохую ошибку (с пресетами ББ у кэнона). Вместо этого получается работа по заявкам: фидбек поступает постоянно, а поскольку версия в работе, то почему бы не поправить еще и это, делов то на 5 минут. Это, конечно, делает программу лучше, но пора и остановиться.

UPD: FRV 1.4.11-1402 выпущен как релиз

На сегодняшний день список правок таков (относительно версии 1.4.10):

Новое

  • Значительно (десятки процентов) ускорено чтение thumbnails. Заметно на медленных носителях (одиночный
  • ...

О цветовой дифференциации

Потратил... ну даже не столько время, сколько жизненных сил, прямо вот упадок чувствую:

Один из компьютеров в доме как то медленно ходил в интернет. И ладно бы в интернет, на локальный файлбокс тоже. Этот файлбокс использует только этот компьютер, поэтому заметил ну вот сегодня.

И что я только не делал, самбу тюнил, на прерывания смотрел, ethernet-кабель менял, все одно - херня, медленно и плохо. Точнее, было просто плохо (меньше 1Mb/sec в любую сторону), после замены кабеля в одну сторону заработало нормально, в другую - все то же говно.

Что выяснилось:

  • Осенью я закупил мешок ethernet-хвостиков. Разной длины и разного цвета. Трехметровые, к примеру, черные, полутораметровые - белые, метровые - желтые. Мне так удобно.
  • И менял я ethernet-кабель - на такой же, конечно, потому что в это место хорошо ложится трехметровый.
  • Так вот, черные, похоже, просто все плохие. Все три. Там и кабель на ощупь какой-то не такой, ну и вот ошибки на интерфейсе (да, дошел до того, что стал их искать).
  • Заменил на зеленый (5 метров), все заработало как из пушки.

Так и запишем, черный ethernet больше не покупать. Куплю трехметровых красных пожалуй.

Pages