FRV официально public beta (как пишут авторы)

Всего 222 сообщ. | Показаны 101 - 120
Re[serg_gera]:
Цитата:
от: serg_gera

Но что Диспетчер задач показывает
1 245 360 КВ памяти откушано, настораживает в применении FRV на Хрюше.


Нет, там есть над чем работать в смысле памяти, это чистая правда (на 64 битах - неактуально, потому и не работаем).
Пока - словесное ограничение. Больше 16Mpix байера или 10Mpix sRAW - пожалте на 64 бита.

Арифметика простая - каждый пиксель в плавучке (а FRV считает все в плавучке, так не медленнее и лучше) - 16 байт.
40 мегапикселей картинки - 640M. Это не считая всякой прочей фигни: JPEG-и, RGB-представления (4 байта на пиксель), карта пересветов/недосветов (тоже 4 байта на пиксель).

Умножить на фрагментацию памяти, вот с ней, действительно, нужно поработать.

Секрет обеспечения скорости показа - он же несложный. Нужно в фоне сделать максимум работы, пока пользователь медитирует над (предыдущим) кадром. Но на это - нужна память.
Re[deejjjaaaa]:
Цитата:
от: deejjjaaaa
но вот задавать то что отображается в виде списка кодов выбираемых пользователем как минимум надо бы ( под списком кодов понимается или hex код


Да, есть в TODO уже, не вы первый просите.

Большой вопрос - что делать с camera-specific данными, типа "названия объектива", а с EXIF - даже и вопроса нет.
Re[Alex Tutubalin]:
Цитата:
от: Alex Tutubalin
с ценой пока не определились, но высокой она не будет. Что-то в районе крышечки на объектив :)

Если от алимпуза, то ой...
Re[kkk]:
Цитата:
от: kkk
Если от алимпуза, то ой...


Ну вот модель крышечки и выбираем пока :)

Re[Alex Tutubalin]:
Цитата:

от:Alex Tutubalin
Нет, там есть над чем работать в смысле памяти, это чистая правда (на 64 битах - неактуально, потому и не работаем).
Пока - словесное ограничение. Больше 16Mpix байера или 10Mpix sRAW - пожалте на 64 бита.

Подробнее


Сейчас начальные ЦЗ - 24мп
А вот нафиг смотреть 100% и декодировать под этот просмотр?
Может поступить как в RPP и добавить галку в преференсы?
У кого файлы большие, но хочется побыстрее смотреть-отбирать - решит сам.
Re[serg_gera]:
Цитата:
от: serg_gera
Сейчас начальные ЦЗ - 24мп


Сейчас начальные CPU - все 64-bit capable. Даже Intel Atom (кроме самых дохлых, одноядерных), а "настоящие" процессоры - уже давно такие.

При этом, в 64-битном режиме оно и быстрее работает - регистров больше доступно. И FRV быстрее работает и более-менее любые 64-битные приложения (относительно 32-битных братьев)

Если же чуть более серьезно и в деталях, то есть два (с половиной) случая
а) типичный: пользователь берет снимки с *одной камеры* (т.е. одинакового размера) и их смотрит. При этом, так как все размеры одинаковы, фрагментация памяти не наступает.
Я проверил сейчас (и раньше проверял) - 32-битная версия, с стандартными настройками (кэш - 8 штук) совершенно без проблем работает с 36-мегапиксельными файлами с Sony A7R, отъедая при этом гигабайт с небольшим памяти.

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

в) атипичный. Берем микс файлов с разных камер, начинаем смотреть. Вот допустим в кэше был 20-мпикс файл, а следующий - 36Mpix. Мы освободили 40Mb (одним куском) RAW-данных (20Mpix x 16 бит), нам нужен кусок на 72 (арифметика - аналогичная). Дырку на 40 - использовать не можем, берем еще памяти.

И, да, это проблема мне известна - я ее умею без проблем воспроизводить на 32-битных системах (у меня для этого есть набор самодельных синтетических DNG разных экзотических размеров), ничего нового для меня нет.

