Программирование

(скопирую из фейсбука, чуть расширив, может и пригодится кому)

Довелось тут залезть в потроха формату HEIC/HEIF, не могу не высказать к нему свое отношение, хоть никто вроде и не спрашивал.

Summary: хороший формат, с потенциалом.

Что там хорошего:

• есть 8 и 10 бит (может быть и больше, но в дикой природе никто не видел)
• Сжатие H.265 гораздо лучше (старого) JPEG при том же/сравнимом качестве.
• Контейнер (MP4/ISO BMFF) тоже удобный, удобно разбирать, можно что хочешь положить (стандартно кладут EXIF и
...

В продолжение предыдущей записи:

• Поступила жалоба от пользователя: в свежей версии FRV под  macOS не копируются locked-файлы
• Даже не залезая в исходники Qt (я знаю что я там увижу) тут же догадался
  • QFile::copy раньше не копировал атрибуты файла (в частности, uchg)
  • А в новой версии - копирует.
  • А FRV копирует файлы правильно
    • Сначала со временными именами в папке назначения
    • И только если все нужные временные файлы (а  одна операция копирования - это может быть много файлов: RAW, JPG, .XMP) создались - происходит переименование временных в нужные имена.
    • А переименование для файлов с атрибутом uchg - запрещено в macOS.

Весь фикс, понятно, две строчки (в принципе, можно было бы и одну), потому что все запчасти нужные уже готовы (для переименования locked-файлов давно есть и нужный код и настройка "разрешать или нет").

Но я о том, что просто подмена Qt*.dll (или, в случае macOS .framework) с более старых на более новые - хоть и должна работать внутри одной major-версии Qt, но на практике - не работает.

В прошлой серии своих упражнений я дошел до того, что уперся в malloc. И успокоился. Но нет. Что-то чесалось и я решил таки продолжить, как выяснилось - не зря.

Чтобы не упираться в malloc, я перешел к такой единичной задаче:

• Передаем в worker указатель на данные (и размер)
• Считаем fnv64
• Результат - 64-битное число, которое копируется без аллокации данных и подобного.

Кроме того, мне очень хотелось добиться двух вещей

• Вписать всю конструкцию в Qt-шные signal/slot, то
...

Три недели в углу лежал незакрытый гештальт, надо закрывать.

Если кто помнит, то в прошлой серии мы дошли до того, что Qt-шная система signal-slot плохо масштабируется в многопоточном случае и нужно для передачи данных между потоками использовать что-то еще. Ну, к примеру, lock-free очередь (из TBB или вот эту, такой уж большой разницы я пока не обнаружил, хотя и должна быть).

Ну что ж, берем делаем приложение:

• пачка потоков (1...32) делает какую-то простую работу (копирует строку)
• складывает
...

Давно не писал о программировании, а тут вдруг повод появился.

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

В реальной жизни прекрасно работает вот такой вот паттерн: запустим N threads и в каждой из них будем делать как-то так:

while(job = nextJob()){ result =...

Записки для себя, но вдруг кому будет полезно: есть многочисленные интернетные гайды, но они все - неизвестного времени, а многое - поменялось....

Загорелось мне тут сделать программу одну для телефона, чисто для себя. Ну, понятно, Qt+QML, потому что Qt я знаю, QML видел издалека, ничего сложного не запланировано. Как и всегда, главный вопрос "как начать" (т.е. настроить все, чтобы оно работало, компилировало, загружало в телефон/эмулятор), я на него потратил минимум...

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

Я на это уже жаловался, но в фейсбуке, а не тут.

Но просматривая сегодня Qt mailing lists/development не смог пройти мимо:

Несчастный пользователь пишет:

I'd like to point out how badly this issue has been handled. It's been reported on February 2016 and marked as P4.To me, it seems a nonsense to ignore issues like this, especially now that Qt3D offers a lot of possibilities and sooner or later you might need to switch your app to core profile....

На одном и том же CPU (i7-7700k на базовых частотах), переход с SSE3 на AVX2 дает выигрыш, если по отдельным кускам:

• Half-демозаика + ББ + цветовая конверсия + тоновая кривая, запись RGB bitmap: 1.97/1.11 sec (SSE/AVX)
• Half-демозаика + ББ + цветовая конверсия + построение гистограммы: 2.11/1.483
• Чтение raw-данных (int16), преборазование в float, вычитание черного, построение RAW-гистограммы: 1.78/1.72. Гистограмма - это очень медленно.....

Тестовый набор: 22 файла Sony A7RM2, т.е. ~900Mpix в сумме. Чиселки - CPU time (не wall time, потому что мультитрединг).

Общий выигрыш на всю программу - не больше 10 процентов, потому что уперлись теперь в видеодрайвер (генерация мипмепов, загрузка текстур в видеокарту), все спинлоки - тама.  Надо более продвинутый OpenGL использовать.