"Отвечая на письма читателей..."
Вот фрагмент для исправления в справке программы:
G_TRC_New2=Min+(Max-Min)*[(( FN0-Min) +(FN - F0))/(Max-Min)]^G_TRC – вот и всё, что нам нужно сделать с данными из *.СRV1
Max – максимальное значение, взятое из канала цветности (из файла *.СRV1),
Min – минимальное значение, взятое из канала цветности (из файла *.СRV1),
G_TRC – по сути, наша целевая гамма из главного окна программы, которая и должна быть прописана в теге CRT профиля монитора *.icm, или же это значение может отличаться для каждой точки и берётся из табличного файла для каждого значения отдельно.
FN – данные LUT VA из файла *.СRV1
F0 – обнулённые данные LUT VA, из файла 0*.СRV1
Эта же ошибка заложена и в СLTest, но последняя не меняет крайние точки. От того картина получается следующая:
xTRC_CLTest.txt -> содержит значения G_TRC_New1
G_TRC_New1=MaxF*[( F0+(FN - F0))/MaxF]^G_TRC – согласно программы CLTest, где MaxF:=65535
Pr:=(FN - F0) – значение прироста, согласно программы CLTest
при этом формула имеет вид: Y=f[Maх*((Х+Pr)/Max)^Gamma]
Подробнее к чему приводит эта ошибка можно увидеть из иллюстрации ниже...
Из иллюстрации (красным) показана кривая тонопередачи красного канала, такая, какая она есть в LUT, с высветленными тенями. При пересчёте с ошибкой данные сохраняются, как показано на графике чёрной кривой (именно так считает сейчас СLTest, но его логика не трогает крайнюю точку, а только следующую за ней. К ошибке же это приводит при импорте кривой в программу CLTest и дальнейшем экспорте в *.icm, после правки. Своя логика в этом есть, если читать спецификацию тегов xCRV из ICC, но содержание при єтом нарушается. От того логика имеет место лишь для формата ICC, но не ICM, где скорректированное значение краёв диапазона должно храниться в тегах точки чёрного и белого). Но, кроме крайних значений при таком пересчёте искажаются и ряд промежуточных значений, что хорошо видно из иллюстрации, от того такой подход ошибочный. Эта же проблема незримо присутствует и в точке белого с учётом разрядности LUT, там кривая может упираться в конечное значение 65280 или 65535. Первое идёт по умолчанию в линеаризованной LUT, а вот второе это место для манёвра при правке точки белого, когда яркость увеличивается, но не финальная точка по умолчанию, что тоже ошибочно в ряде продуктов по визуальной калибровке, да и не только.
[ Продолжение... ]
Вот фрагмент для исправления в справке программы:
G_TRC_New2=Min+(Max-Min)*[(( FN0-Min) +(FN - F0))/(Max-Min)]^G_TRC – вот и всё, что нам нужно сделать с данными из *.СRV1
Max – максимальное значение, взятое из канала цветности (из файла *.СRV1),
Min – минимальное значение, взятое из канала цветности (из файла *.СRV1),
G_TRC – по сути, наша целевая гамма из главного окна программы, которая и должна быть прописана в теге CRT профиля монитора *.icm, или же это значение может отличаться для каждой точки и берётся из табличного файла для каждого значения отдельно.
FN – данные LUT VA из файла *.СRV1
F0 – обнулённые данные LUT VA, из файла 0*.СRV1
Эта же ошибка заложена и в СLTest, но последняя не меняет крайние точки. От того картина получается следующая:
xTRC_CLTest.txt -> содержит значения G_TRC_New1
G_TRC_New1=MaxF*[( F0+(FN - F0))/MaxF]^G_TRC – согласно программы CLTest, где MaxF:=65535
Pr:=(FN - F0) – значение прироста, согласно программы CLTest
при этом формула имеет вид: Y=f[Maх*((Х+Pr)/Max)^Gamma]
Подробнее к чему приводит эта ошибка можно увидеть из иллюстрации ниже...
Из иллюстрации (красным) показана кривая тонопередачи красного канала, такая, какая она есть в LUT, с высветленными тенями. При пересчёте с ошибкой данные сохраняются, как показано на графике чёрной кривой (именно так считает сейчас СLTest, но его логика не трогает крайнюю точку, а только следующую за ней. К ошибке же это приводит при импорте кривой в программу CLTest и дальнейшем экспорте в *.icm, после правки. Своя логика в этом есть, если читать спецификацию тегов xCRV из ICC, но содержание при єтом нарушается. От того логика имеет место лишь для формата ICC, но не ICM, где скорректированное значение краёв диапазона должно храниться в тегах точки чёрного и белого). Но, кроме крайних значений при таком пересчёте искажаются и ряд промежуточных значений, что хорошо видно из иллюстрации, от того такой подход ошибочный. Эта же проблема незримо присутствует и в точке белого с учётом разрядности LUT, там кривая может упираться в конечное значение 65280 или 65535. Первое идёт по умолчанию в линеаризованной LUT, а вот второе это место для манёвра при правке точки белого, когда яркость увеличивается, но не финальная точка по умолчанию, что тоже ошибочно в ряде продуктов по визуальной калибровке, да и не только.
[ Продолжение... ]
1
