Página 1 de 2

SWIM NXP, problema com 24 bits e tft.

MensagemEnviado: 15 Out 2010 13:26
por fabim
Psoal.
Estou com um problema imbecil, e não estou descobrindo o que é.
Estou tentando escrever a imagem a baixo.

http://desmond.yfrog.com/Himg258/scaled.php?tn=0&server=258&filename=correto.jpg&xsize=640&ysize=640

Detalhe.
A imagem tem uma resolução V320*H240, e foi exportado para hex imagem de 24 bits.
Quantidade de bytes = 320*240*3.

A biblioteca swim, tem o exemplo para o hw de 320*240*2, pois trabalha com 16 bits padrão RGB565 por default.
Acontece que o RGB565, sei lá porque raios de motivo, esta com frescuras de paleta 256 cores, e a imagem fica uma nhaca.

Bem, eu configurei o Swim para trabalhar com 24 bits, e o resultado a baixo:

http://desmond.yfrog.com/Himg543/scaled.php?tn=0&server=543&filename=errol.jpg&xsize=640&ysize=640

Detalhe, vejam que ele esta cortando a imagem um pouco mais de 50%.

Vejam só o calculo.

Em 16 bits e 320 * 240 .
Tenho 320*240*2 bytes = 153600 bytes, para poder preencher a screem toda.
Em 24 bits e 320 * 240 .
Tenho 320*240*3 bytes = 230400 bytes, para poder preencher a screem toda.

SE fizer 230400 - 153600 = 74100 bytes. Que pelos meus calculos são os bytes que estão em branco na imagem a baixo.

A AHB transfere até 16KB e pode ser cascateado até 10 unidades da mesma, sendo assim ela sozinha fica escaneando 160kB se bem entendi.

Bem esse não é o problema, o problema é que ele esta cortando e invertendo a imagem da primeira metade da tela.

Alguém ja mecheu no swim, pode dar uma luizia ?

Sei que é algo muito besta, mais não estou conseguindo visualizar a besteira.

Abraços

Fabim

MensagemEnviado: 15 Out 2010 15:02
por fabim
detalhe.
Acabei de descobrir que quando se usa o display em 24 bits, o sistema roda com uma int na matris. ou seja. 4 bytes, pegando apenas o LSB.
Desta forma fica agora, comprovado com um paquimetro, que ele por algum motivo escreve exatamente até a metade do display, e que ele inverte a imagem da metade superior postada acima!!! Croisa cruélica. que cagalho

MensagemEnviado: 15 Out 2010 15:12
por rcakto
eu so me pergunto pq ele faz isso....

MensagemEnviado: 15 Out 2010 15:32
por fabim
rcakto escreveu:eu so me pergunto pq ele faz isso....


Mais tu é abestado eim? num viu que eu ja tinha feito essa pergunta primeiro ? Mas detalhada !!!
Ticontaviu, que cara mais sem curtura.

MensagemEnviado: 15 Out 2010 15:51
por rcakto
mas o fabim, eu to perguntando exatamente o pq no sentido da biblioteca e do hardware.. alguma coisa em especial ou putaria do programador da biblioteca??

MensagemEnviado: 15 Out 2010 15:56
por fabim
Tipo, sabe intão.

Cara intão. ve só. O AHB é formado por 10 estagios cascateados com 16K cada. que dá 160K Bytes.
Uma imagem de 320*240 * 4 = ?

Duas vezes maior que o máximo que a AHB consegue jogar sozinha pro display.
ATé ai eu entendo perfeitamente!!! Mais porque caralhos de motivo ele parte essa suposta metade de imagem ao meio, e as inverte ?

Ta entendendo ? sacou?

E porque o RGB565 16 bits, não da full color ? Me da cor de caramba de palheta !? Sacou?

To procurando alguma outra biblioteca grafica pro 2478 mais todo mundo só usa o swim, e com cores primarias e frias. Froid

MensagemEnviado: 15 Out 2010 16:16
por rcakto
fabim, agora eu to comecando a entender.. mas seguinte, como uma biblioteca vai te dar mais cores sendo que ela e de 16bits?? 16 bits = 256 cores... ou esse 16bits e com relação ao LCD a ser trabalhado??

MensagemEnviado: 15 Out 2010 16:39
por fabim
rcakto escreveu:fabim, agora eu to comecando a entender.. mas seguinte, como uma biblioteca vai te dar mais cores sendo que ela e de 16bits?? 16 bits = 256 cores... ou esse 16bits e com relação ao LCD a ser trabalhado??


intão catarro.
Acho que você nã chegou a ler direitinho sobre cores.

RGB565 =
5 bits * 6 bits * 5 bits
5 bits = 32
6 bits = 64

Sendo assim com RGB565, você alcança
32*64*32 cores.
Isso equivale a 65536 cores.
O que equivale ao mesmissimo valor referido a 16 bits.!!!

Para 24 bits, vem que.
256 * 256 *256 = 16.777.216 de cores, por isso full color. Ele atinge cores de temperatura altissima.

TEndeu ?

Eu não sei porque, o maldito em 16 bits RGB565, esta pegando os valores de 16 bits e paletando!!! pra formar as imagens!!!
Se eu pegar uma foto de uma mão, ele não consegue fazer a textura da pele e os contrastes etc, ficam todos com cores de paleta. Roxo, verde, cinza, etc.

Ta tendendo ?

