Speccy online tools

[pulsar]

Бордер такая вещь что добавить его раз плюнуть, а вот убрать уже не так то просто. Отсюда и такое мое к нему отношение.

раз плюнуть говоришь?! миллион криворуких найдется! и бордер будет похерен и велосипедов на изобретают, так что... а так на уровне конвертера половина проблем решиться, а для гуру и фанатиков функция все решит. да, и славка про то, что бордер сложно удалить - пускай nyuk в человеческий вид все приведет потом еще одну идею выскажу... не приведет, ну, значит и не надо, не доросли пока значит (если останется в таком виде примерно как сейчас я первым же противником проекта стану, да и не найдет, очень рассчитываю, тогда широкого применения и загнется слава богу - нестандарты с велосипедами не нужны по определению!). СЛАВКА, и ты здесь не один слава богу! если бы не твой один из первых постов где ты как всегда рубанул с плеча, - я бы и участвовать не стал!

Но не всем картинки нужны для сайтов...

не всему вебу нужна безбордюрная графика!

тем более, что у спека ЕСТЬ бордюр и заранее лишать его НЕЛЬЗЯ!

Не знаю, как остальные, а я не представляю спектрумовскую графику без него.

для фанатов безбордюрных картинок надо сделать функцию...

читай. а дальше лесом! и спорить тут больше не вижу смысла.

---------- Post added at 01:35 ---------- Previous post was at 01:24 ----------

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

---------- Post added at 01:49 ---------- Previous post was at 01:35 ----------

не даст ожидаемого эффекта (ослабления каналов R и G).

блин, расходиться начинаю, скоро держать меня надо будет! ведь работает в анриле нормально! раз работает так и надо думать в направлении его математики (в код может быть лезть), а не городить... жень, прости, просто серьезно - лучше лишнего не писать. есть желание, говорю, так возьмись посчитай по человечески без абы да кабы! чтоб все как часики все примеры и контр примеры... все сюда больше не пишу ничего кроме нормальной математики. надоело, сколько можно?!.

[Advertiser]

[nyuk]

Бордер по люьому буду делать опцией.
Про "Grey" палитру как раз только что сам догадался :-)

[EEA]

прости, пока толком не вникал в твои выводы, но пока складывается устойчивое впечатление, что ты исходя из нормального посыла изначально, ведешь нас как сусанин в другую степь! ты немножко как я понимаю изначально не совсем в тематике (прости если обидел - но согласись изначально это так).

Ну вообще я изначально отвечал на это:

Я уже несколько раз этот вопрос поднимал, но моего знания матчасти не хватает.
Имхо, в этой формуле расчета что-то неверно:

Насчет в теме/не в теме: этот топик прочитал, два другие с обсуждением количества цветов и как смешивать тоже. Наверное всё-таки немного в теме.

ну так вот изначальный пасыл должен быть не в том чтобы разработать новую более грамотную модель расчета! нет вовсе нет! нужно всего лишь четко выстроить схему работы расчета сто лет назад реализованного в unreal by smt БОЛЬШЕ НИЧЕГО НЕ НАДО!

"Выстроить схему работы расчета" говоришь? Пожалуйста.
Unreal считает в точности по формулам, которые записаны в его ini-шнике (которые ты указал в своем первом посте здесь).
Я это проверил по запощенному тобой скриншоту с "кривой" палитрой.
(Видимо, зря потратил время.)

Цвета на картинке при заданной палитре в точности совпадают с расчетными по формулам из Unreal'а.

Значения ZZ,ZN,NN,NB,BB,ZB не вычисляются, а задаются палитрой.

если есть желание и время построить всю математику... пожалуйста все карты в руки! только не надо на 10 листов размазывать в одном посте выложите всю математику того как оно есть на самом деле в анриле (с примерами и контр примерами) и только после того как будет доказана правильность математики, уже только тогда можете пытаться искать ошибки и исправлять их, а не сейчас.

См. выше. Как считает Unreal - 100% понятно.

А ошибки в Unreal я и не собирался искать. Просто написал, как можно считать, чтобы избежать переполнения, чтобы не получалось #FE вместо #FF и чтобы минимизировать ошибку округления. И всё. Может кому пригодится.

где-то выше я приводил формулу, якобы правильного расчета, ну так вот, с самого начала я призывал за нее цепляться как за истину в последней инстанции! она кстати не верна в корне.

блин, расходиться начинаю, скоро держать меня надо будет! ведь работает в анриле нормально! раз работает так и надо думать в направлении его математики (в код может быть лезть), а не городить... жень, прости, просто серьезно - лучше лишнего не писать.

