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

Title	Comment
перенес... и в отличии от	перенес... и в отличии от исходного пц созданные x-transformer'ом DNG в гриде не показываются (приходится ручками refresh)... разница на первый взгляд - в исходном пц каталог сидел на hdd, теперь на ssd ... куда бежать ? на всякий случай "EnableAllDrivesMonitoring.reg" применил - не помогло
Это больно.	Это больно. Но честно. My kudos.
Ну, он это делает для	Ну, он это делает для поддерживаемых камер же, а не для любых RAW. libraw тоже всё читает — зачем вы написал libraw если всё читает libtiff? Можно было просто libdemosaic написать :-) А вы, глупые, мучаетесь!
Слава богу, не все	Слава богу, не все программисты у производителей фотоаппаратов на столько криворукие :-) Это радует. Но легче вашу жизнь не делает.
Вот ровно это (не совсем	Вот ровно это (не совсем ровно, конечно, но по смыслу - очень близко) делает DNG Converter (+ еще упаковку собственно raw-данных меняет с приватной на человеческую). И, гм, все работает более-менее.
Таких, кстати, будет тоже	Таких, кстати, будет тоже довольно много.
Я считаю, что что бы считать	Я считаю, что что бы считать файл TIFF'ом, он должен отвечать условиям не только «прочли IFD и не отругались» но и условиям «Отсортировали все IFD и внешние блоки данных как захотели, записали назад и всё работает». Из-за криво сделанных MakerNotes это не так, что и делает RAW не TIFF'ом а чем-то, что чисто по удаче читается libtiff'ом.
Ну ты же понимаешь, что это	Ну ты же понимаешь, что это иллюзия. Если бы читал — то по его выводу можно было бы восстановить валидный CR2 файл. Обратно собрать теги, записать в файл. Но ведь если и удастся то только по удаче, если все приватные блоки в те же места попадут. А если нет — то TIFF будет «валидный» а CR2 — уже нет. Значит CR2 — не TIFF. Если бы CR2 был TIFF'ом, то он не ломался бы от любых преобразований, которые не ломают TIFF и не теряют tag values.
Собственно, а что оно может	Собственно, а что оно может прочесть, кроме структуры IFD (правильная) и списка известных ей тегов (корректные)?
Ну вот взял на сон грядущий	Ну вот взял на сон грядущий CR2 от Canon 1Dx. Tiffdump читает, не ругается.
Т.е. именно потому что так,	Т.е. именно потому что так, судя по твоим рассказам, делают, я и говорю, что RAW — не TIFF и libtiff на самом деле НЕ ПРОЧТЁТ RAW, хотя сделает вид, что прочла. Но нет, это иллюзия.
Все offset в private data	Все offset в private data должны быть внутрь их же. Мне трудно себе представить, чем и как надо думать, делая расширение TIFF где есть кросс-ссылки из бинарных блоков в другие бинарные блоки, которые (бинарные блоки) с точки зрения стандарта TIFF будут независмыми элементами данных.
Ты же в чужих private data не	Ты же в чужих private data не знаешь, что offset, а что - просто значение.
А класть оффсеты на внешние	А класть оффсеты на внешние блоки, описанные другими тегами, — это уж точно полный идиотизм. Какой-то запредельный.
Ну вот я и говорю — им	Ну вот я и говорю — им насрать на экосистему. Или просто идиоты (не объяснять злонамеренностью и всё такое). Относительные должны спасать, их же можно релоцировать.
Тем не менее - кладут. Даже	Тем не менее - кладут. Даже если оффсеты относительные - это не спасет.
Ничто не мешает, Count = XXXX	Ничто не мешает, Code = 0xZZZZ, Count = XXXX, Type = BYTE, Offset = 0xYYYY, это нормально копируется в соседний файл, перепаковывается, сохраняется, что угодно. Если ты ВНУТРИ этих XXXX байт вдруг положил важные для тебя АБСОЛЮТНЫЕ оффсеты — ну, ты ИДИОТ. (понятно, что «ты» здесь — не Алексей Тутбалин).
Кто запрещает положить	Кто запрещает положить private data в какой-нть private tag целиком? Не SubIFD, а вот просто "вот бинарный массив"?
При чём тут EXIF? Это	При чём тут EXIF? Это стандарт TIFF, он общий для EXIF, XMP, Makernotes. Если мы заявляем что мы TIFF, стандартный, то обязаны делать такой файл, что бы условный libtiff мог перепаковывать все данные не ломая их (но и возможно не понимая). Но просто RAW — не TIFF и никто и не обещал. Опять же, потому что на экосистему авторам насрать.
EXIF - да. А Makernotes - это	EXIF - да. А Makernotes - это ж поди UNDEF какой-то большой длины.
Это какое-то очень	Это какое-то очень неправильное прочтение стандарта. В стандарте сказано, что там должны быть tags как и в стандартной IFD, только их codes живут в собственном пространстве имён и не требуют регистрации в Adobe. Т.е. Private IFD должна быть валидной IFD, просто Code могут значить другое. Но это не значит, что она может быть в произвольном формате.
То есть это вот ровно та же	То есть это вот ровно та же проблема, но уже в рамках одного XMP.
О, да, есть.	О, да, есть. Поэтому вот FRV пишет crs:exposure и libraw:exposure. А потом мы редактируем это в ACR, оно меняет crs: но не трогает libraw: естественно.
На самом деле, конечно,	На самом деле, конечно, цветовые данные и Orientation - это единственная серьезная проблема для показа. Остальное можно пережить.
А еще может быть ICC-профиль	А еще может быть ICC-профиль в EXIF и ICC-профиль в APP (это старый стандарт, до JPEG/EXIF). И при этом, я вроде никогда не видел (особо и не искал, впрочем) ICC в EXIF. И при этом вполне может быть JPEG(+ICC) aware program, которая не EXIF-aware.
Оно на то и private, что ты	Оно на то и private, что ты не знаешь что в них.
В XMP есть неймспейсы. В	В XMP есть неймспейсы. В общем, это всё можно аккуратно разрулить, если захотеть. Не захотели.
Ну вот и как они приняли	Ну вот и как они приняли такой стандарт без описания приоритетов?! :-) После этого от остальных как-то даже неловко требовать!
Сложно так сделать. Потому	Сложно так сделать. Потому что XMP бывает и в PDF (где, AFAIK, не бывает EXIF) Не говоря о том, с чего все начиналось, о sidecars.
Ну, если Private Data	Ну, если Private Data сохраняют формат IFD, т.е. являются той же табличкой, то их можно переносить правильно, интерпритируя, так как IFD хранит типы данных (!). Но, видимо, много кому было лень делать так и в результате эти Private IFD — и не IFD вовсе.

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

Pages