Удивительное рядом, но оно запрещено!

После всех копаний в спецификациях TIFF более всего мне нравится следующий момент:

Вот есть многоканальный (к примеру, RGB) TIFF, так и пишем, 3 значения на пиксель. Или вот 4, потому что Альфа-канал:

  | 5)  PhotometricInterpretation = 2 => RGB
  | 8)  SamplesPerPixel = 4 => RGB + Alpha (не пробовал, но поди можно и больше)
  | 19) ExtraSamples = 0 => Unspecified data т.е. "это не прозрачность"

Дальше для каждого из каналов задается его формат и битность:
  | 3)  BitsPerSample = 32 32 32 32
  | 20) SampleFormat = 3 3 3 3 (плавучка)

Возникает резонное вот предположение, что раз мы задаем это поканально,  то теоретически то можем иметь, скажем, Lab в котором L-канал 16-битный, а a/b каналы - 8-битные.

Но и это еще не все, можно иметь L в floating point, а каналы a/b - целые. Или не целые, а комплексные (SAMPLEFORMAT_COMPLEXIEEEFP)

Такой TIFF будет
а) корректным
б) насколько я насмотрелся на чужой код в последние дни, его НИКТО не прочтет, несмотря на корректность. Потому что, к примеру, и BitsPerSample и SampleFormat принято читать только первое значение, а не всю группу (и действительно, если все едино не умеешь читать микс FP/integer, так чего и париться). Другой вопрос, что наверное не очень то и надо, такой микс битности, даже если данные целые, читаться будет очень медленно, а микс представлений - так и вообще труба.

Вишенка на торте:

  | 17) Predictor = 3

Задается для IFD целиком. И таки что делать, если у нас смешанный SampleFormat?

Короче, если вдруг надо будет записать корректный (с точки зрения стандарта) TIFF, который не будет читаться нигде, так я знаю как.

UPD: ну конечно альфа-каналов можно сколько хочешь, фотошоп умеет:

  | 3)  BitsPerSample = 16 16 16 16 16
  | 8)  SamplesPerPixel = 5
  | 19) ExtraSamples = 0 0
  | 20) SampleFormat = 3 3 3 3 3

IrfanView показывает на таком файле (и на одном альфа-канале тоже) чорный экран.

Comments

"Какая гадость эта ваша заливная рыба!"

Я, честно говоря, в шоке.
Ну то есть я сначала был в шоке от PNG/libpng, но шок от нее оказался меньше, чем от TIFF/libtiff.

"Формат был разработан Aldus Corporation в сотрудничестве с Microsoft"
Это многое объясняет (если википузия не врёт).
Мелкомягкие, похоже, вообще не способны сочинить что-то короткое и продуманное. Одна история со спецификациями на форматы ms office чего стоит. А что они у кого-то готовое покупают - неминуемо превращают в раздутое говнище.

Так ведь других то нет.....

Благодаря этому есть дофигища форматов которые не совсем простые картинки, которые внутр TIFF вот с такими разнообразными странностями, и спец-софт эти странности понимает (каждый софт одну определённую странность, конечно).

GeoTIFF, всякие форматы медицинского и научного Imageing'а (МРТ, КТ, Рентген, дефектоскопия всякая), даже воксельные какие-то форматы.

И всё - TIFF!

Чему "этому"? Возможности задать разный формат для sub-pixels?

Гибкости во всём теле. На сколько я понимаю (помню свои исследования этих форматов лет 10 назад) там такое встречается.

Ну не в данных же. В тегах. Против этого я не возражаю.

Так а в чём проблема в данных если ты на секундочку представишь себе, что это вообще не картинка-для-смотрения-глазами?
А некоторые семплированные данные. Которые вот естественно представлять как два набора синхронизированных, один в FP16 а другой однобитный, например. Или 3 в INT16 а один в FP32 (достоверность этого пикселя, предположим)?

А вот у тебя три в INT16, один в FP32, Predictor=3. Что будем делать?

Причем, если для 3xINT16 + FP32 логичным было бы PLANARCONFIG_SEPARATE, это позволяет данные вменяемо(быстро) читать, то проблему Predictor это все едино не решает, ибо он един для всех Plane.

Есть вменяемое решение в рамках TIFF, не несущее проблем с перемешиванием данных разной битности: SubIFD.

А вот возможность перемешивания - добавлена
а) зря, потому что она есть, а пользоваться ей таки нельзя нормально
б) если уж добавили, то почему PHOTOMETRIC один на всех? Уж если делать с изумляющей гибкостью, то почему YRGB не разрешить заодно?