ОК. Как скажешь.
Больше тратить время, городить и писать лишнего на 10 листов не буду, благо есть чем заняться более полезным.

[moroz1999]

Бордер такая вещь что добавить его раз плюнуть, а вот убрать уже не так то просто. Отсюда и такое мое к нему отношение.

Предлагаю такую концепцию:
1. Картинки хранятся в оригинальном виде.
2. У каждой картинки ручками может быть введен цвет бордюра и, если необходимо, формат (gigascreen/monochrome/flash-effect)
3. У каждого пользователя есть настройки - любимая палитра, показывать/скрывать бордюры, мигать/смешивать gigascreen и flash-эффект.
4. Эти настройки так или иначе передаются в скрипт, отвечающий за выдачу картинки.
5. Скрипт берет настройки, шерстит кэш, при необходимости генерит недостающий вариант и отдаёт конкретному юзеру желаемый им вариант автоматом!

И никаких холиваров - все довольны. Почти реализовал это у себя. Доделаю альфа-версию проекта - покажу подробнее.

[pulsar]

Предлагаю такую концепцию:
1. Картинки хранятся в оригинальном виде.
2. У каждой картинки ручками может быть введен цвет бордюра и, если необходимо, формат (gigascreen/monochrome/flash-effect)
3. У каждого пользователя есть настройки - любимая палитра, показывать/скрывать бордюры, мигать/смешивать gigascreen и flash-эффект.
4. Эти настройки так или иначе передаются в скрипт, отвечающий за выдачу картинки.
5. Скрипт берет настройки, шерстит кэш, при необходимости генерит недостающий вариант и отдаёт конкретному юзеру желаемый им вариант автоматом!

И никаких холиваров - все довольны. Почти реализовал это у себя. Доделаю альфа-версию проекта - покажу подробнее.

фак, фак, фак... ой какой молодец (мега уважуха), аж события поторопил, я это только еще в будущие планы закладывал:

подкину еще одну отличную идею.

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

пускай nyuk в человеческий вид все приведет потом еще одну идею выскажу...

отлично! ладно, если суть идеи почти озвучена доскажу ее до конца:
1. не надо хранить картинку на сервере конвертера!
2. конвертер в идеале должен быть яваскрипт/ява/флэш компонентом догружаемым в любую веб страницу
3. скрипту ^^^ передается урл на стандартный спековский скрин (scr, img, mg(x)), скажем линк на палитру (так оно лучше, чем передавать строку с палитрой тк можно будет свичить прямо на лету в нужную палитру), параметры фильтрации (зум, блур, интерлейз, бордюр (хотя в mg(x) он и так встроен в картинку))

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

---------- Post added at 01:52 ---------- Previous post was at 01:44 ----------

ладно раз нарушил собственное же обещание:

все сюда больше не пишу ничего кроме нормальной математики.

и не смотря на 2 часа ночи на часах, придется забросить это гиблое дело со сном и таки подбить окончательно математику с логикой, что бы уже было все как надо, все понятно, все равно у меня картина почти полная сейчас вырисовалась. сейчас придется еще убить время на описание и на приведение в систему и надеюсь таки сегодня закрою этот вопрос тогда.

[nyuk]

