SWIM NXP, problema com 24 bits e tft.

Software e Hardware para linha ARM

Moderadores: 51, guest2003, Renie, gpenga

SWIM NXP, problema com 24 bits e tft.

Mensagempor fabim » 15 Out 2010 13:26

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
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 5001
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Mensagempor fabim » 15 Out 2010 15:02

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
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 5001
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Mensagempor rcakto » 15 Out 2010 15:12

eu so me pergunto pq ele faz isso....
(parado por culpa da faculdade...)Osciloscopio opensource... entre e participe:
http://asm51.eng.br/phpBB/viewtopic.php?t=10710
rcakto
Word
 
Mensagens: 787
Registrado em: 09 Jun 2010 00:57
Localização: vitoria ES

Mensagempor fabim » 15 Out 2010 15:32

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.
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 5001
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Mensagempor rcakto » 15 Out 2010 15:51

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??
(parado por culpa da faculdade...)Osciloscopio opensource... entre e participe:
http://asm51.eng.br/phpBB/viewtopic.php?t=10710
rcakto
Word
 
Mensagens: 787
Registrado em: 09 Jun 2010 00:57
Localização: vitoria ES

Mensagempor fabim » 15 Out 2010 15:56

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
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 5001
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Mensagempor rcakto » 15 Out 2010 16:16

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??
(parado por culpa da faculdade...)Osciloscopio opensource... entre e participe:
http://asm51.eng.br/phpBB/viewtopic.php?t=10710
rcakto
Word
 
Mensagens: 787
Registrado em: 09 Jun 2010 00:57
Localização: vitoria ES

Mensagempor fabim » 15 Out 2010 16:39

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 ?
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 5001
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Mensagempor rcakto » 15 Out 2010 16:50

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...
(parado por culpa da faculdade...)Osciloscopio opensource... entre e participe:
http://asm51.eng.br/phpBB/viewtopic.php?t=10710
rcakto
Word
 
Mensagens: 787
Registrado em: 09 Jun 2010 00:57
Localização: vitoria ES

Mensagempor fabim » 15 Out 2010 16:59

shit meu, alguém ai que não queira perguntar nada, gostaria de me ajudar ?
hehehe
Mano, ve só.
Sou responsável pelo que escrevo!!! E não pelo que você entende !!!
fabim
Dword
 
Mensagens: 5001
Registrado em: 16 Out 2006 10:18
Localização: aqui uái!!!?

Mensagempor pbernardi » 15 Out 2010 17:35

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.
But to us there is but one God, plus or minus one - Corinthians 8:6±2. (xkcd.com)
pbernardi
Word
 
Mensagens: 707
Registrado em: 12 Out 2006 19:01
Localização: Curitiba-PR

Mensagempor barboza » 15 Out 2010 19:03

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.
Os homens mentiriam muito menos se as mulheres fizessem menos perguntas.
Avatar do usuário
barboza
Word
 
Mensagens: 948
Registrado em: 17 Out 2006 13:42
Localização: Longe de onde gostaria de estar

Mensagempor Jorge_Francisco » 15 Out 2010 19:29

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.
Avatar do usuário
Jorge_Francisco
Dword
 
Mensagens: 1009
Registrado em: 12 Out 2006 09:53
Localização: Rio de Janeiro

Mensagempor Jorge_Francisco » 15 Out 2010 19:31

Avatar do usuário
Jorge_Francisco
Dword
 
Mensagens: 1009
Registrado em: 12 Out 2006 09:53
Localização: Rio de Janeiro

Mensagempor msamsoniuk » 15 Out 2010 20:03

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 ?
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Próximo

Voltar para ARM

Quem está online

Usuários navegando neste fórum: Bing [Bot] e 1 visitante

x