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

Title	Comment
Не-не, дело не в снимках.	Не-не, дело не в снимках. Дело в том, что формат позволяет описать данные, про которые в описании формата не написано как их раскодировать (проблема именно в предикторе, который дельты пишет).
SubIFD, FILETYPE_MASK, один	SubIFD, FILETYPE_MASK, один бит на данные. Все уже есть без смешения.
Ну что — отказываться. Я не	Ну что — отказываться. Я не ожидаю, что FRV будет читать fMRI-снимки, например. Мне кажется — это нормально. В смысле, не работать со всем зоопарком.
Причем, если для 3xINT16 +	Причем, если для 3xINT16 + FP32 логичным было бы PLANARCONFIG_SEPARATE, это позволяет данные вменяемо(быстро) читать, то проблему Predictor это все едино не решает, ибо он един для всех Plane. Есть вменяемое решение в рамках TIFF, не несущее проблем с перемешиванием данных разной битности: SubIFD. А вот возможность перемешивания - добавлена а) зря, потому что она есть, а пользоваться ей таки нельзя нормально б) если уж добавили, то почему PHOTOMETRIC один на всех? Уж если делать с изумляющей гибкостью, то почему YRGB не разрешить заодно?
Результат для FRV на самом	Результат для FRV на самом деле такой, что я посмотрел в профайлер и для 8/16 битных (на компонент) Gray/RGB таки буду делать декодирование в RGBA руками, потому что это тихий ужас.
Потому что в слове TIFF -	Потому что в слове TIFF - вторая буква - I, а не D.
А глобально, конечно, если	А глобально, конечно, если это "некие семплированные данные", то положить их надо в HDF.
А вот у тебя три в INT16,	А вот у тебя три в INT16, один в FP32, Predictor=3. Что будем делать?
Так а в чём проблема в данных	Так а в чём проблема в данных если ты на секундочку представишь себе, что это вообще не картинка-для-смотрения-глазами? А некоторые семплированные данные. Которые вот естественно представлять как два набора синхронизированных, один в FP16 а другой однобитный, например. Или 3 в INT16 а один в FP32 (достоверность этого пикселя, предположим)?
В переносимом C коде?	В переносимом C коде? Совершенно не естественно. В FRV? Да, естественно. Ну, можно прикинуть какие 5-10 форматов поддаются очень крутой оптимизации и вставить special cases. Но начал бы я всё равно совершенно общего кода двух вложенных циклов (по пикселям и по компонентам) читающих покомпонентно. Но у меня ментальная модель софта другая — я никогда не писал FRV :-)
Ну не в данных же. В тегах.	Ну не в данных же. В тегах. Против этого я не возражаю.
Ну как бы тебе сказать.	Ну как бы тебе сказать. Вот есть, к примеру, float16. И вполне естественно применить _mm_cvtph_ps для его быстрого чтения. Если, конечно, оно не перемешано с однобитными....
Гибкости во всём теле. На	Гибкости во всём теле. На сколько я понимаю (помню свои исследования этих форматов лет 10 назад) там такое встречается.
Чему "этому"? Возможности	Чему "этому"? Возможности задать разный формат для sub-pixels?
И ещё одно: если бы мне надо	И ещё одно: если бы мне надо было написать читалку (но не писалку) TIFF'а, то для меня как инженера, самым очевидным решением было бы выделить один достаточный мне формат пикселя (ну там для экрана или для рассчёта — в зависимости от задачи, понятно) и после этого написать столько функций XXXBitsToSample() сколько допустимо SampleFormat в стандарте, диспатч-табличка, и после этого у меня естественным образом получилось бы читать любую мешанину. Для меня как-то это самый естественный способ запрограммировать такой формат. Да, в случае совпадения моего формата и формата файла это не самое эффективное, но так как всё равно II/MM (т.е. должны очень звёзды сойтись что бы было memcpy()), то и чёрт с нем.
А вообще, например,	А вообще, например, однобитная маска при 24 (3x8) битной картинке могла казаться привлекательной фичей во времена когда Aldus был Aldus'ом и самый большой винчестер был сколько там? Мегабайт 100?
Благодаря этому есть дофигища	Благодаря этому есть дофигища форматов которые не совсем простые картинки, которые внутр TIFF вот с такими разнообразными странностями, и спец-софт эти странности понимает (каждый софт одну определённую странность, конечно). GeoTIFF, всякие форматы медицинского и научного Imageing'а (МРТ, КТ, Рентген, дефектоскопия всякая), даже воксельные какие-то форматы. И всё - TIFF!
Так ведь других то нет.....	Так ведь других то нет.....
"Формат был разработан Aldus	"Формат был разработан Aldus Corporation в сотрудничестве с Microsoft" Это многое объясняет (если википузия не врёт). Мелкомягкие, похоже, вообще не способны сочинить что-то короткое и продуманное. Одна история со спецификациями на форматы ms office чего стоит. А что они у кого-то готовое покупают - неминуемо превращают в раздутое говнище.
Я, честно говоря, в шоке.	Я, честно говоря, в шоке. Ну то есть я сначала был в шоке от PNG/libpng, но шок от нее оказался меньше, чем от TIFF/libtiff.
"Какая гадость эта ваша	"Какая гадость эта ваша заливная рыба!"
Я честно скажу - файл	Я честно скажу - файл проверил и сразу снес обратно. Но вот то что заявлена обработка на видяхе - повод посмотреть когда-нибудь повнимательнее, я люблю такое.
Хм, типа, православный клон	Хм, типа, православный клон фотошопа? Ну хоть подписка недорогая.
Ух ты, открывает. С неверной	Ух ты, открывает. С неверной гаммой (профиль встроенный верный есть), но хотя бы читает.
Попробуйте этим: https:/	Попробуйте этим: https://alivecolors.com
Я, правда, схалявил - я взял	Я, правда, схалявил - я взял 24-битный декодер из DNG SDK, не сам писал. Так вот, и при попытке применить предиктор, и без нее - чушь вылазит. Остается конечно вариант, что внутри libtiff (ошибочно) применен какой-то предиктор, либо byteswapped.
Весело.	Весело.
Ну так 32 бита или все 64,	Ну так 32 бита или все 64, что экономить-то на временном файле? А по-хорошему, вообще через пайп. Но это фатастика, да.
Да-да, оно.	Да-да, оно. И вот тамошний FP24 - не раскодируется как написано.
Так не хранить (долго).	Так не хранить (долго). Intermediate между склейщиком и raw-проявщиком.

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

Pages