Página 1 de 5

Leer paleta de un BMP

Publicado: Lun, 19 Ene 2015, 12:11
por radastan
Buenas a todos.

Estoy realizando un conversor de BMP a código ASM para pasar sprites del modo radastaniano del zxuno a código. Los pixels los leo sin problemas, pero la paleta no se como cogerla.

El problema es que sin la paleta no puedo convertir los pixels a un color, ya que tengo el RGB de los mismos pero no se a que color de paleta corresponde.

¿Alguna idea?

A las malas tendré que definir en un fichero externo los colores de la paleta y cogerlos por aproximación.

PD. PO-FA-VÓ y esas cosas :jias:

Re: Leer paleta de un BMP

Publicado: Lun, 19 Ene 2015, 12:29
por na_th_an
¿Cómo funciona la paleta del modo este rarow? ¿Cuántos bits por componente? Sabiendo eso, es fácil detectar el indice más próximo de la paleta tiendo el R, G, y B del pixel original.

Como no sé cómo funcionan los colores en este modo, tampoco te puedo ayudar. Pero si es como pienso (X bits por componente) es tan sencillo como hacer shifts.

Re: Leer paleta de un BMP

Publicado: Lun, 19 Ene 2015, 12:43
por radastan
Eso lo tengo claro, oh Na_Th_An el grande, si es hasta sencillo. La pega es con que paleta comparar. Los BMP traen la paleta incluida, eso sería lo suyo (y de paso pasar a ASM la paleta). Lo que no quiero es tener que pasar la paleta a mano, ya que estoy programando una herramienta.

En cuanto la termine la modificaré para que sirva también para gráficos de ZX Spectrum, así mato dos pájaros de un tiro. Es que es con IDE, no tienes que pelearte con comandos, y encima multiplataforma (es java). Molaría mucho añadirlo al MK2, y luego hacer lo mismo para el conversor de mapas. Hasta podría hacer que cogiera el tileset, los sprites, y el mapa, y te lo pasara todo al código de una tacada. Vamos, la panacea.

Re: Leer paleta de un BMP

Publicado: Lun, 19 Ene 2015, 13:21
por na_th_an
Supuestamente, y sin saber qué estás usando para hacerlo, si cargas un archivo de gráfico puedes obtener el color de cada pixel, da igual si el archivo gráfico es con paleta o no. Y todo lo que conozco usa un formato de 32bits RGBA en el que sacar las componentes es trivial.

Es que creo que no estoy entendiendo muy bien tu pregunta :) Con qué paleta comparar ¿qué? Por eso te preguntaba por cómo genera el modo este los colores.

Por ejemplo, en la ULA+ las paletas son de 3 bits para R, 3 para G y 2 para B. De ese modo, teniendo un color (r, g, b) de una imagen, que tendrá 8 bits por componente, sólo tienes que hacer R = r >> 5; G = g >> 5; B = b >> 6 para obtener el color de ULA+.

Dependiendo del formato de paletas del modo este de ZX-Uno, habrá que hacer una cosa u otra.

En todos mis conversores trabajo por aproximación pura y dura. Como son para uso propio, sé con qué colores tengo que pintar en mi editor gráfico preferido para que la conversión sea como yo quiero. Así, siguiendo el ejemplo de la ULA+, yo dibujaría eligiendo colores que cumpliesen los requisitos de 8 niveles para R o G y cuatro para B.

Si te refieres a que quieres cuantizar primero para obtener una paleta y luego convertir en base a esa paleta, necesitarás dos pasadas... Hay varios algoritmos. Por ejemplo, sabiendo los bits por componente, vas recorriendo la imagen, convirtiendo los pixels, y contando cuántos píxels hay de cada color que vayas encontrando (ya convertidos). Luego coges los 16 colores más repetidos, y recorres de nuevo la imagen aproximando los demás colores a esos.

Otra forma algo más compleja (matemáticamente) es elegir los 16 colores de todos los que has encontrado que cumplan un espectro mayor. Pero para eso hay que cambiar a HLS y usar coordenadas polares (OUCH). Esto lo vi hace muuucho tiempo y apenas recuerdo nada.

