Не нашел в сети конвертора картинок в поток для армов с LCD ....
Ну как, они то есть, но не совсем подходят. у кого разрешение низкое, кто не поддерживает RGB 5:6:5

Вот решил сесть и написать свое.

Предлагаю ВАМ на "заплевать" мое творение за вечер.

Если будет интересно... предлагайте , что бы вы хотели туда добавить....
Пока реализовано:
1. Поддержка файлов BMP и Jpeg
2. автоматическое приведение размера картинки к требуемуму (320х240, 640х480)
3. автоматическое конвертирование цвета 16 BPP и 24 BPP (32 бита)
4. Генерация текста в окне (Copy-Paste в ваш H-файл)

в ближайшее время доделаю

1. Сохранение прямо в указанный файл
2. Сохранение всех настроек в реестре
3. Ну и ваши пожелания, если будут....

PS БЕЗ палитры! пока. Может будет 8 бит на пиксель, тогда добавлю палитру....

Сам файл....

новый релиз..... с доделками...

Да... НАРОД! А можно не просто скачивать, а еще и высказываться ?
Неплохо было бы довести до ума фичу, раз уж начал ее делать....


Проверено
16BPP 640x480 на LPC2478 + LQ064V3DG01 (фотку могу выложить)
Просьба
У кого есть возможность... проверить 320х240 24BPP (32 Bits) и отписаться..

Можно. Цель сей программы? Реализация фоторамки на LPC2478?
Дело в том, что ARM7 производительностью не блещет.
Я, например, для GUI использую заранее подготовленные файлы.

ИМХО, гораздо удобнее реализовать поддержку bmp с любым разрешением и глубиной цвета в программе для МК, а на PC только паковать файлы каким-нибудь LZ.

фоторамка тут не причем
подготовка "своих " битмапов для GUI - различные "побрякушки " на кнопочки и тд.....
это для чего я ее делал, а куда вы "пристроите" - вам решать....




может быть, а заголовки вам во флеше тоже нужны? и , если глубина цвета на вашем мк не такая как в файле? , еще и тратить время МК на конвертирование?
Это только те аргументы, которые сподвигли меня делать все это.....

Заголовки много не занимают, тем более в компрессированном виде.


Зато не нужно специально конвертировать файлы (а их несколько сотен): просто взял любую bmp-шку, скопировал в каталог resources и все. Для элементов GUI лучше всего подходит 8bpp с оптимизированной палитрой, соответственно ресурсы МК нужны только на конвертирование самой палитры. Еще один плюс в том, что нет привязки к конфигурации железа - на экране можно ставить 8-16-24-32bpp ничего при этом не меняя в файлах ресурсов.

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

protestiroval na olimex LPC-2478STK - rabotaet! Izobrajenie pokazivaetcya otlichno!
razreshenie - 320*240 24bit

спасибо огромное.


в установках выбирается разрешение TFT , а не размер картинки!!!

Кому нужны другие разрешения - пишите , доделаю.

было бы супер если бы она сама умела определять разрешения
другими словами, если картинка 320*240 он её так и оставляет, если меньше, например, 16*16 то тоже оставляет, а если скажем 800*600 спрашивает в какое именно разрешение переделать...
было бы значительно удобней...
да и исходники бы не помешали бы (но я не настаиваю, каждый сам решает что его собственное )

1. вы в самом начале "определяетесь" какого разрешения ваш LCD и устанавливаете в настройках.
Затем прога автоматом приводит картинку к 320 точкам (к примеру, если выбран режим 320х240) по горизонтали и пропорционально уменьшает кол- во строк (те соблюдает пропорцию). Это если картинка по горизонтали превышает 320 точек. Если картинка по вертикали больше 240 линий - то автоматом подгоняет под 240 линий. ТЕ ваша картинка по-любому будет на LCD полностью!
картинки меньшего разрешения не растягиваются - все остаеться как есть!

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

2. Прога писана на Delphi и без комментов , почти - есть желание копаться в коде?

800*600 добавить?