Так и не уяснил до конца, откуда берется третье состояние яркости. Про два понятно (6-й бит атрибута). Посмотрел исходники moroz1999, там уровень ZZ используется если для получаемого реального цвета нет такого же исходного компонента. Иначе используется NN или BB в зависимости от уровня яркости атрибута.
Блин, не могу сформулировать, в общем к примеру для темно-красного (#02):

real_Red = (NN*R11 + ZZ*R12 + ZZ*R13) / #FF

Для ярко-желтого (#46):

real_Red = (BB*R11 + BB*R12 + ZZ*R13) / #FF

Я правильно понял?

Перенес функции generateColors и generateGigaColors цветов себе практически без изменений. Возникла проблема переполнения цвета на палитрах "Mars" и "Ocean" из unreal.ini. Поправил формулу по способу EEA:

Sr = (R11+R12+R13);
Sg = (R21+R22+R23);
Sb = (R31+R32+R33);
S = max(Sr, Sg, Sb);
real_Red = (Red*R11 + Green*R12 + Blue*R13) / S
real_Green = (Red*R21 + Green*R22 + Blue*R23) / S
real_Blue = (Red*R31 + Green*R32 + Blue*R33) / S

Переполнение исчезло. Кстати для палитр "pulsar" и "alone" разницы никакой, т.к. там S=0xFF

В общем, вылил всё на сайт, можно тестить. В обычном экране цвета похожи на Unreal, но если померять пипеткой, чуть-чуть отличаются. Посчитал на калькуляторе, вроде у меня по формуле все...

Гигаскрин заметно светлее, чем в Unreal, возможно там я совсем ничего не понял.

Еще поправил ошибку с последним столбцом пикселей, остальное позже.

Потестировал гораздо хуже, чем предыдущую версию, так что ошибки должны быть. :-)

[pulsar]

ват ви хэв ~ в чем суть?
предлагаю рассматривать все на основе палитры:

pulsar=00,76,CD,E9,FF,9F:FF,00,00;00,FF,00;00,00,FF

откуда я ее взял? при желании найдете (обсуждали мы тут ее с полтора года назад... ссылок больше не даю ибо ламеры по ним все равно не ходят (задолбали!), а кому надо и без мой помощи во всем разберется). ну так вот взял ее потому как она почти самая удобная получается (все значения цветов максимально просты - #FF), а все яркости различны (но рассуждение будет справедливо пожалуй для любой палитры, а иначе зачем это все надо вообще?!.), в отличии от палитры:

alone=00,60,A0,E0,FF,A0:FF,00,00;00,FF,00;00,00,FF

вообще она ^^^ самая странная и не адекватная как сегодня при новом рассмотрении оказалась, в сравнении с остальными:

Mars=00,80,C0,E0,FF,C8:FF,00,00;40,C0,00;00,40,C0
Ocean=20,80,A0,C0,E0,A8:D0,00,30;00,D0,30;00,00,FF
Grey=00,80,C0,E0,FF,C8:49,92,24;49,92,24;49,92,24
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
pul=80,76,CD,E9,FF,9F:80,80,80;00,FF,00;00,00,FF
ATM=00,55,AA,E0,FF,80: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

обратите внимание на 3 и 6 компоненты яркости и все станет ясно, имхо палитра alone, хуже всего подходит для гига и мультигига графики, и тому целый ряд причин, ну да ладно бог с ней мы не ради этого собрались.

перепишем палитру в удобной для разговора форме:

       ZZ,ZN,NN,NB,BB,ZB:R1,R2,R3;R4,R5,R6;R7,R8,R9
pulsar=00,76,CD,E9,FF,9F:FF,00,00;00,FF,00;00,00,FF

; where ZZ,NN,BB - bright levels for black,normal,and bright colors
; ZN,NB,ZB - bright levels for zero+normal, normal+bright, zero+bright

надеюсь никто не против что я так с коэффициентами поступил (как говорится от перестановки...)?! сразу тогда расчетные формулы перепишу чтоб все понятно было (классику с новыми коэффициентами):

;  real_Red    = (Red*R1 + Green*R2 + Blue*R3) / 0x100
;  real_Green  = (Red*R4 + Green*R5 + Blue*R6) / 0x100
;  real_Blue   = (Red*R7 + Green*R8 + Blue*R9) / 0x100

формулы абсолютно нормальные рабочие все отлично, жень, ты прав:

Unreal считает в точности по формулам, которые записаны в его ini-шнике (которые ты указал в своем первом посте здесь).
Я это проверил по запощенному тобой скриншоту с "кривой" палитрой.

прости меня дурака!..

ладно, поехали дальше. цветовую логику заметили? надеюсь да.

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

real_Red    = (CD*FF + CD*00 + CD*00) / 0x100

в результате мы и получаем то что и должны CC. можно будет померить - в аттач положу пару картинок в нужной нам палитре проверяйте. что откуда взялось думаю понятно? CD - это NN (яркость раз мы ее такую выбрали для примера). для остальных составляющих (green, blue) получим по 0, только не за счет составляющих R4-R9 которые у нас никуда не могут исчезнуть а за счет того, что яркостная компонента в формуле берется ZZ! хочу обратить на это особое внимание! все нужно делать правильно!

еще момент, что такое белый цвет? это 111 в бинарнике, ну так вот черный цвет это тоже 111 в бинарнике только в формулу яркость подставляется ZZ! надеюсь это очевидно! и на этом тоже заостряю особое внимание это тоже очень важно.

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

тогда идем в два экрана. кладу второй скрин в аттач.

пускай будет тоже красный цвет на одном экране и тоже не яркий тогда формула:

real_Red    = (76*FF + 76*00 + 76*00) / 0x100

равно 75 все понятно?! надеюсь да - имеем ZN тк на одном скрине у нас не яркий красный на втором черный. если будет яркий будет соответственно ZB. что если два не ярких красных? логично! NN:

real_Red    = (CD*FF + CD*00 + CD*00) / 0x100

когда получится NB, BB уверен, - ясно!? черный в гиге получаем аналогично одному экрану.

все если не ошибаюсь осталось рассмотреть для гиги еще только один показательный случай. смешаем к примеру не яркий синий с ярким фиолетовым, тогда для красной составляющей получим 75, справитесь?! думаю да, а иначе что вы тут делаете!? а вот по синей будет E8, надеюсь тоже объяснять не придется!

в общем все, хз все разжевал дальше не куда... просто ужас как... лучше только лично на примерах с глазу на глаз мог бы объяснить. так что не знаю надо ли еще этот вопрос еще трогать или нет, ну разве что я где-то по времени суток накосячил... ну да завтра все проверю!

[pulsar]

хотел было еще написать как правильно нормировать цвета, но уже и так не успел... ты раньше закончил чем я дописал.

гигу удобно проверять приаттаченым файлом (создавался в году так 2003м).

---------- Post added at 03:31 ---------- Previous post was at 03:17 ----------

В общем, вылил всё на сайт, можно тестить.

первые тесты - "отличная работа"! завтра еще потестирую, глядишь и не я один. если все ок ждем бордер и затем мультигигу. далеше горизонт moroz1999, и я нарисовали...

---------- Post added at 03:36 ---------- Previous post was at 03:31 ----------

палитры Mars, Ocean можно бы вроде и выкинуть... ну да ладно больше не меньше, там разве что еще так и для ручного ввода останется только что то предусмотреть (но с этим лучше не спешить) слишком много вариантов тоже иногда становится плохо.

все, пока хватит, ушел спать (на часах почти 4).

[nyuk]

Сорри, вчера в предыдущем посте написал ерунду.
На самом деле, у меня считает цвета так же, как написал pulsar. Если сконвертировать AllColor.img и сравнить в фотошопе со скриншотами выше, то расхождения будут на единицу.
Т.е. для темно-красного в палитре pulsar вместо #cc будет #cd. А если вместо нормализации по методу EEA просто делить на 0x100, от совпадение вообще будет полным.

По поводу палитр. Я думаю не отключать лишние, мне например Mars нравится, она забавная. Но вот я бы палитру pulsar переставил вверх, чтобы она стала по-умолчанию, т.к. картинка с ней получается самая "ровная" что ли.

[pulsar]

перечитал свой ночной пост... эх и понаписал же... ладно, вроде бы все понятно и вроде как верно. поправил некоторые шероховатости, полностью все выправлять не стал, чего уж там если тут некоторые собственную подпись то с очепяткими пишут:

Спектрумист, не умеющий форматировать дискты на реале.

смеюсь. ладно.

значит еще что?! на бордер рассчитываю?! как делать вроде бы обсудили выше и делать как понимаю не проблема... следующий этап мультигига в mg(x) коих 4 шт (mg1, mg2, mg4, mg8) - значение бордера хранится в самом файле вот выдержка из документации (саму документацию кинул в ататач (выдернул из первого поста tmk)):

For MG1,MG2,MG4,MG8 file have HEADER 256 bytes length (one sector on tr-dos disk):
[3]	MGx_FILE_ID	Identifier for MG files = "MGH" (Milti Gigascreen ZX File Header)
[1]	MGx_FILE_VER	MG zx file format Version
[1]	MGS_CharSize	Size of Char[1=8x1, 2=8x2, 4=8x4, 8=8x8]
[1]*	ZX Color1 Border
[1]*	ZX Color2 Border

8х2, 8х4, 8х8 в будущем вряд ли изменятся, а вот 8х1 может измениться (так что надо будет отслеживать еще и параметр - MGx_FILE_VER)! кпримеру вместо 16 знакомест в ширину мультиколор можно сделать скажем 18-20 без особых проблем да и само "окно" по идее может стать плавающим. в общем это надо делать! обязательно! думаю еще и tmk потом тебе памятник соорудит...

так и еще маленькое (именно маленькое) предложение-дополнение. надо для веба сделать масштаб х0.5! зачем это надо?! zpixel и аналоги ([1], [2]) - вот и весь ответ! почему х0.5 нельзя (не желательно делать) вебом?! потому как по юзате разные браузеры! они ведь все уж очень не стандартны все очень зависит от типа браузера и операционной системы, где-то масштаб с блюром будет, где-то еще что-то...