Масштабирование экрана Спектрума

[SMT]

Учитывать 3-ки и четверки это уже нелинейная интерполяция и потребует арифметику с плавающей точкой или в крайнем случае умножение/деление точно

для ч/б - умножение по таблицам

[CityAceE]

Короче ради интереса потестил. По-моему нормально.
Результат (с дополнительным приведением к 2бита на канал цвета)

Результат впролне удовлетворяет! Прошу разложить мне по полочкам суть метода.

учитывая лишь 2x2 мы получим "рывки" на фреймовых эффектах.

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

больше всего меня интересует, как ты выбираешь палитру для цветного режима?

Никак не выбираю. Пользуюсь той, что предлагается по умолчанию. А из неё выбираю наиболее похожие цвета. Я не стремлюсь к максимальной точности.

[maximk]

Исходные данные. Двумерный массив точек изображения, которое надо
масштабировать - image[][]. Элемент массив - число, определяющее цвет точки (в каком либо виде).

Есть вспомогательные функции(макросы), которыми можно извлечь
каждую компоненту из этого числа - getRed/getGreen/getBlue

Идем по точкам результирующего изображения:

for (int x=0; x<128; ++x) {
  for (int y=0; y<96; ++y) {
    // интерполируем каждый канал по отдельности
    int red = (getRed(image[x*2][y*2]) +
                    getRed(image[x*2+1][y*2]) +
                    getRed(image[x*2][y*2+1]) +
                    getRed(image[x*2+1][y*2+1])) / 4;

    int green = (getGreen(image[x*2][y*2]) +
                    getGreen(image[x*2+1][y*2]) +
                    getGreen(image[x*2][y*2+1]) +
                    getGreen(image[x*2+1][y*2+1])) / 4;

    int blue = (getBlue(image[x*2][y*2]) +
                    getBlue(image[x*2+1][y*2]) +
                    getBlue(image[x*2][y*2+1]) +
                    getRed(image[x*2+1][y*2+1])) / 4;

    // имеет цвет точки в виде R,G,B
    int paletteIndex = convertToPalette(red, green, blue);
    newImage[x][y] = paletteIndex;
  }
}

Само-собой код можно оптимизировать. Это я написал для понятности.

[CityAceE]

Есть ещё вопрос в рамках той же темы. В прилагаемом файле стандартная палитра Палма. Один цвет занимает клетку 8x8. Цвета идут слева направо, сверху вниз. Цвет в левой верхней клетке имеет номер 0 и далее по возрастанию.

Никогда до этого не сталкивался, поэтому для меня несколько не ясно как получаются эти цвета... Не могу понять закономернось. Какой бит номера цвета за что отвечает?

[maximk]

Ну, там используются так называемые web-safe цвета.

Каждая компонента может принимать значение из набора 0x00, 0x33, 0x66, 0x99, 0xCC, and 0xFF и того имеем 6^3=216 цветов + дополнительные оттенки для серого (все компоненты 0x22, 0x44, 0x55, 0x77, 0x88, 0xAA, 0xBB, 0xDD, 0xEE) и если посмотреть на представленную палитру еще несколько цветов, где компонента либо 0x88 либо 0x00

Значит если мы возьмем номер в палитре от 0 до 215, то можно его разложить таким образом:
index % 6 = индекс зеленого в массиве [0xFF, 0xCC, 0x99, 0x66, 0x33, 0x00]
(index / 18) % 6 = индекс красного в массиве
(((index / 6) % 3) * 2) + (index / 108) * 3 = индекс синего. Т.е. смысл в том, что первую часть палитры синий убывает по горизонтали в группах с 0xff до 0x99, а вторую половину с 0x66 до 0x00

Цвет с номером 215 не черный, а темно-темно серый (0x111111)

Если я не ошибся конечно...

Это я написал преобразование номера в RGB, но думаю и обратная операция большого труда не составит. Можно сделать таблицу(ы) для ускорения. По 512 байт получится.

А вообще, неужели в API PalmOS нет таких функций, для работы с цветом покомпонентно? Прямо даже не верится...

[CityAceE]

Спасибо за помощь!

Ну, там используются так называемые web-safe цвета.
...
Цвет с номером 215 не черный, а темно-темно серый (0x111111)
Если я не ошибся конечно...

Нет, не ошибся, всё верно. Это я уже опытным путём проверил

Только напомни, пожалуйста, какое действие обозначает знак процента (%). Целочисленное деление?

А вообще, неужели в API PalmOS нет таких функций, для работы с цветом покомпонентно? Прямо даже не верится...

Наверняка есть! Но всё, что я пишу, я пишу на чистом ассемблере. Можно конечно и из ассемблера все эти API вызывать, но разбираться совсем нет желания, да и нет времени у программы пользоваться громоздкими и медленными процедурами API.

[Advertiser]

[maximk]

% - остаток от деления. Т.е. например 5 % 3 = 2 (частное = 1, в случае целочисленного деления)

[CityAceE]

Замечательно, вроде всё получается, благодаря советам с форума. Ещё раз спасибо всем откликнувшимся. Отпуск короткий и пока я делаю другие вещи мне всё же хотелось бы не тратить время на решение этой задачи, а увидеть в этой ветке уже готовую формулу как перевести цвет в формате RGB в формат INDEXED COLOR, т.е. в стандартную палитру Палма.

[maximk]

Если RGB результрующей картинки, где могут быть смешанные цвета (не спектрумовские) для сглаживания результатов масштабирования, то где-то так:

index = (green / 0x33) + ((red / 0x33) * 18) + ((blue / 0x33) % 3) * 6
if (blue < 0x80) {
  index = index + 108
}

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

Например, выделить под цвет 2 бита и получим 64 цвета, но этого хватит на самом деле.

Т.е. скажем индекс в палитре будет раскладываться по битам так: 00RRGGBB

[captain cobalt]

С точки зрения объёма данных лучше преобразовывать из экрана 6912 в конечный результат. Т. е. (2 байта экрана + 1 байт аттрибутов) -> 4 пикселя. Возможно, байт аттрибутов сначала преобразовать и затем применять ко всем 4 строкам.

Имеются ли 32-битные регистры? Целочисленное умножение? Какова палитра?
[Добавлено]
Ответы нашлись здесь и здесь.