Картинка дня

Кто не понял про что это - смотрите теги :)

Qt - рулит. Ну то есть я не разобрался (пока?) с динамическими библиотеками, Frameworks и прочими страшными словами, поэтому с LibRaw слинковался статикой.

Ну, естественно, повылезало всякого, но умеренно:

  • Явная установка лимитов размеров элементов. Где-то слишком мало оказалось (преимущественно), где-то, наоборот, слишком много. Шрифты все-таки совсем другие. Приходится доделывать (и на скриншоте видно, что еще не закончил).

    Без таковой установки все может выглядеть немножко слишком просторно или слишком резиново,но почти гарантированно не будет ужасно

  • Qt Designer - полный и абсолютный трэш и угар. Диалоги, которые он делает - и на винде то плохо переживают шрифт 150%, а на Mac - полная катастрофа. Пока, временно, растянул на побольше, но придется руками переделывать.
  • С Shortcuts - ожидаемые и неожиданные приколы. Например Preferences (Ctrl-P в виндовой версии) стала Command-, (как положено), но Command-P тоже работает. Но что-то и отвалилось, скажем Ctrl-H не стала Command-H (Hide).
  • QGroupBox, который на винде выглядит отлично, на Маке смотрится плохо, а заменить нечем.
  • Ну и, так как инсталлятора нет, то ExifTool придется класть внутрь .app, а значит как-то научиться его там найти. Но, похоже, второе реально несовместимое с виндой место.
  • А первое несовместимое место - это обращение с нелатинскими именами файлов. Виндовый wfopen (и подобные) хочет wchar_t*, а Мак - UTF-ную строку в char*

Comments

а нефиг файл называть не английскими буквами!

спасибо, пошел пробовать :-)

работает, я проверил. У меня там std::filebuf, правда, но с fopen тоже должно работать.

Что же до файлов - то мне жаловался грек, у него отчего-то системная локаль стояла американская, а имена файлов были родные.

ой, а нельзя ли то, что можно попробовать? не нашел на сайте, вряд ли уж настолько плохо искал. интересует под macos, у меня 10.6.8

В течение нескольких дней, если я не пропустил что-то фатальное, выйдет маковская альфа.

Уведомление будет и тут и на rawdigger.ru

> А первое несовместимое место - это обращение с нелатинскими именами файлов. Виндовый wfopen (и подобные) хочет wchar_t*, а Мак - UTF-ную строку в char*

QFile ?

Ну да. С QFile/QDir проблем нет совсем.

Только у меня LibRaw::open_file(const char *fname, int bigfile_limit = 100M);

Соответственно, под винду пришлось родить вызов
LibRaw::open_file(const wchar_t *fname, int bigfile_limit = 100M);

А внутри там неонка. Точнее std::filebuf и/или fopen/wfopen (и еще куча гемороя, связанного с тем, что метаданные могут быть в отдельном файле с тем же именем и другим расширением или с тем же расширением, но номером отличающимся на единичку, очень сексуально на самом деле).

Ну а дальше QString::toStdWstring на винде, QString::toUtf8 на маке. Ужос.

Вот!
А нельзя libraw кормить данные из произвольного стрима? Типа кусочками - данные пришли - мы их скормили. И обработку по мере возможности делать также кусочками.

Не, ну а как тогда открывать соседние файлы с метаданными? У стрима таких свойств быть не может.
А выкинуть эту возможность - означает выкинуть метаданные от хаканых камер (CHDK и аналогичное для Nikon). Что в общем случае - как-то обидно.

А так - весь I/O работает на классе LibRaw_datastream, в поставке есть реализации на файлах, std::filebuf, mmap для Win32, буфере в памяти.
Если кому дозареза нужен стрим - пусть реализует. Но seek() придется реализовать.

Что же до памяти - процессинг в любом случае требует в разы больше памяти, на этом фоне буфер для байеровских данных не слишком мешает.

> Не, ну а как тогда открывать соседние файлы с метаданными? У стрима таких свойств быть не может.

Коллбэк аппликухе, чтобы стрим с метаданными выдала.

Ну оно так примерно и работает (зовется subfile_open - метод LibRaw_datastream).
Но для этого надо знать (в LibRaw) имя файла, который отдали изначально (чтобы по нему вычислить).

В-общем, дырка проковыряна (в виде класса, реализующего IO), но она довольно развесистая и не от хорошей жизни эта развесистость.

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

Ага!
Спасибо за freeimage! То, что нужно!

Алексей, обьясни плиз, из каких соображений RawDigger
ставит точку 0Ev на гистограмме в автомате? Вроде попадалось где-то но не нашёл :(

http://www.rawdigger.ru/usermanual/histograms

Ноль шкалы размещается на уровне 3 стопа (8 раз) ниже, чем максимальное значение пиксела, округленное вверх до ближайшей степени двойки . Например, если максимальное значение среди всех пикселов снимка равно 3000, то ближайшая бОльшая степень двойки - 4096 и уровень EV0 для данного снимка будет автоматически установлен на уровне 512

Это для гистограммы по всему изображению.

Для гистограммы по кусочку - используется EV0 от всего изображения (и это место может глючить).

Если включено "Remember last used Histogram Settings", то EV0 берется от предыдущей (по времени) гистограммы, неважно в этом запуске программы или в предыдущем.

Спасибо!

YASQ: А зачем ExifTool если можно слинковаться с exiv2?

GPL2

У автора exiv2 можно и разрешение спросить. Таскать с собой самораспаковывающийся perl-бинарник с GPLv1 - брр.

Отчего же с GPLv1. C Artistic