Свежие комментарии

Странно сие, да.
Попробую да усыпить и разбудить, может там сетевой менеджер не просыпается.

Железка лежит прямо в коробке.
Конкретно у моего, который NUC5i3RYH, возможно у других моделей иная комплектация.

Прикручивать к монитору не очень удобно - порты тоже оказываются сзади (USB, наушники)

Если бы я купил Intel NUC, то захотел бы его прикрутить к монитору, чтобы он не занимал места на столе.

И как ни странно Intel это предусмотрели: http://click.intel.com/vesa-bracket-for-next-unit-of-computing.html - молодцы. Впрочем в России эту железку никто не продаёт (или она уже есть в комплекте?).

Да, стандарт на ISO здорово поломан, это верно.
С разрешением - да, меряли на миллиметр, это и сегодня можно.

"Шансов столкнуться с ней в реальности со своими файлами - примерно ноль"
Вот за это я Вас и ценю!
Респект.

Пока наша позиция тверда как кремень
- никакой записи в RAW (втч в DNG, хотя это мешает)
- никакой записи в JPG (хотя это вот не дает иметь отдельные XMP для jpeg и raw)
- никакого удаления сразу, потому что все мы, такие умные и опытные, многократно теряли данные по собственной дури.

Используйте другую программу.

Сейчас я вот уверен, что FRV *не может* ничего удалить (из за моей программистской ошибки, например) или испортить важные данные (XMP я к ним не отношу), потому что просто места такого нет. Это - важная (для меня) уверенность.

Вот сейчас должна увидеть. Перебросили крантик.

Если Filmstrip, то максимум что с ним можно сделать это
1) Prefetch depth = 0
2) Prefetch threads = 1

Если и так будет мешать - закрыть эту панель (F6, перестартовывать не надо) и использовать только если нужно.

Да, с версией я ошибся, имел ввиду ту, в которой появились Filmstrip и Folders. И судя по некоторым наблюдениям, тормоза возникают из-за отображения Filmstrip. Поменял настройки в соответствии с данными рекомендациями, стало чуть лучше, но иногда задержки все же проявляются. Посмотрю еще, если задержки будут мешать, тогда пришлю отладочный лог.

Спасибо!

Этот путь мне известен уже четыре года: http://blog.lexa.ru/2011/05/12/o_rastre_v_gps_howto.html
Но GlobalMapper14 на тех случаях, когда нужны большие тайлы, работает сильно быстрее: http://blog.lexa.ru/2013/05/04/o_rastre_v_gps_chast_3.html
Но хотелось бы еще быстрее, конечно, вот оно сейчас фигачит 4 листа 2-километровки, так за 2 часа только 2/3 сделало.

Или map2jnx за прошедшие 4 года стал сильно быстрее?

UPD: В моем понимании "лист" - это лист номенклатуры, скажем M-48. Километровых карт он содержит 144 штучки, если не в высоких широтах.

Оно фрактальное, в каждом месте - БЕЗДНЫ. Если вдаться на первый уровень, то

• метаданные: основное количество EXIF, но есть некоторое количество отдельно стоящих (Foveon, .mos, внешний JPEG)
  • следующий уровень фрактала: DNG-файлы, конвертированные из не-DNG, разными версиями конвертора Adobe с сильно разными приколами
• распаковщики, не помню сколько, но штук 25 их вроде есть. 8 файлов покрывают, понятно, не более 8 (я тут не ожидаю особых траблов, хотя вот зацикленный ljpeg_start уже поправили)
• постпроцессинг базовый (демозаика и помимо нее)
• - постпроцессинг расширенный (HL recovery, коррекция всякой разной фигни)

Последние два твои тесты вовсе не трогают. А там могут быть свои приколы, вроде вынутого из камеры кривой матрицы color space которая, к примеру, не инвертируется (и никто этого не проверяет)

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

UPD: вот у Canon с десяток версий Makernotes (это байтовый массив, одни и те же данные лежат с разными смешениями). Интересно, оно мутировало их в разные варианты, али по одному пути ходим.

Ну и отлично.

Там вот для меня мутный вопрос (на тему "как правильно") - это битые теги EXIF/TIFF(/Makernotes для тех, у кого makernotes в этом же формате).
Вот два примера:
1) Тег указывает за пределы текущего файла (текущая позиция + offset - в космос). Казалось бы, битый файл, его не надо принимать, однако у Лейки половина файлов такая (а у второй половины - кажет в космос, но внутрь файла попадает). Вот скандал с Apple Photos и Leica Typ 246 - скорее всего ровно из этой области.
2) Тег корректный, но невдолбенная длина, которой у данного тега быть не должно.

Эти две штуки мешают отрезать некорректное сразу, всякие условия по длине тега приходится ставить по месту, а мест - много.

Если я не обсчитался, то всего 6 багов. Три наших, три Коффиновских.
Будешь продолжать - бери Альфу4 отсюда: http://www.libraw.org/download

Оно пока не анонсировано т.к. надо часть этих багфиксов загнать в 0.16, вечером сделаю и анонсирую обе две сразу.

Удаленно лечить очень непросто, все советы будут в духе "по колесу постучать".
1.1 отличается от 1.0 панелями Filmstrip и Folders. С ними ситуация такая
Filmstrip: "отключается" сразу при ее убирании. Если тормоза связаны с тем, что у вас перестраивается (длинный) список превьюшек - вы это сразу заметите.
Folders: чтобы ее отключить совсем (мониторинг дисков и т.п) - FRV нужно перестартовать.

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

Не видя что у вас происходит, я, тем не менее, предполагаю, что таки дело в панели с превьюшками файлов, она может конкурировать за процессор (и диск, хотя для SSD это малозаметно) с показом RAW. Эту панель можно "прижать" настройками в Preferences - Performance - группа Thumbnail cache:
- Thumbnail prefetch depth поставить поменьше (это глубина чтения "за" видимое окно)
- Thumbnail decoder thread count: тоже поменьше, 1-2.

Если вышеописанное (отключение ненужных панелей, уменьшение ресурсов на чтение thumbnail) не поможет, то надо сделать так
- включить отладочный лог в Preferences - Other - Enable FastRawViewer debug log
- перестартовать FRV
- добиться тормозов при перемещении в Rejected
- Menu - Help - Debug log записать в файл и прислать на support@fastrawviewer.com

Будем тогда разбираться глубже