Свежие комментарии
| Title | Comment |
|---|---|
| А 1063 - правит ошибку в |
А 1063 - правит ошибку в первом режиме. |
| 1062 - дозволяет регулировку |
1062 - дозволяет регулировку на любой вкус, четвертого варианта не придумать, пожалуй. Вот так и оставим. |
| Кроп/выравнивание |
Кроп/выравнивание запланированы на версию 1.5 Там не все так просто, как хотелось бы т.к. адобовский "полный кадр" и наш отличаются (наш чуть побольше, поля не оставляем), но для ~700 актуальных камер (из 1000 поддержаных) решим вопрос. |
| В LR удобный инструмент для |
В LR удобный инструмент для кропа/выравнивания. Но LR тормозит... А может этот функционал добавить в FRV? Он же независим от камеры и цвета, и пишется в XMP? |
| Да, Ctrl-Click или чекбокс не |
Да, Ctrl-Click или чекбокс не делают файл текущим |
| Ну да, у нас осознанно |
Ну да, у нас осознанно разнесена отметка (select) и перемещение. Я там задал другой же вопрос, ну да ладно уже. |
| > а потом перешли на |
> а потом перешли на следующий - нам что ли галку снимать? я про операции select/deselect, а не про выбор текущего (на котором "фокус")... например у меня текущий файл "А" где-то далеко там и я сделал ctrl-click мышкой (select/deselect) на другом файле "B" (или попал ему в чекбокс в углу просто кликом) - и текущим сразу стал этот файл "B" ... это никак не отменяет ситуации возможной в FRV что текущим может опять стать другой файл "C" без того чтобы он стал selected (например мы в него просто кликнули мышкой, но не попали в чекбокс или сказали через меню/клавиши "(De)Select and move to next")... |
| Ну "select/unselect' в том |
Ну "select/unselect' в том смысле что "покрасить его красным и добавить в список выбранных" - это плохая идея т.к. если мы сначала текущим файлом попали на уже selected (с галочкой), а потом перешли на следующий - нам что ли галку снимать? Или завести там некий tri-state (выбран явно, выбран переходом)... ну это сильно усложнит все внутри. Поэтому то что вы хотите надо делать иначе, добавлением третьей опции к этому выпадающему новому списку вариантов (на кого действуют хоткеи/пункты меню/кнопки на панелях): current+selected (в добавление к имеющимся current, selected). Остается единственный вопрос: контекстные меню (на selected файлах), через которые можно сделать все то же самое. |
| душевно... а вот еще - я не |
душевно... а вот еще - я не знаю как другие пользователи... но я испорчен UI в других программах где по больше части - текущий файл он же и selected автоматически... никак нельзя заполучить опцию чтобы выбор (обе операции select/de-select) файла в FRV его бы автоматом делал и текущим при этом ? т.е. чтобы текущий файл не болтался где-то там сам по себе хрен знает где (раз уж он у вас не считается selected по умолчанию)... |
| См билд 1161 (и выделено |
См билд 1161 (и выделено красным в тексте) - это место стало регулироваться. |
| В Lr если есть выделенные, то |
В Lr если есть выделенные, то текущий - обязательно в них входит. У нас "selection model" другая - и в этом месте пахнет настройкой уже. |
| > если выделены несколько |
> если выделены несколько файлов и текущий файл в группе выделенных А хорошо ли это... раз выделил то выделил для операций... не важно какой там текущий уже... хотя если цель совместимость с массовым сознанием = LR и там так оно и есть, то в этом есть смысл |
| https://blog.lexa.ru/2017/09 |
https://blog.lexa.ru/2017/09/07/fastrawviewer_144_1156_beta2.html |
| Мы сейчас переделываем "как в |
Мы сейчас переделываем "как в Lr" (логика в любом случае сложная, в таком случае надежнее списать слова). Будет еще и по разному в Grid/Single file mode. |
| > В групповом режиме .... |
> В групповом режиме .... кнопки/индикаторы в нижней строке программы ( ... рейтинг, метка) продолжают работать в режиме "одного файла" ложка меда ! |
| Полет вашей мысли мне |
Полет вашей мысли мне непонятен. |
| Про возможную мотивацию. |
ИМХО, это сделано для ускорения работы с каталогами, которые содержат снимки с нескольких камер. |
| Насколько я знаю, |
Насколько я знаю, используемый фаззер дает лимит в 2Gb на фаззимую программу. Теперь почему "в реальном коде не будет". Ну потому, что (см. соседние комментарии) резать по одному фиксированному размеру для данного формата (ну там NEF - не крупнее чем D810) или по списку размеров - не очень хорошо, если мы осознанно даем юзеру возможность поправить у файла make/model и посмотреть что будет (впрочем, у софта, который пользуется hardcoded-метаданными от RawSpeed - будет не очень хорошо). В реальном коде имеет смысл ставить (динамически) ограничение на максимальный размер (в мегапикселях), исходя ну вот из потенциально доступной памяти (и, скажем, в 32-битном FRV стоит стандартное ограничение в 40Mpix, правда юзер может его поменять) |
| Ну вот свежий пример D850. |
Ну вот свежий пример D850. Чтобы открыть тамошние NEF-ы адобовскими тулами - меняют модель на D750 или на D500. В обоих случаях - если мы проверяем размеры - файл будет отвергнут т.к. размер не соответствует D750/D500 |
| Можно же сделать так, чтоб не |
Можно же сделать так, чтоб не поломало. "Нет камеры в БД - не проверяем размер". Ну, или проверяем, но на совсем уж дикие значения. Например, чтоб ширина/высота не превышали более чем в три раза размеры от самой развесистой камеры того же производителя. |
| > 16 битные и больше чем 2^32 |
> 16 битные и больше чем 2^32 не будет в любом случае. я только про то, что доводы в пользу фаззинга разумные, и как-то ограничить размеры сверху это хорошо (только лучше в отдельной проверке с отдельной диагностикой). я предложил ограничить примерно на 20-ти битах, как раз что бы перемножение размеров было больше 31-го бита, но если Вы считаете что можно ограничить ниже, не буду спорить. основывался на том что разрешение человеческого зрения вроде примерно на границе 16, так что лучше с запасом, и с учётом того что у роботом может вполне быть больше. |
| Заметим в скобках, что |
Заметим в скобках, что таблица размеров для make-model поломает часто применяемый пользователями способ таки скормить файл (от новой камеры) конвертору (который эту новую камеру не поддерживает и отвергает "по списку поддерживаемых") - меняют make/model в EXIF и начинает жрать. Что, наверное, тоже плохо. То есть такая проверка должна отключаться на рантайме (и end-user sw должно иметь для этого рукоятку) |
| Ну если под i32 имеется в |
Ну если под i32 имеется в виду u32, то это в меру бессмысленное упражнение будет, потому что размеры в файле (часто/обычно, лень проверять) - 16 битные и больше чем 2^32 не будет в любом случае. Сама по себе проверка для файлов "из камер" имеет смысл (размеры если и меняются с обновлением FW, то это бывает ну сильно редко), но тогда уже полноценная, make+model=>список размеров (хотя вот возможно что двуформатные камеры, типа пентаксов, имеют два списка размеров, никогда не задумывался). Я имею в виду "на практике имеет смысл", чтобы битые файлы отвергать как можно раньше. Второе применение такого лимита - это (слегка) застраховаться от out of memory (в случае битых файлов). Тогда можно какой-то вменяемый лимит поставить, ну там 300Mpix или гигапиксель, и забыть про это место на несколько лет (пока какой-нибудь олимпус не сделает склейку панорам в камере в raw). Меня в данной конкретной истории изумляет не то, что это вот было сделано (проверка имеет смысл, повторяю), а способ реализации проверки. |
| а нельзя ли просто |
а нельзя ли просто захардкодить в 100 раз бОльшие константы, что бы и фаззер был счастлив и человеки? что бы например W*H был больше i32. |
| А вторая сторона "будем |
А вторая сторона "будем использовать только Turbo C++, потому что деды так делали". Или Фортран-4. Новые технологиии осваивать надо, опенсорсная библиотека с (очень) небольшим количеством пользователей - это прекрасный вариант для такого освоения. Тут я ничего против сказать не могу (хотя некомпилируемость теми версиями компилятора MS, которые я использую в production - огорчает, но я переживу). Я возражаю именно против частных некорректных практик (собственно, она одна, хардкодинг, сначала в данных, а вот теперь и в коде) |
| Два носа в бесконечное |
Два носа в бесконечное количество раз лучше отсутствия носа! |
| А представьте себе, что |
А представьте себе, что выслушивают фотографы, не позаботившиеся выставить свет так, чтобы клиенту нравилось. Мягкий вариант - "а почему на Вашем снимке два носа?" И ничего, извиняемся и переснимаем, со срочностью. Объяснение "это свет бабочкой, стиль такой" не проканает. |
| > многие вещи делаются - как |
> многие вещи делаются - как мне кажется со стороны - ради процесса разработки, а не ради результата (а результат - удовлетворение пользователей, а не разработчиков) А это уже не первый год мода такая - программизм ради программизма. |
| Ну в этом смысле, да, я |
Ну в этом смысле, да, я (потенциальный) пользователь, пора эту версию прикручивать как-то аккуратно, там декодеры ljpeg реально быстрее. |
| По-моему эти обиды это |
По-моему эти обиды это детство сплошное. Нам от пользователей продукта и не такое приходится выслушивать и в более критичной форме и ничего - вдумываемся в сказанное и делаем выводы. |
Pages
