comments by 452
> Назвал все буквы, но не
> Назвал все буквы, но не сумел прочесть слово.
от того что я не говорю на албанском, текст на оном не перестаем быть текстом на оном - я могу видеть слова и буквы... но понять не могу...
> Стандарт определяет не только "контейнер" но и интерпретацию стандартных же тегов.
я лишь про контейнер - кто-то утверждал что если какое-то ПО не понимает допустимую стандартом перестановку тэгов в порядке следования в файле то все пропало и на этом основании это не tiff контейнер...
Z / V
> Написать такой тег можно?
> Написать такой тег можно? Ну да. Что он значит?
а вот это уже не про "контейнер", а про интерпретацию содержимого тэгов (тех которые не отвечают за собственно структуру контейнера)...
Z / V
> так а откуда мы знаем что
> так а откуда мы знаем что это tiff-контейнер?
если структура файла соотв. "стандарту" , то ПО которое учитывает стандарт (не обязательно конвертер) может правильно разобрать файл на составные части (опять же мы не говорим о конверсии - просто разбор, без интепретации содержимого относящегося к конверсии и томы подобному)
Z / V
> Если в
> Если в PhotometricInterpretation написано что-то, чего нет в описании TIFF 6.0 - это TIFF или нет?
1) это же относится к интерпретации данных внутри контейнера, да ? т.е. даже если "стандард" явно запрещает что-то не описанное в стандарте для данного тэга это все равно оставляет саму структуру файла контейнером соотв. стандарту
2) если же "стандард" явно не запрещает для данного случае что-то не описанное стандартом то не только структура соотв. контейнеру, но и в части интерпретации содержимого контейнера все в порядке
Z / V
> А в случае любого
> А в случае любого собственного RAW формата
мы же про те raw которые tiff контейнер, если tiff контейнер разрешает подобное - то это именно ошибка в software... и даже если родное ПО (конвертер поставляемый производителем) выдает ошибку после подобных манипуляций над структурой, то это опять же ошибка этого ПО и только... потому что понятно что когда задумывали файл то исходили как раз из tiff, но поленились ПО написать соотв. образом - а вовсе не потому что был замысел специально сделать формат файла не соотв. tiff
Z / V
> В стандарте TIFF 6.0 даже
> В стандарте TIFF 6.0 даже про SubIFD нету ничего.
но тогда и претензии к файлу про SubIFD не надо предъявлять (на тему что он не tiff 6.0 контейнер
Z / V
> Но не TIFF.
> Но не TIFF.
чем не TIFF ? что именно нарушает в стуктуре файла стандарт ? речь не про конвертер, а именно про содержимое файла
Z / V
> А вот фирменный RAW может
> А вот фирменный RAW может (и технически и юридически, потому что никто не произносил вслух слово «TIFF») сломаться от перестановки местами двух полей в image directory. TIFF от этого разваливаться не имеет право. а фирменный RAW — имеет.
вы имеете ввиду наверное что некое конкретное ПО может не обработать данный случай... но причем здесь сам raw файл ?
Z / V
> но ОНИ ИМЕЮТ НА ЭТО ПРАВО,
> но ОНИ ИМЕЮТ НА ЭТО ПРАВО, потому что они НИГДЕ не заявляли, что это TIFF
кстати а в чем должно состоять заявление что файл - tiff контейнерм, помимо следования стандарту насчет содержимого ?
Z / V
> DNG — адобовский формат
> DNG — адобовский формат
ну так как почти все raw форматы это tiff контейнер, то им можно и туда заодно !
Z / V
увидел что камеру (firmware)
увидел что камеру (firmware) будете... а если например в чем-нибудь фирменном типа Adobe DNG converter'е что-нибудь не так (случилась проруха) - будете писать им чтобы поправили или таки будете поддерживать (если вдруг нет) ?
Z / V
> И нет, всякое говно,
> И нет, всякое говно, которое придумало тип из головы - мы поддерживать не будем. Вот хочешь патч и собирай все сам, но и не более.
но вот если говно будет в firmware камеры то будете же, да ?
Z / V
смысл предположения - Adobe
смысл предположения - Adobe поди готовится полукадр использовать в DPraw CR2, ибо в нормальный DNG последние релизы их ПО (ACR, DNG converter) не конвертирует, а только в линейный - т.е. как и в ситуации с коррекцией оптики Panasonic'ом в RW2 готовится новая ревизия DNG стандарта (там тоже ACR/LR открывали или RW2 или линейный DNG вначале и конверсия была возможна из RW2 с тэгами коррекции оптики только в linear DNG)...
Z / V
там ссылка на один постинг в
там ссылка на один постинг в топике.
Z / V
из топика в dpreview - какая
из топика в dpreview - какая альтернативная теория почему новый DNG converter DPRaw в обычный raw не конвертирует, а в linear - да ? https://www.dpreview.com/forums/post/58388040
Z / V
> есть выбор камеры (или даже
> есть выбор камеры (или даже системы) и качество картинки играет не последнюю роль
и ? конвертер и вложенные туда человеко-часы (уже вложенные и в перспективе) тоже влияют и это нормально... поэтому совершенно незачем рассматривать камеру отдельно от...
Z / V
> Причем, в моем последнем
> Причем, в моем последнем абзаце (в посте) вообще написано только про пункт "в", крутим ручки - меняем результат.
так я и говорю - не надо озадачиваться вообще это проблемой - кому интересно пусть сами ручки крутят и сравнивают результат...
Z / V
> как __объективно__
> как __объективно__ сравнивать?
зачем ? большинство интересуется связкой : камера + конвертер/профиль... вот на своей любимой связке пусть и сравнивают сами... А страшно далеким от народа можно же и отдельно по каждому каналу
Z / V
как там называется компания
как там называется компания которая разбирает чипы под электронным микроскопом ? ChipWorks... разве они не разбирали подобные сенсоры уже ?
Z / V
а какой смысл складывать до
а какой смысл складывать до ADC ? выигрыш только за счет "аналогового усиления" за счет сложения на стоп перед ADC , но проигрыш в лишней схемотехнике в кремнии и для PDAF / DPRaw все равно надо вычитывать без сложения
Z / V
> Ну да. Но растут шумы
> Ну да. Но растут шумы чтения (читаем два раза, то есть в корень из двух, если они независимы)
а чем меньше емкость тем говорят (аптина -> новые сенсоры сони где часть емкости специально отключают) и шумы меньше ?
Z / V
точно, это я с утра не
точно, это я с утра не подумал сначала... мораль - пить кофей надо.
Z / V
> Возможно, верхний стоп (у
> Возможно, верхний стоп (у полупикселя) - настолько нелинеен
но тогда и целуй сенсель (получаемы сложением настолько нелинейных полусенселей) в верхнем стопе настолько же нелинеен, да ?
Z / V
а если еще на два какждый
а если еще на два какждый сенсель поделить то и +два стопа, и еще, и еще... малина !
Z / V
> но и обобщать на все DSLR
> но и обобщать на все DSLR не надо
я не обобщаю = я про именно себя лично писал... и dSLR были 5-10-12-14mp (ес-но в определенном диапазоне выдержек с рук, а вовсе не на 1/4000s) vs 42mp с EFCS сейчас...
Z / V
конкурировать с #3
конкурировать с #3
1) photomechanic не предлагает лучший просмотр raw на техническом уровне (где клиппинг, Зин ?) = плюс к FRV
2) photomechanic вроде бы предлагает более развитую систему отмечания файлов ключевыми словами = минус к FRV
3) photomechanic дороже (если покупать) чем FRV = плюс к FRV
4) они оба не предлагают посмотреть, а что же будет в вашем любимом конвертере = паритет
5) photomechanic уже имеет аудиторию которая его купила и привыкла = минус к FRV, сможет ли лучшее отображение технических деталей в raw привлечь аудиторию photomechanic'а ? тем более там наверняка многие просто снимают в камджпег
Z / V
конкурировать с #2
конкурировать с #2
1) они бесплатны (обычно) : решение = разумная цена
2) они смотрят тьму форматов : ну вот нам обещают tiff в v2
3) они в лучшем случае делают неконтролируемую конверсию raw = вот поэтому FRV этой аудитории мб полезен
Z / V
> Я вот не понимаю, почему не
> Я вот не понимаю, почему не надо в конвертере.
вопрос с кем FRV конкурирует и кому FRV продается
условно говоря (все IMHO отсюда и до забора)
1) пользователи LR, C1, Bridge/ACR - т.е. всего ПО где конвертер совокуплен с браузером, DAM, итд
2) пользователи FastStone, explorer (с кодеками), XnView, итд - т.е. где в худшем случае смотрится вложенный thumbnail, в лучшем происходит неконтролируемая конверсия raw
3) пользователи photomechanic'а - где упор на быстрое вбитие всяких ключевых словов и вообще надо успеть в прошлый выпуск новостей
Z / V
и ? я вот на той неделе (?)
и ? я вот на той неделе (?) увидел в rpp листе рассылки что штатные (внутри сборки которые) профили в RPP рассчитаны для гаммы 2.35 - но зуб (даже два!) даю что несколько лет назад они были для гаммы 2.36 Ё-) /хотя мб это была очепятка/ !
Z / V
> У меня например на всяком
> У меня например на всяком старье (Кодаки там Мамии всякие) никаких проблем нет с резкостью
А некоторые в интернетах утверждают что на вытянутой руке с 600mm обьективом с выдержкой в секунды снимают... и что это доказывает ? отсутствие shutter shock & mirror slap в соотв. диапазоне выдержек ?
Z / V
> В конвертере то можно
> В конвертере то можно разное увидеть, там столько кнопок!
именно - поэтому там можно увидеть конечный результат (но речь-то не про технический отбор кадров по экспозиции в raw каналах где frv вполне себе вне конкуренции)
Z / V
> На них ориентироваться -
> На них ориентироваться - имхо глупо
в случае если вы конвертируете именно в ACR (а именно об этом случае и речь - я же не призываю использовать bridge в случае другого конвертера) то ориентироваться на что-то другое бесмысленно... какая разница где, что и как можно сделать лучше если принято решение /не суть важно почему/ использовать ACR ?
Z / V
> то ведь, наверное, и
> то ведь, наверное, и проблемы отбора кадров по техническим же параметрам нету.
у меня нет проблем с экспозицией (спасибо в значительной части вам, авторам RD & FRV) и резкостью (спасибо EFCS & IBIS) сейчас по сравнению тем что было сколько-то лет назад с dSLR ( ужас, ужас что было внутри !!! ) - но отбирать-то надо и по тому что и кто и как в кадре и, повторюсь, по тому как __КОНВЕРТЕР__ отрабатывает в конечный результат да и вовсе не все конвертировать (я никогда не делаю batch)... и чем меньше сущностей тем лучше... т.е. поскольку я дожил то ситуации когда меня субъективно ACR устраивает уже больше года ( дополнительное спасибо Torger'у за dcamprof ), то Bridge/ACR/PS это мин. набор (PS это как среда плагинов для resize и sharp например) - если бы я например использовал RPP то был бы пожалуй FRV/RPP/PS... но так по сравнению с Bridge для рутинной работы преимуществ нет... и чем больше засад для конвертера o которых вы выше говорили - тем на самом деле еще больше среда именно конвертера лучше чем FRV ибо тем дальше то что вы видите в FRV от того что будет в итоге в конвертере, нет ?
Z / V
> А есть пример, где у Adobe
> А есть пример, где у Adobe клиппинг ниже, чем в FRV?
не понял вопроса ?
FRV с хорошей точностью покажет клиппинг в raw данные "в кадрe"/какие каналы... замечательно для освоения техники съемки с новой камерой, замечательно для отбора кадров для эксперимента (мишень там снимаем), неплохо для случаев брэкетинга...
но в условиях когда у меня dSLM (т.е. я при своих настройках параметров OOC JPG клиппинг в raw вижу в real time, не говоря у же о blinkies после снимка) с которой я провел много времени я серьезно не вижу особой нужды в FRV для отбора кадров из бытовой сессии ни на тему правильной экспозиции ни на тему резкости... я могу позволить себе подождать пока построятся preview конвертером для всей сессии... с другой стороны если бы я использовал регулярно что-то типа RPP или Iridient (vs например Bridge/ACR) то конечно FRV бы был ну очень хороший вариант (недаром я усиленно пытался перейти с XnView(MP) на FRV в этих целях... пока не стряхнул пыль с Bridge, который было заброшен мной на много лет).
Z / V
> Baseline exposure'
> Baseline exposure'
что опять же в DCP профиле это компенсируется соотв. тэгом - но, да для обладателей камер типа Fuji или использующих определенные номинальные ISO (ISO50 у Sony) при съемке в RAW мб небольшой геморрой - другой вопрос что их не надо использовать вообще
Z / V
> Вполне допускаю что для
> Вполне допускаю что для многих камер
а вот не надо иметь слишжком много разных камер :-)
Z / V
> подозреваю что шумодав
> подозреваю что шумодав/размыватель и шарп
ну тем более аргумент в пользу того что смотреть надо на конверсию конвертера, а не что FRV покажет :-)
Z / V
> Бридж (если файл не трогали
> Бридж (если файл не трогали) - это ж некая дефолтная ("все по нулям") настройка ACR?
да, но почему по нулям - не по нулям, а так как вы задали... я обычно запустив B, забираю все файлы в ACR (или прямо в Bridge через "Develop Settings") и применяю к ним желаемый рецепт, а потом "иду пить чай" пока оно занимается генерацией превью согласно рецепта... потом можно сделать тоже самое по большим группам файлов (например если кусок сессии происходил при недостатке освещения то применить к ним другой рецепт итд)... потом можно и заняться отбором уже окончательным... понятно что у Bridge есть свои недостаки по сравнению с интегрированными средами типа LR или C1 (и потом сам Adobe его не развивает) где например можно делать всякие виртуальные копии для различных вариантов итд... и понятно что вам возможно удобнее сначала сделать отбор без представления как оно потом в конвертере будет и потом заняться обработкой.... я же совмещаю кусками (что конечно может и не оптимально с точки зрения времени) - по сюжетам - и прореживание и конверсию
> Ну вот проблема же с этим в том, что вы не управляете тоновой кривой
какой именно (котарая задается вами "в UI" или в DCP профиле) и почему нет если я ее (обе) явно задаю ?
> и остается только молиться, что она не меняется с версией движка
вы же не утвеждаете что Adobe тайно (баги не в счет) манипулирует __такими__ вещами вне process 2003, process 2010, process 2012 ?
Z / V