De todos modos estas cosas no suelen salir bien. Es preferible que el diseñador trabaje con las restricciones en mente y que el conversor no tenga que adivinar nada. Si quieres hacerlo más universal, siempre puedes requerir que en la imagen haya 16 pixels en algún sitio definido que contengan los 16 colores.

Personalmente, prefiero las herramientas de linea de comandos que pueda meter en un batch. Así el trabajo manual es mínimo. En Ninjajar! cambiamos tantas veces los mapas y los gráficos... Pero cientos de veces. Y sólo había que ejecutar un make.bat para reconstruirlo todo y volver a probar :) Pero entiendo que hay otras formas de trabajar.

Re: Leer paleta de un BMP

Publicado: Lun, 19 Ene 2015, 13:44
por iforeve
$this->bbcode_second_pass_quote('na_th_an', '.')..Pero entiendo que hay otras formas de trabajar.

Re: Leer paleta de un BMP

Publicado: Lun, 19 Ene 2015, 13:45
por iforeve
$this->bbcode_second_pass_quote('iforeve', '')$this->bbcode_second_pass_quote('na_th_an', '.')..Pero entiendo que hay otras formas de trabajar.

Siiiii, con un cincel y un martillo, :lol: :lol: :lol:

Re: Leer paleta de un BMP

Publicado: Lun, 19 Ene 2015, 17:56
por antoniovillena
Lo más fácil es definir una paleta fija de 16 colores que cubra todas las necesidades del juego. Si quieres que haya algo más de variedad, puedes usar 3 o 4 colores sólo para fondos. Eso te limita la paleta para sprites, pero permite usar colores nuevos en otros escenarios. Por ejemplo puedes usar 12 colores para la paleta y los escenarios los haces con esos 12 colores fijos y otros 4 que cambian según la escena. Para selvas necesitarás varios tonos de verde, para hielo varios de azul, etc...

No soy muy experto pero usar distintas paletas para un mismo sprite no es en general buena idea. Es lo que usaba la nintendo para genera el personaje Luigi partiendo del sprite de Mario.

Coincido con na_th_an con que lo mejor es línea de comandos. Si quieres fíjate en mis herramientas churreras, que usan una librería para leer de archivos .pngs.

Re: Leer paleta de un BMP

Publicado: Lun, 19 Ene 2015, 19:34
por radastan
Vamos a ver, por partes (como diría Jason de Viernes13):

1) Si, la paleta es la de la ULA+... la cual es redefinible. Es decir la paleta es de 16 colores seleccionable de 256. Eso quiere decir que cada programador va a querer trabajar con la paleta que más rabia le de, por no hablar de la posibilidad de cambiar la paleta para cada pantalla rizando el rizo. Se pueden conseguir cosas increíbles con ello.

2) Todo fichero BMP incluye, aparte de la cabecera y los pixels, una paleta de los colores según la profundidad de color de la imagen si es por debajo de 16 bits. Quiere decir que una imagen de 16 colores incluye la paleta íntegra de 16 colores con la que se ha realizado la imagen, use dicha imagen todos los colores o no. Y es que ese es el quid de la cuestión, que cada imagen convertida no tiene porqué usar toda la paleta.

Voy a rebuscar un poco más por Internet, a las malas me hago una aplicación para generar paletas de ULA+ en ASM y presento en pantalla la paleta creada para capturar y basarse en esa.

Publicado: Lun, 19 Ene 2015, 21:00
por na_th_an
Sigo sin saber exactamente lo que quieres conseguir. Si lo que quieres es extraer la paleta del BMP, puedes abrir el archivo como binario, decodificar la cabecera, y extraer la cabecera de ahí. Es extremadamente sencillo y puedes encontrar la descripción del formato BMP muy fácilmente. Creo recordar que venía al final del archivo y usaba 8 bits por componente. Lee esa información, convierte los colores, y cuantiza la imagen.

Publicado: Lun, 19 Ene 2015, 21:03
por na_th_an
De todos modos, creo que es mejor habilitar alguna forma de que el diseñador defina la paleta sin tener que recurrir a archivos paleteados. Cada vez menos aplicaciones permiten manejar una paleta de forma cómoda. Augusto Ruiz hizo sus conversores para CPC requiriendo que se definirse la paleta de forma explícita en un archivo. Puedes hacerlo usando pixels de la propia imagen como te sugerí, si no quieres usar archivos extra.