А можно реальзовать вариант хранения картинок в формате jpeg в внутренней или внешней flash памяти контроллера, а при необходимости декодировать их в RGB и выводить на экран?. Если не требуется частого обновления картинок, например их всего 10 потребуется. тогда как реализвать декодер такой? хватит ресурсов LPC2478?

у меня получалось но ОЧЕНЬ медленно! 640х480 из jpeg вылазило на LCD ~1...1.2 sec

ну для меня это приемлемая скорость, тем более надо 320 на 240. а алгоритмом не поделетесь?(декодирования)

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

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

я имел ввиду "сами не справитесь с проблемой"
я сча нагружен сильно проблемой LPC2478+Ext.Flash

Новая версия
+ 1024х768

Гы ,в целом неплохо,я год назад тоже подобное делал,а с месяц полностью переделал прогу,правда история была под 132х176.
Из своего опыта могу сказать , можно организовать сжатие и распаковывать на "лету",типа тем же самым потоком.
Неплохо получаются фотки крупным планом в формате 5:4:4х3 (первые три числа -цвет ,последнее-счетчик повторений точки с этим цветом)
Фотки зданий -природы,рисованые картинки неплохо смотрятся при 4:4:4х4 ,различные меню или сообщения отлично сжимаются при 3:3:3х5,
Весьма полезно будет для тех ,у кого напряг с памятью.

Ну и выходной формат BIN или HEX тоже наверное полезен будет ,я например картинки храню во внешней памяти.

+800х480

#include <stdlib.h>

int *temp_multiply_matrix_place, temp_multiply_matrix_place_x, temp_multiply_matrix_place_y;

void copy_matrix(temp_multiply_matrix_place, size_x_b, size_y_a, result)
int *temp_multiply_matrix_place, size_x_b, size_y_a, *result;
{
int i,j,accum;
for(i=0, accum=0; i<size_y_a; i++)
{
for(j=0;j<size_x_b;j++)
{
result[accum+j] = temp_multiply_matrix_place[accum+j];
}
accum+=size_x_b;
}
}

void mul_matrix(a, size_x_a, size_y_a, b, size_x_b, size_y_b, result)
int *a,*b, *result, size_x_a, size_y_a, size_x_b, size_y_b;
{
int i,j,k, row_accum_1,row_accum_2,row_accum_3, sum_num;
sum_num = (size_x_a<size_y_b)?size_x_a:size_y_b;
if(a!=result && b!=result)
{
for(i=0, row_accum_1 = 0, row_accum_2=0; i<size_y_a; i++)
{
for(j=0; j<size_x_b; j++)
{
result[row_accum_2+j] = 0;
for(k=0, row_accum_3=0;k<sum_num;k++)
{
result[row_accum_2+j] += a[row_accum_1+k]*b[row_accum_3+j];
row_accum_3+=size_x_b;
}
}
row_accum_1+=size_x_a;
row_accum_2+=size_x_b;
}
}
else
{
mul_matrix(a, size_x_a, size_y_a, b, size_x_b, size_y_b, temp_multiply_matrix_place);
copy_matrix(temp_multiply_matrix_place, size_x_b, size_y_a, result);
}
}

int main()
{
temp_multiply_matrix_place_x = 10;
temp_multiply_matrix_place_y = 10;

temp_multiply_matrix_place = calloc(temp_multiply_matrix_place_x,temp_multiply_matrix_place_y);
/*
int a[3][2] = {{1,2},{3,2},{1,3}};
int b[2][3] = {{1,2,3},{3,2,1}};
int c[3][3] = {{0,0,0},{0,0,0},{0,0,0}};

mul_matrix(a, 2,3,b,3,2,c);
*/

int a[3][3] = {{1,2,3},{3,2,1},{1,3,2}};
int b[3][3] = {{1,2,3},{3,2,1},{2,2,2}};

mul_matrix(a, 3,3,b,3,3,a);

free(temp_multiply_matrix_place);
return 0;
}


вот..... на "ЛАБУ" похоже, но я тоды только учился