Может сжатие прилепили потом, в поздних версиях, и люди, которые не делали изначальные версии и проглядели?

В TIFF 6.0 предиктора для FP нету, только H/V differences

Ну то есть не исключено.

Ну что — отказываться. Я не ожидаю, что FRV будет читать fMRI-снимки, например. Мне кажется — это нормально. В смысле, не работать со всем зоопарком.

Не-не, дело не в снимках.

Дело в том, что формат позволяет описать данные, про которые в описании формата не написано как их раскодировать (проблема именно в предикторе, который дельты пишет).

Ну, ещё формат позволяет наверняка так налажать с сочетанием ширины, высоты, размера такйла и колчиества тайлов (лень смотреть все теги), что оно не сойдётся. Можно на это смотреть так, что формат описывает синтаксис. Семантический анализ никто не обещал. На C тоже можно написать программу, которая разберётся в AST но не скомпилируется дальше. Ну что уж...

Стандарт специфицирует, сколько записей в теге TileOffsets т.е. если их туда недоложить - это будет нарушением стандарта.

А глобально, конечно, если это "некие семплированные данные", то положить их надо в HDF.

Потому что в слове TIFF - вторая буква - I, а не D.

Ну вот это поняли и сделали HDF, но TIFF-то был раньше.

И я не удивлюсь, если в ментальной модели тех, кто основывал свои форматы на TIFF эти данные — картинка. Это естественно так думать. Для людей из соседней лаборатории — уже мешанина какая-то :-) (так же Image vs Picture)

Но, опять же, это не повод пытаться эти форматы читать в FRV. Быть единственным софтом на планете, который одновременно и запускается на Windows 10 и читает вот тот файл с 5.25" дискеты вон из той лаборатории — это, конечно, почётно, но стоит ли тратить на это силы?

У меня и в мыслях нет все TIFF-ы читать. Я даже FP24 (пока?) похерил.

А вообще, например, однобитная маска при 24 (3x8) битной картинке могла казаться привлекательной фичей во времена когда Aldus был Aldus'ом и самый большой винчестер был сколько там? Мегабайт 100?

SubIFD, FILETYPE_MASK, один бит на данные. Все уже есть без смешения.

И ещё одно: если бы мне надо было написать читалку (но не писалку) TIFF'а, то для меня как инженера, самым очевидным решением было бы выделить один достаточный мне формат пикселя (ну там для экрана или для рассчёта — в зависимости от задачи, понятно) и после этого написать столько функций XXXBitsToSample() сколько допустимо SampleFormat в стандарте, диспатч-табличка, и после этого у меня естественным образом получилось бы читать любую мешанину. Для меня как-то это самый естественный способ запрограммировать такой формат. Да, в случае совпадения моего формата и формата файла это не самое эффективное, но так как всё равно II/MM (т.е. должны очень звёзды сойтись что бы было memcpy()), то и чёрт с нем.

Ну как бы тебе сказать.
Вот есть, к примеру, float16. И вполне естественно применить _mm_cvtph_ps для его быстрого чтения. Если, конечно, оно не перемешано с однобитными....

В переносимом C коде? Совершенно не естественно.

В FRV? Да, естественно. Ну, можно прикинуть какие 5-10 форматов поддаются очень крутой оптимизации и вставить special cases. Но начал бы я всё равно совершенно общего кода двух вложенных циклов (по пикселям и по компонентам) читающих покомпонентно.

Но у меня ментальная модель софта другая — я никогда не писал FRV :-)

Результат для FRV на самом деле такой, что я посмотрел в профайлер и для 8/16 битных (на компонент) Gray/RGB таки буду делать декодирование в RGBA руками, потому что это тихий ужас.

А в свете новостей
"An innocent-looking image -- sent either via the internet or text -- could open your Android phone up to hacking. "While this certainly doesn't apply to all images, Google discovered that a maliciously crafted PNG image could be used to hijack a wide variety of Androids -- those running Android Nougat (7.0), Oreo (8.0), and even the latest Android OS Pie (9.0)," reports CSO Online."

FRV - нехорошие редиски могут хакнуть? :-)

Не храните в FRV пароли и данные о кредитных картах!

Мы используем libpng последней версии, насколько я вижу - у нее известных и опубликованных проблем на сегодня нет. Может быть чисто андроидная беда, например.