Ищу велосипеды
Хочу несколько вещей реализовать, и по работе, и для своего ScanCombine. Найти их реализованными пока не смог, но может быть плохо искал, не по тем ключевым словам?
Первая - это хэш-функция для изображений, возращающая одинаковое значение только если изображения совпадают, хотя они при этом могут иметь разный формат как файла (tiff и png), так и пикселя (в одном RGB-значения, в другом палитра).
Это поможет надежно отработать систему древовидного Undo для ScanCombine, но и вне его может оказаться очень полезным.
Я пока натыкался на Perceptual image hash, это совсем другое, мне разница хоть на единичку в одном пикселе должно менять хэш-функцию.
В общем-то, ничего сложного в реализации нет - выбираешь наиболее общий формат пикселя (скажем, RGB-alpha, по 16 бит на каждый цвет на всякий случай), из любого другого формата превращаешь на ходу в него и делаешь что-нибудь вроде md5, вот и готово.
Хотя быстрее может оказаться пробегать по изображению и определять, какой минимальный формат из доступных нужен для его кодирования (градации серого или RGB, и сколько бит на пиксель, из удобных), и делать хэш уже от него. Т.е, если у нас изображение 1-битное (ч/б), тут уж дальше некуда, сразу же сделаем хэш. А если то же ч/б, но каждый пиксель кодировался как RGB 24 бита, то мы определим, что цвета всего два и это именно черный и белый, соотв. на лету превратим в тот же битовый поток и получим в точности тот же хэш. Хорошо оно еще и тем, что может расширяться другими форматами пикселя.
Вторая - математические операции над функциями, заданными сплайнами.
Есть у меня функция видности V(λ), показывающая чувствительность глаза к свету разных длин волн и определяющая, что такое люмены, канделы и пр. Она никакого математического выражения не имеет и задается таблицей.
И еще есть спектральная чувствительность матрицы σ(λ), которая тоже берется из даташита, сейчас я это делаю с помощью ImgGraph2Txt. Идея была такая: зачем хранить прорву точек, а потом ими постоянно ворочать - отмечу некие ключевые точки, увижу сам, что при интерполяции кубическими сплайнами кривая очень хорошо совпадет с исходной:
и тогда только эти точки я и сохраню, по ним всегда можно будет полную кривую восстановить.
То же самое сделано со спектром источника излучения I(λ).
Ну а дальше - собственно задача, имея перед собой эти кривулины, все табличные, быстро и точно посчитать что-то вроде такого:
Я реализовывал это, но криво: перемножал непосредственно табличные значения и потом их соединял кубическими сплайнами, но зачастую начинаются "высокочастотные пульсации", почти всегда вблизи нуля, иногда мне настолько "везет", что излучение некоторых спектров дает мне отрицательную освещенность! Тут надо действовать тоньше, найти такой набор точек, что полученные по ним сплайны очень точно аппроксимируют произведение двух исходных функций, причем желательно, чтобы этих точек было поменьше. Ясно, можно вернуться к линейной интерполяции и каждый отрезок делить пополам рекурсивно, пока не получим нужной точности, но это грубовато малость.
Первая - это хэш-функция для изображений, возращающая одинаковое значение только если изображения совпадают, хотя они при этом могут иметь разный формат как файла (tiff и png), так и пикселя (в одном RGB-значения, в другом палитра).
Это поможет надежно отработать систему древовидного Undo для ScanCombine, но и вне его может оказаться очень полезным.
Я пока натыкался на Perceptual image hash, это совсем другое, мне разница хоть на единичку в одном пикселе должно менять хэш-функцию.
В общем-то, ничего сложного в реализации нет - выбираешь наиболее общий формат пикселя (скажем, RGB-alpha, по 16 бит на каждый цвет на всякий случай), из любого другого формата превращаешь на ходу в него и делаешь что-нибудь вроде md5, вот и готово.
Хотя быстрее может оказаться пробегать по изображению и определять, какой минимальный формат из доступных нужен для его кодирования (градации серого или RGB, и сколько бит на пиксель, из удобных), и делать хэш уже от него. Т.е, если у нас изображение 1-битное (ч/б), тут уж дальше некуда, сразу же сделаем хэш. А если то же ч/б, но каждый пиксель кодировался как RGB 24 бита, то мы определим, что цвета всего два и это именно черный и белый, соотв. на лету превратим в тот же битовый поток и получим в точности тот же хэш. Хорошо оно еще и тем, что может расширяться другими форматами пикселя.
Вторая - математические операции над функциями, заданными сплайнами.
Есть у меня функция видности V(λ), показывающая чувствительность глаза к свету разных длин волн и определяющая, что такое люмены, канделы и пр. Она никакого математического выражения не имеет и задается таблицей.
И еще есть спектральная чувствительность матрицы σ(λ), которая тоже берется из даташита, сейчас я это делаю с помощью ImgGraph2Txt. Идея была такая: зачем хранить прорву точек, а потом ими постоянно ворочать - отмечу некие ключевые точки, увижу сам, что при интерполяции кубическими сплайнами кривая очень хорошо совпадет с исходной:
Click to viewи тогда только эти точки я и сохраню, по ним всегда можно будет полную кривую восстановить.
То же самое сделано со спектром источника излучения I(λ).
Ну а дальше - собственно задача, имея перед собой эти кривулины, все табличные, быстро и точно посчитать что-то вроде такого:
Я реализовывал это, но криво: перемножал непосредственно табличные значения и потом их соединял кубическими сплайнами, но зачастую начинаются "высокочастотные пульсации", почти всегда вблизи нуля, иногда мне настолько "везет", что излучение некоторых спектров дает мне отрицательную освещенность! Тут надо действовать тоньше, найти такой набор точек, что полученные по ним сплайны очень точно аппроксимируют произведение двух исходных функций, причем желательно, чтобы этих точек было поменьше. Ясно, можно вернуться к линейной интерполяции и каждый отрезок делить пополам рекурсивно, пока не получим нужной точности, но это грубовато малость.