blog.lexa.ru

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

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

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

Я пропустил анонс и увидел его только по трафику на 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.

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

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

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

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

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

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

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

Вот значит сменил видяху, на 2080 Ti. Быстрая, где-то раза в два быстрее чем 1080 (по Furmark), явный для моих целей оверкилл (FRV, без всяких оптимизаций под очень много ядер - кажет 40Mpix/Sony uncompressed со скоростью 24fps, при этом видяха не удосуживается даже частоту поднять хотя бы до базовой, не говоря о boost).

Брал из идеи попрограммировать Tensor cores когда дойдут руки, ну прям очень интересно.

Но я не об этом.

Чудовищные, чудовищно сырые дрова драйвера. В двухмониторной конфигурации стандартно частота в idle не падает ниже 1065Mhz и ~60 ватт потребления. Проблема известная, частота минимальная у всех разная, но большая, есть гипотеза что она зависит от частоты обновления мониторов (на 120/144 Hz у народа бывает и больше мегагерцев в idle).

В октябре выпустили версию драйверов, которая проблему должна была вылечить, но нет.

Решение - частичное - тоже известно, NVidia Inspector, там есть аж специальный режим для Multimonitor Power saver. У меня сбивает частоту до 645, потребление до 20 с небольшим ватт.

В одномониторном режиме такого нет, без всякого инспектора - частота падает до 300-330Mhz сама.

Ну я даже смирился уже.

Но вот оставил компьютер на ночь в режиме sleep. Утром - разбудил, а у меня мониторинг видяхи (пока) выведен. Ну и проснулась она и у нее все хорошо - 300Mhz в idle. Второй монитор - вот он.

То ли выспаться ей было надо, то ли еще чего.

Уверен на 100% - перезагружусь и опять будет 645. Вот пошел пробовать....

UPD: перезагрузился, конечно 645. Дал поспать минутку, разбудил, после просыпания - 645, но пока я это пишу - упало до 300. Правда на потребление переход с 645 на 300 влияет мало, пара ватт.

P.S. Ну и в firefox  - flicker при прокрутке на оба монитора. Нужно hw acceleration выключать.