Картинка дня
lexa - 28/Мар/2012 18:08
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, правда, но с
работает, я проверил. У меня там std::filebuf, правда, но с fopen тоже должно работать.
Что же до файлов - то мне жаловался грек, у него отчего-то системная локаль стояла американская, а имена файлов были родные.
ой, а нельзя ли то, что можно попробовать? не нашел на сайте
ой, а нельзя ли то, что можно попробовать? не нашел на сайте, вряд ли уж настолько плохо искал. интересует под macos, у меня 10.6.8
В течение нескольких дней, если я не пропустил что-то фаталь
В течение нескольких дней, если я не пропустил что-то фатальное, выйдет маковская альфа.
Уведомление будет и тут и на rawdigger.ru
http://www.rawdigger.ru/news/rawdigger-0-9-10-alpha-mac
http://www.rawdigger.ru/news/rawdigger-0-9-10-alpha-mac
> А первое несовместимое место - это обращение с нелатинским
> А первое несовместимое место - это обращение с нелатинскими именами файлов. Виндовый wfopen (и подобные) хочет wchar_t*, а Мак - UTF-ную строку в char*
QFile ?
Ну да. С QFile/QDir проблем нет совсем. Только у меня LibRa
Ну да. С 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 кормить данные из произвольного стрима?
Вот!
А нельзя libraw кормить данные из произвольного стрима? Типа кусочками - данные пришли - мы их скормили. И обработку по мере возможности делать также кусочками.
Не, ну а как тогда открывать соседние файлы с метаданными? У
Не, ну а как тогда открывать соседние файлы с метаданными? У стрима таких свойств быть не может.
А выкинуть эту возможность - означает выкинуть метаданные от хаканых камер (CHDK и аналогичное для Nikon). Что в общем случае - как-то обидно.
А так - весь I/O работает на классе LibRaw_datastream, в поставке есть реализации на файлах, std::filebuf, mmap для Win32, буфере в памяти.
Если кому дозареза нужен стрим - пусть реализует. Но seek() придется реализовать.
Что же до памяти - процессинг в любом случае требует в разы больше памяти, на этом фоне буфер для байеровских данных не слишком мешает.
> Не, ну а как тогда открывать соседние файлы с метаданными?
> Не, ну а как тогда открывать соседние файлы с метаданными? У стрима таких свойств быть не может.
Коллбэк аппликухе, чтобы стрим с метаданными выдала.
Ну оно так примерно и работает (зовется subfile_open - метод
Ну оно так примерно и работает (зовется subfile_open - метод LibRaw_datastream).
Но для этого надо знать (в LibRaw) имя файла, который отдали изначально (чтобы по нему вычислить).
В-общем, дырка проковыряна (в виде класса, реализующего IO), но она довольно развесистая и не от хорошей жизни эта развесистость.
И я даже знаю, что ей пользуются, наприме в freeimage (а freeimage, в свою очередь, офигенно распространенная библиотека для поддержки всего что шевелится в смысле графики)
Ага! Спасибо за freeimage! То, что нужно!
Ага!
Спасибо за freeimage! То, что нужно!
Алексей, обьясни плиз, из
Алексей, обьясни плиз, из каких соображений RawDigger
ставит точку 0Ev на гистограмме в автомате? Вроде попадалось где-то но не нашёл :(
http://www.rawdigger.ru/userm
http://www.rawdigger.ru/usermanual/histograms
Это для гистограммы по всему изображению.
Для гистограммы по кусочку - используется EV0 от всего изображения (и это место может глючить).
Если включено "Remember last used Histogram Settings", то EV0 берется от предыдущей (по времени) гистограммы, неважно в этом запуске программы или в предыдущем.
Спасибо!
Спасибо!
YASQ: А зачем ExifTool если
YASQ: А зачем ExifTool если можно слинковаться с exiv2?
GPL2
GPL2
У автора exiv2 можно и
У автора exiv2 можно и разрешение спросить. Таскать с собой самораспаковывающийся perl-бинарник с GPLv1 - брр.
Отчего же с GPLv1. C Artistic
Отчего же с GPLv1. C Artistic