А дальше вопрос приоритетов. Программировать борьбу с фрагментацией - реально вот муторное дело. Если при этом несчастен один пользователь из тысячи (0.1%) - мне проще его пожалеть и порекомендовать таки перейти на x64, в 2014-м году пора уже (Дополнительная 4-гиговая планка памяти, которая решит массу проблем этого юзера, ну там кэши файловые станут побольше и *вообще все* станет работать быстрее - стоит $40. Апгрейд *поддерживаемой* ОС /XP к ним уже не относится/ денег вообще не стоит, ключики 32- и 64-битных Windows взаимозаменяемы.

Остальные ~33.2% пользователей (по опыту RD - на 32-битных виндах сидит ~треть) - ничего и не заметят, жалеть их не надо даже. Потому что они не суют ломы разных диаметров в бензопилы, а подпадают под описанные выше варианты а-б

UPD: потому и запрет на >16Mpix - устный. На самом деле, для типичного сценария на 32-битной машине лимит в районе 50Mpix. Если видеодрайвер не обосрется грузить текстуры.
Re[Alex Tutubalin]:
Считаете, что 50% просмотр при отсортировке недостаточно информативен?
Ресурсы сократятся же почти в четверо, а 100% просмотр при современном (не фовеонистом) пикселе - сомнительное удовольствие. Я не говорю о х32, сделать галку общую для всех типов.
Re[Alex Tutubalin]:
IMHO, пора считать, что на сегодня все системы 64бит, бо пока пилятся костыли под фрагментацию 32 битным, с них соскочат последние юзеры.
Re[serg_gera]:
Цитата:
от: serg_gera
Считаете, что 50% просмотр при отсортировке недостаточно информативен?


Считаю что достаточно - так сейчас и сделано (и просят 100 и для мелких камер, вроде 4k video - правильно просят).

Но к кэшу RAW это не имеет отношения, чтобы сделать "дебайер" в half - сами RAW данные надо распаковать все.
Re[Alex Tutubalin]:
Цитата:
от: Alex Tutubalin

...чтобы сделать "дебайер" в half - сами RAW данные надо распаковать все.


А как же?
Полноразмерный рендеринг приводит к
- учетверению памяти под картинку
- учетверению времени на все вот это вот (ББ, смена экспозиции)
- учетверению времени на загрузку данных в видеокарту (а на сейчас - это самая медленная операция)
Ну и к затратам времени на сам рендеринг, но его нужно сделать один раз на картинку, в отличие от ББ/экспозиции. (с) lexa

Уже сейчас можно использовать для более наглядной картинки для отбора, автоэкспозицию, авто-ББ. Можно еще авто-шарп добавить и авто-контраст.
А чтоб все это хорошо шевелилось - half

Re[serg_gera]:
Цитата:
от: serg_gera
А как же?
Полноразмерный рендеринг приводит к
- учетверению памяти под картинку
- учетверению времени на все вот это вот (ББ, смена экспозиции)


Ну да. Именно поэтому - сейчас все в half. Кроме распаковки RAW, кои надо распаковывать целиком. И кроме X-Trans, который в half без поллитры не распакуешь.

Но вот 36Mpix в half (9Mpix битмеп) - на приличном компьютере шевелится очень бодро, 80 - да, уже тяжеловато, но и то, жить можно. То есть можно совершенно безболезненно рендерить скажем 10Mpix в полное разрешение, а бОльшие размеры, к примеру - по кнопке или в фоне.

А для 2.5k-4k камер (4-8Mpix, соответственно) с half довольно грустно (но зато 30fps)
0.9.1 - официально
Официально вышла версия 0.9.1

http://www.fastrawviewer.ru/download

* Исправлены все известные на сегодня ошибки
* Добавлены настройки
- Стартовать в full-screen
- прятать нижнюю строку (statusbar) по Tab
- писать XMP в компактном формате
* Добавлена поддержка Samsung NX mini и Sony ILCE-3000

Re[Alex Tutubalin]:
Цитата:
от: Alex Tutubalin
Ну да. Именно поэтому - сейчас все в half. Кроме распаковки RAW, кои надо распаковывать целиком...


И что с него после распаковки? Пересветы сосчитали, раскрасили, гисту построили, зачем 100% в памяти держать? Оставить half, если пользователь галку в префах выставил.
Re[Alex Tutubalin]:
А можно подтянуть FRV в арифметике?

У меня в папке лежат три графических файла, но программа уверяет, что только два.
Один (рав SDIM2112) отсутствует в подсчете и показе


Re[serg_gera]:
Цитата:
от: serg_gera
А можно подтянуть FRV в арифметике?

У меня в папке лежат три графических файла, но программа уверяет, что только два.
Один (рав SDIM2112) отсутствует в подсчете и показе


SDIM2112.JPG склеился с SDIM2112.X3F в один "виртуальный" файл с двумя представлениями.

Выключите режим RAW+JPEG - файлов в подсчете станет три.

UPD: да, для сигм это представление выглядит немного странно, я согласен:
raw-представление запрещено т.к. сигмы не поддерживаются
встроенный jpeg запрещен при стандартных настройках т.к. они такие (игнорировать встроенный JPEG при наличии внешнего)

Re[serg_gera]:
Цитата:
от: serg_gera
И что с него после распаковки? Пересветы сосчитали, раскрасили, гисту построили, зачем 100% в памяти держать? Оставить half, если пользователь галку в префах выставил.


Пользователь ушел на следущий файл. Для него тоже посчитали все как вы написали.
Потом он вернулся. А распакованый RAW - вот он. В кэше.
Re[Alex Tutubalin]:
SDIM2112.JPG склеился с SDIM2112.X3F в один "виртуальный" файл

Опасная ситуация. На экране появляется только джипег. Если он меня не устроил (корявая проявка), при отсортировке (шифт+М) в Мусор отправляются оба jpg+raw. А рав как бы святое...
Re[serg_gera]:
Цитата:

от:serg_gera
SDIM2112.JPG склеился с SDIM2112.X3F в один "виртуальный" файл

Опасная ситуация. На экране появляется только джипег. Если он меня не устроил (корявая проявка), при отсортировке (шифт+М) в Мусор отправляются оба jpg+raw. А рав как бы святое...

Подробнее


Ну я ж написал что делать
- выключить склейку
- или выключить 'ignore internal jpegs if external jpeg exists'

В-принципе, наверное, надо просто X3F из стандартного списка расширений удалить и про сигмы забыть как страшный сон.
Re[Alex Tutubalin]:
Цитата:
от: Alex Tutubalin
Пользователь ушел на следущий файл. Для него тоже посчитали все как вы написали.
Потом он вернулся. А распакованый RAW - вот он. В кэше.


Ну меня (может и многих) устроит если он будет при отсортировке не выше 50% при Просмотре, т.е. half. В 100% все равно мыльно, а скорость может страдать. Не у всех же топовое железо.
Re[Alex Tutubalin]:
Цитата:
от: Alex Tutubalin

В-принципе, наверное, надо просто X3F из стандартного списка расширений удалить и про сигмы забыть как страшный сон.


хмм… Можно для рава давать монохромную картинку. И "честные" гистогр. и U/O
Вы не авторизованы

Пожалуйста, авторизуйтесь, чтоб иметь доступ к полному функционалу сайта

Обратная связь

Здесь вы можете оставить свои контактные данные, чтобы мы могли связаться с вами.