newart, а можешь такую картинку выложить? А то я долго искать буду...
newart, а можешь такую картинку выложить? А то я долго искать буду...
Спектрумист, более менее умеющий форматировать дискеты на реале.
Вот.
не тру! в прения вдаваться не буду.Сообщение от newart
давай подытожу тот топик, но только посредственно, чтоб только все в дальнейшем гибко делать.
надо осилить только вот что из конфига unreal speccy:
вроде бы не так много, вроде как все понятно?!!; palette format:
; name=ZZ,ZN,NN,NB,BB,ZB:R11,R12,R13;R21,R22,R23;R31 ,R32,R33
; where ZZ,NN,BB - bright levels for black,normal,and bright colors
; ZN,NB,ZB - bright levels for zero+normal, normal+bright, zero+bright for GIGASCREEN and FLASH-COLORS
; Rnn - matrix for post-processing:
; real_Red = (Red*R11 + Green*R12 + Blue*R13) / 0x100
; real_Green = (Red*R21 + Green*R22 + Blue*R23) / 0x100
; real_Blue = (Red*R31 + Green*R32 + Blue*R33) / 0x100
если же пытаться объяснить описание палитры:
то получается: R11,R12,R13 - описывают красный цвет, R21;R22;R23 - зеленый, и R31,R32,R33 - синий, как это прикрутить надеюсь разжевывать не надо?; name=ZZ,ZN,NN,NB,BB,ZB:R11,R12,R13;R21,R22,R23;R31 ,R32,R33
английский "родной"? соответственно: color/256*bright level=real color. это надеюсь тоже понятно.ZZ,NN,BB - bright levels for black,normal,and bright colors
для гигаколоров цвет получаем (color1+color2)/2=colorn, осталось домножить на уровень брайта. их в гиге больше не 2(on|off)+черный как для стандарта, добавляются еще брайт. для сочетаний: черный+ноубрайт (1+2 скрин) - ZN, ноубрайт+брайт (1+2 скрин) - NB, черный+брайт (1+2 скрин) - ZB. результирующий: colorn/256*bright level=real color.
если все это понятно останется только прикрутить вот эти 3 основные палитры:
на всякий случай держать их в таком же виде, чтобы легко можно было все подкорректировать и быть может вставить поле для ручного ввода такой последовательности, что очень просто.Код:alone=00,60,A0,E0,FF,A0:FF,00,00;00,FF,00;00,00,FF pulsar=00,76,CD,E9,FF,9F:FF,00,00;00,FF,00;00,00,FF orthodox=00,76,CD,E9,FF,9F:D0,00,00;00,E4,00;00,00,FF
если не все понятно стоит немного подумать...
когда это прикрутишь... думаю есть шанс что зантересуется риска, тогда надо будет для режимов х2, х3, х4 прикручивать фильтры (черезстрочник, блур...) потом надо будет все делать еще и для мультигиги... ладно ты хотя бы это осиль! чтоб хоть немного твой проект стал интереснее.
Последний раз редактировалось pulsar; 25.09.2009 в 20:09.
pulsar, спасибо. Повникал в твой пост, стал больше понимать в вопросе. После выходных выберу время, повникаю еще, и все равно буду спрашивать.
Спектрумист, более менее умеющий форматировать дискеты на реале.
Я уже несколько раз этот вопрос поднимал, но моего знания матчасти не хватает.
Имхо, в этой формуле расчета что-то неверно:
real_Red = (Red*R11 + Green*R12 + Blue*R13) / 0x100
Объясню почему. В случае спектрумовского ярко-красного цвета мы получим такие значения:
real_Red = (0xFF*0xFF + 0 + 0) / 0x100
real_Red = 0xFE (после округления)
Но ведь #FE - это не #FF, который задумывался для R-канала.
но именно по этой формуле считает анрил! возьми скинь скрин и померяй "пипеткой" и ты получишь fe вместо ff. что уже не плохо, хоть расчетная формула соответствует реализации.
насколько плох результат?! вот для примера:
на тему такой уж глобальности ошибки с ff|fe ^^^ (без "пипетки" кто-нибудь мне может сказать наверняка какая половинка картинки темнее? я нет! или у меня глаза кривые, или мон такой, на такую погрешность кладет, хз). на самом то деле конечно в формуле (зачем уж она составлена именно так как она уже долгие годы есть я не знаю, надо спрашивать автора - smt...) просматривается системная ошибка ведь если к примеру взять:
получим: color=#17e, да, если кто читал конфиг анрила:Код:color=(#ff*#80+#ff*#80+#ff*#80)/#100
берем младшие 8 бит (в лучшем случае). так что вместо #80, получаем #7e, что в принципе приводит к ошибке немного превышающий 1%("на глаз" ошибку уже видно - проведите эксперимент...), что на мой взгляд тоже не так страшно! ведь при составлении палитры скажем значение яркости имеет существенное значение только при изменении на 5-10%, к тому же ошибка почти глобальная и почти всегда приводит к простому декременту задуманного значения (хотя есть и исключения, смотри выше).Код:; note: emulator uses 8-bit precision for color components, ; 8-bit filters: use 6 bit precision (VGA palette limitation) ; overlay & hi-color: truncates results to 5 bit ; true color: no quality loss
на всякий случай приведу нормальную формулу, "состряпал", ее быстро почти не проверяя, быть может smt просто так же поступил? может где-то и ошибся... у меня получилось вот что:
тогда не придется даже выделять младшие 8 бит, тк больше 8 бит результат никогда не получится.Код:color_x=(#ff*xr+#ff*xg+#ff*xb)/#2fd
хочу однако предостеречь от холиваров! не знаю почему все так сделано в анриле! не знаю... да и это не столь существенно на мой взгляд! ведь в общем случае эта ошибка не превышает даже 1% и на глаз не заметна (смотри картинку выше). и еще, в том же спектакуляторе ярко белый это f8f8f8, во fuse ffffff, в анриле fefefe. так что все равно к общему знаменателю не придем. можете конечно проверять мою "правильную" формулу, если все правильно и есть уж очень большое желание можно попытаться попинать того кто сейчас клепает анрилы чтоб он это исправил, и скажем, в дальнейшем везде использовать эту формулу. но, имхо, ошибка такая старая и такая не значительная. не стал бы так беспокоиться.
истина ради истины... хотя конечно в последствии не стоит наверное наступать на теже грабли!!? правда еще раз повторюсь я хз зачем smt написал формулу именно так, может это была не ошибка? хотя, все же, скорее всего ошибка...
Последний раз редактировалось pulsar; 26.09.2009 в 11:27.
С любовью к вам, Yandex.Direct
Размещение рекламы на форуме способствует его дальнейшему развитию
попробуй реализовать. если реализуешь как надо, и со временем добавишь мультигигу (а без нее, теперь уже, смысла подобных проектов уже почти не вижу!) подкину еще одну отличную идею. а пока тебе и так хватает над чем работать.
Думаю, правильно так:
По идее, это как раз простое смешивание цветов.real_Red = (Red*R11 + Green*R12 + Blue*R13) / (R11+R12+R13)
real_Green = (Red*R21 + Green*R22 + Blue*R23) / (R21+R22+R23)
real_Blue = (Red*R31 + Green*R32 + Blue*R33) / (R31+R32+R33)
Коэффициенты матрицы нормированы.
Переполнения не будет ни при каких входных RGB.
Потери точности тоже не будет.
С математической точки зрения - все отлично.
Что и показано на частном случае здесь:
Но если pulsar имел в виду
real_Red' = (Red*R11 + Green*R12 + Blue*R13) / (#FF+#FF+#FF)
то это неправильно. Переполнения конечно не будет, но мы получим "ослабление" цвета.
Например, real_Red' = (#FF*#FF + 0 + 0) / #2FD = #55.
А чтобы формула стала совсем идеальной, можно перед делением к числителю добавить половину знаменателя, то есть округлить результат по правилам математики.
Итого:Что касается оригинальной формулы:Sr = (R11+R12+R13);
real_Red = (Red*R11 + Green*R12 + Blue*R13 + Sr/2) / Sr;
Sg = (R21+R22+R23);
real_Green = (Red*R21 + Green*R22 + Blue*R23 + Sg/2) / Sg;
Sb = (R31+R32+R33);
real_Blue = (Red*R31 + Green*R32 + Blue*R33 + Sb/2) / Sb;
Возможно, он все-таки нормировал коэффициенты матрицы перед использованием, просто в комментах этого не указал.
Например, так:
R11 = R11*#100/(R11+R12+R13)
На это сможет ответить тот, кто разбирался в исходниках.
EEA, привет, друг!
почитал то что ты по навоял, у меня после твоего сообщения пока больше вопросов чем ответов, пока некогда особенно все раскручивать, вечером приду возможно подобью всю концепцию. а пока разберитесь, что такое Red Green Blue в формуле и почему при такой палитре (не важно, что она не правильная! зато помогает понять, что такое Red Green Blue):
получаем такую картинку:Код:=00,76,CD,E9,FF,9F:80,80,80;00,FF,00;00,00,FF
Буквально позавчера встал вопрос, как перетащить кучу своей графики в png...
Уже на данном этапе вещь нужная и полезная! Однако при первом же тесте появились непонятные артефакты (в виде черной однопиксельной полоски) с правой стороны экрана на некоторых картинках. Глюк самого конвертора, поскольку и в обычном режиме и в режиме пакетной обработки экраны получаются одинаковыми. Прикрепил к этому сообщению пару примеров, смотри сам.
+ Обязательно нужно добавить border! Просто сделать дополнительной опцией для выбора (on/off). Некоторые работы изначально задуманны под его определенный цвет.
Успехов!
Ждем следующую версию!
Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)
Ваши права
Ответить с цитированием