MensagemEnviado: 15 Out 2010 16:50
por rcakto
a ta agora eu entendi, e que me falaram que esses nomes RGBXXX eram so nomes de paletas e que nao tem relação ao numero de cores e afins.. como se fosse nomes de padroes de protocolo de rede.... mas vejo que o pessoal esta muito enganado a isso...


OBS.: sinceramente vo comecar a perguntar o ABC a voces... o que eu acho na internet ou perguntando a outras pessoas ta tudo errado... to cancado de passa vergonha aqui...

MensagemEnviado: 15 Out 2010 16:59
por fabim
shit meu, alguém ai que não queira perguntar nada, gostaria de me ajudar ?
hehehe

MensagemEnviado: 15 Out 2010 17:35
por pbernardi
Pq vc não tenta gera uma imagem com padrão diferente de cores, pra ver o que acontece?

P.ex. uma imagem que varie na vertical, o R, e a horizontal o G. E depois outra que seja BxG, e outra RxB.

Vizualizando essas imagens, talvez você consiga pescar qual é o problema.

MensagemEnviado: 15 Out 2010 19:03
por barboza
fabim escreveu:detalhe.
Acabei de descobrir que quando se usa o display em 24 bits, o sistema roda com uma int na matris. ou seja. 4 bytes, pegando apenas o LSB.
Desta forma fica agora, comprovado com um paquimetro, que ele por algum motivo escreve exatamente até a metade do display, e que ele inverte a imagem da metade superior postada acima!!! Croisa cruélica. que cagalho


Neste caso não deveria exportar a img para 32 bits ao invês de 24?

Sobre a inversão pode ser um problema com a orientação no momento de exportar os dados e montar a matriz.

MensagemEnviado: 15 Out 2010 19:29
por Jorge_Francisco
Eu não entendi. Se aceita só 16 bits, pra que colocar algo de 24?

24 bits = RRRRRRRR GGGGGGG BBBBBBBB

16 bits = RRRRR GGGGGG BBBBB

Para testar poderia tirar os 3 bits ultimos de R, 2 de G e 3 de B. Ou seja, deslocar os bits. E colocar no display e ver no que dá.

Espelhar a imagem é problema de matriz, seja de leitura ou escrita.

MensagemEnviado: 15 Out 2010 19:31
por Jorge_Francisco

MensagemEnviado: 15 Out 2010 20:03
por msamsoniuk
pq a temperatura das cores iria ser diferente? acho q eh exatamente nisso que vc esta comendo bola hein! :)

com 24 bits de cor vc tem 8 bits de cor por componente e com 15 bits de cor vc tem 5 bits de cor por componente (no caso de 16 tem uma aberracao 565, vc entendeu neh, vou usar 555 para o raciocinio ficar padrao, depois vc adapta). o que muda eh o range, mas um range de 32 gradacoes para 256 nao dah tanta diferenca assim, principalmente se vc usar o algoritmo de difusao por erro. dah uma comparada ae:

http://www.whitewing.co.uk/vdub_errdiff.html

a temperatura das cores eh a mesma pq de 8 para 5 bits vc trunca o LSB de cada componente e acaba ficando com o mesmo range, mas com granularidade diferente. se vc compensar isso com difusao por erro, de 24 para 16 bits realmente nao vai perceber diferente.

agora, se fizer errado e truncar o MSB, vc obtem 32768 cores completamente empasteladas. converter imagens eh um negocio relativamente trivial, dah uma olhada nesse codigo:

http://xstep.sourceforge.net/xstep-4.1/ ... onversor.c

esse eh bem simples ateh e soh converte formatos. depois eu fiz um mais avancado com suporte a JPEG e que converte quase qq formato de entrada para um buffer de 24 bits no X11:

http://xstep.sourceforge.net/xstep-4.1/ ... tepimage.c

esse buffer vai para o X11 com 8, 16 ou 24 bits usando uma biblioteca de conversao que eu fiz, que inclui ateh recurso de zoom, porem nao suporta difusao:

http://xstep.sourceforge.net/xstep-4.1/lib/image.c

uma epoca eu cheguei a implementar difusao para 8 e 16 bits a partir de 24 bits, mas nao sei onde foi parar o codigo. de qq forma, essas paradas sao triviais, qq 10 minutos vc coda isso ae na boa, eh soh largar as muletas dos tools da nxp que vc deslancha rapido! ;)

fabim escreveu:
rcakto escreveu:fabim, agora eu to comecando a entender.. mas seguinte, como uma biblioteca vai te dar mais cores sendo que ela e de 16bits?? 16 bits = 256 cores... ou esse 16bits e com relação ao LCD a ser trabalhado??


intão catarro.
Acho que você nã chegou a ler direitinho sobre cores.

RGB565 =
5 bits * 6 bits * 5 bits
5 bits = 32
6 bits = 64

Sendo assim com RGB565, você alcança
32*64*32 cores.
Isso equivale a 65536 cores.
O que equivale ao mesmissimo valor referido a 16 bits.!!!

Para 24 bits, vem que.
256 * 256 *256 = 16.777.216 de cores, por isso full color. Ele atinge cores de temperatura altissima.

TEndeu ?

Eu não sei porque, o maldito em 16 bits RGB565, esta pegando os valores de 16 bits e paletando!!! pra formar as imagens!!!
Se eu pegar uma foto de uma mão, ele não consegue fazer a textura da pele e os contrastes etc, ficam todos com cores de paleta. Roxo, verde, cinza, etc.

Ta tendendo ?