OJODIGITAL

 
perfectRAW/perfectBLEND Foro para tratar todo lo relacionado con estos dos programas basados en DCRaw para el revelado de imágenes RAW y el blending de imágenes para aumentar su rango dinámico

Tema Cerrado
  #101 (permalink)  
Antiguo 20-ene-2009, 22:54
Lleva poco por aquí
 
Fecha de Ingreso: septiembre-2008
Ubicación: Valencia
Mensajes: 76
Uff como os cunde cuando no tengo tiempo de leer...

Sólo decir que Linux hay de 32bits y 64 bits. Yo en casa lo uso a 64bits en el fijo y a 32bits en el portátil.
Publicidad
  #102 (permalink)  
Antiguo 20-ene-2009, 23:13
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Cita:
Iniciado por Lassus Ver Mensaje
Manuel, he añadido la línea, definiendo command_line y pos (que he renombrado como pos_cl por existir ya) como globales para recuperar su contenido en la función que escribe el EXIF y cambiando "args" por "argv", que es como lo tiene puesto Coffin, y lo que obtengo es esto:

Código:
C:\Documents and Settings\Administrator\Desktop\dcraw\dcraw.exeP -v\ -wp -HE 2O -oN 0I -q3 7
Cuando debería ser así:

Código:
C:\Documents and Settings\Administrator\Desktop\dcraw\dcraw.exe -v -w -H 2 -o 0 -q 7 -T -N 2 2 4000 -G 95 D700hSLI25600.NEF
¿Alguna idea de por qué sucede? El número de opciones las cuenta bien (son 16) pero escribe sólo la mitad añadiéndoles caracteres que no tengo ni idea de dónde salen.

No te comas mucho la cabeza si te quita tiempo, podré vivir sin ello.
Vale, ya lo he podido probar, aquí tienes el código corregido:
Código:
  int i,l;
  char *command_line,*pos;

  for(i=l=0;i<argc;i++) l+=strlen(argv[i])+1;
  command_line=(char *)malloc(l+1);
  if(command_line){
    for(i=l=0,pos=command_line;i<argc;i++,pos++){    
      memcpy(pos,argv[i],l=strlen(argv[i]));
      pos+=l;
      *pos=0x20;
    }
    *pos=0x00;
    // Do something with command_line
    free(command_line);
  }
Además de eso, tienes que cambiar en las opciones de compilación de Unicode a Multibyte. Está en General -> Juego de caracteres. Por eso te sale sólo la mitad de la cadena.

Cita:
Iniciado por Lassus Ver Mensaje
AFD para mi gusto es el mejor. Es posible que AHD consiga mejor luminancia, pero tiene artefactos de color en la barandilla y confunde la dirección de las hojas. VCD no sale muy bien parado en nada.
A mí desde luego VCD no me ha aportado nada. AFD es un algoritmo muy bien balanceado, sólo me molestan los píxeles que se van de madre en algunas imágenes, especialmente en los rojos y azules saturados.

Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos
  #103 (permalink)  
Antiguo 20-ene-2009, 23:15
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Cita:
Iniciado por Egon Ver Mensaje
Uff como os cunde cuando no tengo tiempo de leer...

Sólo decir que Linux hay de 32bits y 64 bits. Yo en casa lo uso a 64bits en el fijo y a 32bits en el portátil.
¿Y has probado a compilar dcraw en 64 bits?

Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos
  #104 (permalink)  
Antiguo 21-ene-2009, 00:39
Avatar de Raulcc
Enganchad@ a los foros
 
Fecha de Ingreso: octubre-2005
Ubicación: Pineda de Mar
Mensajes: 1.030
Enviar un mensaje por MSN a Raulcc
Hola!! Una pregunta que me imagino que va a ser que no pero bueno: hay version para mac?? Es que yo estuve probando el programa en windows y me gustó mucho, pero ahora me he pasado a mac y no hay vuelta atrás.

Saludos!!
__________________
El mejor libro: Luces de Montaña, Galen Rowell. El maestro de la luz.

web: www.raulcomino.com
  #105 (permalink)  
Antiguo 21-ene-2009, 01:16
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Cita:
Iniciado por Raulcc Ver Mensaje
Hola!! Una pregunta que me imagino que va a ser que no pero bueno: hay version para mac?? Es que yo estuve probando el programa en windows y me gustó mucho, pero ahora me he pasado a mac y no hay vuelta atrás.
La habrá, y esperamos que al mismo o casi al mismo tiempo que la 1.0 para Windows y Linux.

Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos
  #106 (permalink)  
Antiguo 21-ene-2009, 01:19
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Bueno, ya tengo el mini gestor de memoria acabado para los buffers intermedios a cachitos. Funciona bien y es considerablemente rápido, aunque una pizca más lento. Variando el parámetro BUFFER_SIZE se logrará más o menor velocidad/fragmentación.

Para los curiosos, este es el código:
Código:
#define BUFFER_SIZE 25000000

void FreeBuffer(void *buffer){  
  size_t *stBuffer;
  int *iBuffer;

  stBuffer=buffer;
  iBuffer=stBuffer[1];
  do{
    free(stBuffer);
    stBuffer=iBuffer;
    iBuffer=stBuffer[1];
  }while(iBuffer!=NULL);  
  free(stBuffer);
}

void *AllocBuffer(size_t size){
  int *iBuffer=NULL;
  size_t *stBuffer=NULL;
  void *fBuffer;

  while(size>BUFFER_SIZE){           
    size-=BUFFER_SIZE;
    stBuffer=(size_t *)malloc(BUFFER_SIZE+sizeof(int)+sizeof(size_t));
    if(!stBuffer){
      // Release previous buffers     
      if(iBuffer!=NULL){
        iBuffer[0]=NULL;
        FreeBuffer(fBuffer);
      }
      return NULL;    
    }
    if(iBuffer!=NULL){
      iBuffer[0]=stBuffer; // Next reference    
    }else{
      fBuffer=stBuffer; // First Buffer
    }
    stBuffer[0]=BUFFER_SIZE;
    iBuffer=&stBuffer[1];
  }

  // Last
  if(size>0){
    stBuffer=(size_t *)malloc(size+sizeof(int)+sizeof(size_t));
    if(!stBuffer){
      // Release previous buffers           
      if(iBuffer!=NULL){
        iBuffer[0]=NULL;
        FreeBuffer(fBuffer);
      }
      return NULL;    
    }
    if(iBuffer!=NULL){
      iBuffer[0]=stBuffer; // Next reference    
    }else{
      fBuffer=stBuffer; // First Buffer
    }
    stBuffer[0]=size; 
    iBuffer=&stBuffer[1];        
  }
  iBuffer[0]=NULL; // This is the last           
  return fBuffer;
}

void CopyToBuffer(void *buffer,char *origin){
  size_t *stBuffer;
  int *iBuffer;
  size_t size;
  char *ptr;

  stBuffer=buffer;
  size=stBuffer[0];
  iBuffer=stBuffer[1];  
  do{
    ptr=stBuffer;
    memcpy(ptr+sizeof(int)+sizeof(size_t),origin,size);
    origin+=size;
    stBuffer=iBuffer;
    size=stBuffer[0];
    iBuffer=stBuffer[1];
  }while(iBuffer!=NULL);
  if(size>0){
    ptr=stBuffer;
    memcpy(ptr+sizeof(int)+sizeof(size_t),origin,size);
  }
}

void CopyFromBuffer(char *destination,void *buffer){
  size_t *stBuffer;
  int *iBuffer;
  size_t size;
  char *ptr;

  stBuffer=buffer;
  size=stBuffer[0];
  iBuffer=stBuffer[1];
  do{ 
    ptr=stBuffer;
    memcpy(destination,ptr+sizeof(int)+sizeof(size_t),size);
    destination+=size;
    stBuffer=iBuffer;
    size=stBuffer[0];
    iBuffer=stBuffer[1];
  }while(iBuffer!=NULL);
  if(size>0){
    ptr=stBuffer;
    memcpy(destination,ptr+sizeof(int)+sizeof(size_t),size);  
  }
}
#undef BUFFER_SIZE
De momento y, a pesar de esta mejora, aún falla con las imágenes grandes, pero eso era de esperar, dado que el buffer enorme del final se sigue intentando reservan contiguo. Lo que me queda es mejorar eso. Tengo una idea para dejarlo al menos reducido a un cuarto del tamaño actual contiguo, pero ya veremos si funciona. Si no lo hace, entonces habrá que pensar en otro cosa (tirar de HD ), aunque el problema es el que ya dije, de eso estoy seguro.

Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos
  #107 (permalink)  
Antiguo 21-ene-2009, 16:49
Habitual
 
Fecha de Ingreso: diciembre-2006
Ubicación: Madriz y Cantabria
Mensajes: 201
Ufa, ¡que de tiempo hacía que no me pasaba por Ojo Digital! Veo que vuestro proyecto va como una moto. Espero que algún día se convierta en mi revelador favorito, y que - un poquito más adelante (pero poco, ¿eh?)- seáis el relevo completo a Photoshop.

Mientras, quería probar la actual versión de PerfectRAW, pero me encuentro con un problemilla tonto: ¿Como lo hago? ¿El fichero .exe que encuentro en el zip, es directamente el ejecutable? ¿Habéis escrito algunas instrucciones? ¿Hay algo de documentación sobre como usar el programa (algún pequeño guiaburros para idems)?

Una sugerencia que espero consideréis, es la de crear un subforo con la única finalidad de a) tener un enlace a la última versión del producto y b) enlaces a la documentación y notas que tengáis (por poca que sea siempre se agradece a los que nos topamos con un proyecto así por primera vez). Ese subforo solo estaría abierto para el común de los mortales y mientras menos comentarios y paja tuviese mejor: sería una manera rápida y cómoda de iniciarse en PerfectRaw sin tener que rebuscar entre tantos hilos ya abiertos

Enhorabuena a todos los que desarrolláis y trabajáis en el proyecto. Saludos.
  #108 (permalink)  
Antiguo 22-ene-2009, 00:28
Avatar de LArasanz
Lleva poco por aquí
 
Fecha de Ingreso: agosto-2008
Ubicación: Barcelona
Mensajes: 134
Estoy de acuerdo.... Creo que un manual guaburros seria muy util, puesto que las veces que he probado el programa no acabo de ver la diferencia entre activar varias de las opciones.

Otra cosa seria la doble ventana de revelado para comprobar las diferencias de los parametros, pero creo que eso aun esta por desarrollar

Saludos y seguir asi, que los mortales acabaremos aprendiendo algo sobre como revelar.
__________________
Lluis Arasanz
(Creciendo y aprendiendo...)

Si quieres ver mis Fotos, sigue el enlace. No olvides dejar tus comentarios!!!

http://picasaweb.google.es/Lluis.Arasanz

Última edición por LArasanz; 22-ene-2009 a las 00:29. Razón: Correcciones gramaticales
  #109 (permalink)  
Antiguo 22-ene-2009, 09:39
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Para Oneteacup y LArasanz:

Gracias en nombre de todo el equipo por vuestras sugerencias, ánimo y felicitaciones.

Desde luego que el programa tendrá un manual y unas instrucciones. Además estamos desarrollando nuestra propia página, www.bytedelight.com (en este momento funcional pero de aspecto provisional y de contenido escaso). Dado que aún estamos en la versión 0.65 y que el interfaz es provisional (el definitivo lo está programando Egon utilizando OpenGL), no hemos querido dedicar tiempo a escribir documentación que tendrá que ser reescrita más adelante. Nuestro desarrollo aún no ha abandonado la fase experimental, como demuestra el contenido de este tema en el que ando probando diferentes estrategias para aprovechar al máximo la RAM disponible y que, desafortunadamente, cambiarán ligeramente el proceso de revelado. Además, en este momento todos los esfuerzos del equipo se están dedicando a programar.

En cualquier caso, como ya he dicho, nuestro afán es que junto a la versión 1.0, o antes una vez tengamos el interfaz definitivo, crearemos manuales y demás. Aunque debéis tener en cuenta que perfectRAW es un revelador técnico, que siempre obligará al usuario a tener un conocimiento exacto de lo que hace. A cambio le dará un control mucho mayor de cada fase del revelado que otros reveladores y una forma de navegar por la imagen cómoda y rápida.

Respecto a vuestras dudas concretas:
  • Para instalar la aplicación hay que descomprimir el .ZIP en una carpeta, instalar la fuente .TTF y ejecutar el .EXE. Y ya está.
  • En la última versión subida, manteniendo pulsado espacio podéis ver el revelado anterior. Me temo que para saber lo que hace cada parámetro tendréis que aprender primero a manejar dcraw (con el estupendo manual de la página de Guillermo) y luego leeros este foro para entender los añadidos a dcraw que hemos creado nosotros... una ardua tarea, tal vez; espero que el resultado lo compense. ¡Ánimo!
Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Última edición por ManuelLlorens; 22-ene-2009 a las 09:44.
  #110 (permalink)  
Antiguo 22-ene-2009, 22:00
Lleva poco por aquí
 
Fecha de Ingreso: septiembre-2007
Ubicación: Costa Rica
Mensajes: 23
Hola, he estado probando la ultima version del programa, cambiando las opciones y he notado que cuando el balance de blancos esta en auto las fotos salen con un dominate azul, lo que antes no sucedia, pues era muy similar al balance de la camara, ahora la diferencia es notoria. Estoy hablando de raws de la Sony A100. Por lo demas todo funciona de maravilla, saludos
  #111 (permalink)  
Antiguo 22-ene-2009, 22:36
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Cita:
Iniciado por Sipa Ver Mensaje
Hola, he estado probando la ultima version del programa, cambiando las opciones y he notado que cuando el balance de blancos esta en auto las fotos salen con un dominate azul, lo que antes no sucedia, pues era muy similar al balance de la camara, ahora la diferencia es notoria. Estoy hablando de raws de la Sony A100. Por lo demas todo funciona de maravilla, saludos
¿Salen azuladas en pantalla, en el TIFF o en ambos?
¿Con dcraw y las mismas opciones salen distintas?
¿Te pasa con las opciones por defecto?
¿Con qué versión anterior no te pasaba? ¿Con las mismas imágenes?

Es que es bastante raro, porque no he tocado nada en esa línea. Gracias por probar.

Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos
  #112 (permalink)  
Antiguo 22-ene-2009, 22:57
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Bueno, después de darle bastantes vueltas esta semana voy a tener que implementar la fase final del revelado de un modo que no me gusta demasiado, pero que es la única que garantizará memoria suficiente. El resultado será algo lento en imágenes grandes. Lo que voy a hacer es tratar de reservar al principio del revelado toda la memoria necesaria y si lo consigo revelar en modo rápido pero usando memoria y si no lo consigo en modo más lento pero usando menos memoria.

Además me he preparado un memcpy con SSE2 que aún tengo que probar bien para tratar de compensar la ralentización que se ha producido en el código de los buffers intermedios (aunque la verdad es que yo no la noto, pero si hace que vaya aún rápido, ¿por qué no usarla?).

Con los cambios nuevos, cuando no hay suficiente memoria contigua disponible sólo se usará un buffer del tamaño completo de la imagen contiguo (ese es siempre inevitable y los demás irán discontinuos). Además, si la imagen no necesita girarse pR va ahora bastante más rápido en la última fase y consume mucha menos memoria... así que nada de disparar en vertical los que tengan poca RAM en la máquina, ¿eh? .

Cuando lo tenga todo listo habrá que migrar esos cambios a la salida a JPEG/TIFF... ¡qué perezón! .

Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos
  #113 (permalink)  
Antiguo 22-ene-2009, 23:25
Habitual
 
Fecha de Ingreso: diciembre-2006
Ubicación: Madriz y Cantabria
Mensajes: 201
Gracias, Manuel, por tu rápida respuesta. Mañana probaré a instalarlo en el ordenata con güindous (esta noche me siento demasiado perezoso) y ver si consigo hacer que me funcione. Sí, en su día probé el invento de GUI, y tengo sus excelentes notas sobre DCRAW, así que algo sacaré en limpio, espero,

Cuando hablaba sobre "documentación" en mi post anterior, no me refería necesariamente a escribir ahora un tocho de manual. Comprendo vuestro esfuerzo y vuestras prioridades. Pero aunque solo fuese una recopilación de notas y posts (como este último tuyo) en algún sitio visible o un stick-it sería muy, muy útil a los que queremos probar vuestro programa.

Gracias de nuevo y un saludo a todos.
  #114 (permalink)  
Antiguo 22-ene-2009, 23:32
Avatar de Vlihada
Habitual
 
Fecha de Ingreso: septiembre-2007
Ubicación: .
Mensajes: 776
Flipo con vosotros...
Como os lo currais...
  #115 (permalink)  
Antiguo 22-ene-2009, 23:55
Avatar de LArasanz
Lleva poco por aquí
 
Fecha de Ingreso: agosto-2008
Ubicación: Barcelona
Mensajes: 134
Hola Manuel y resto de colaboradores....

Tal como dices, ya se que tocar un revelador como PerfectRaw necesita conocimientos técnicos (que por otro lado he aprendido gracias a este y otros hilos, a GUI, y por supuesto a ti), pero como apunta Oneteacup, con solo apuntes que indiquen que hace o a que afecta cada control seria un gran paso.

Por ejemplo, como afecta el valor de "Noise detection" al Demosaicing, si actua antes o despues del mismo....

Vamos, unas notas con un mini diagrama de proceso para saber que parametro afecta a que fase del revelado.

Aun asi´, seuiremos jugando con el revelador para intentar comprender un poco más como funciona... y seguiremos flipando con las explicaciones que dais en el foro.

Adelante, que lo haceis de maravilla!!!

Saludos
__________________
Lluis Arasanz
(Creciendo y aprendiendo...)

Si quieres ver mis Fotos, sigue el enlace. No olvides dejar tus comentarios!!!

http://picasaweb.google.es/Lluis.Arasanz
  #116 (permalink)  
Antiguo 23-ene-2009, 00:44
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Bueno pues ahí va eso:

Instalación:
  • Descomprimir el contenido del .ZIP en una carpeta. Instalar la fuente .TTF en el directorio de fuentes de Windows. Ejecutar el .EXE.
Configuración:
  • Si se quiere gestión de color ICC para la salida por pantalla (la única activa en esta versión, es decir, que no simulará dispositivos de salida ni tendrá en cuenta el perfil de la cámara) hay que modificar el archivo config.xml para decirle a la aplicación dónde está el perfil en el disco.
Controles:
  • HIGHLIGHT RECOVERY: recuperación de altas luces, es el mismo código de Coffin. Por encima de 2 se aplica al final de todo el revelado, =2 al realizar el balance de blancos. Más información en el curso de Guillermo sobre dcraw.
  • NOISE ATTENUATION: NONE/AFD, activa o desactiva la atenuación adaptativa de ruido RAW. Se acompaña del parámetro NOISE DETECTION que regula lo mucho (100%) o poco (0%) que se atenuarán los píxeles ruidosos. Se aplica antes de interpolar basándose en un mapa de textura extraído de la luminancia de la interpolación AFD. Sobre ese mapa se calcula la desviación típica de las celdas 3x3 alrededor de cada píxel y se compara con la del píxel en cuestión. Si es superior a un umbral se mezcla el píxel con el valor medio de la celda 3x3 en función del parámetro NOISE DETECTION (que no debería llamarse así) y el diafragma al que pertenece el entorno 3x3 del píxel.
  • RAW NOISE REDUCTION: es la reducción de ruido por Wavelets de Coffin. Se aplica antes de la interpolación, justo después del balance de blancos. Para aplicarla y no tener que hacer una preinterpolación (como hace lo anterior) empaqueta previamente los canales en una imagen mitad de ancho y mitad de alto. No es efectivo para ISOs altos, pero sí para zonas ruidosas en imágenes con ISOs bajas. Es necesario usar parámetros altos para lograr resultados efectivos (entre 100 y 1000, por ejemplo). Más información en la documentación de dcraw.
  • EXPOSURE CONTROL: se aplica después de la recuperación de altas luces y sube linealmente la exposición de toda la imagen. Se controla mediante EXPOSURE que son los pasos de exposición a subir o bajar y PRESERVATION que controla los diafragmas (desde el más alto) que no se tocarán.
  • INTERPOLATION ALGORITHM: los dos BILINEAR (que es como debería aparecer, y no bilineal) no valen para imágenes reales, pero son rápidos para dar un preview. El RGGB sirve para que en las Olympus y Panasonic no salgan artefactos (es equivalente a la opción -f de dcraw). VNG no sirve para nada desde mi punto de vista salvo que se quiera usar VNG RGGB para quitar los laberintos, pero para eso está el equilibrado de canales verdes (más adelante). PPG es el que mejor balance calidad/velocidad da. AHD es el mejor en imágenes sin ruido, aunque cuando falla falla de verdad. AFD es el más equilibrado de todos, pero falla en texturas Nyqüist. En ISO altas es el mejor. VCD no aporta nada desde mi punto de vista... especialmente a la versión modificada de AFD, que no está activa en esta versión.
  • ONLY LUMINANCE: como su nombre indica extrae la luminancia LAB de la imagen y descarta la crominancia. Se aplica después de la interpolación.
  • WHITE BALANCE: no creo que requiera mucha explicación. En modo USER permite especificar los multiplicadores.
  • GREEN EQUILIBRATION: NONE, GLOBAL, GLOBAL+LOCAL. Equilibra los canales verdes G1 y G2 para evitar artefactos en las Olympus y Panasonic (especialmente con sensores Kodak). GLOBAL calcula el nivel medio en toda la imagen de cada canal y luego lleva los dos a la media, LOCAL hace lo mismo en celdas del radio especificado, que no hace falta tocar (al menos yo no he encontrado ninguna imagen que lo necesite).
  • CHROMATIC ABERRATIONS: la reducción de aberraciones cromáticas de Coffin. Ver la documentación de dcraw.
  • SATURATION LEVEL: el nivel de saturación de la cámara. En principio sólo hay que tocarlo para algunas cámaras, cuando las altas luces presentan un tono extraño.
  • BLACK LEVEL: el nivel de negro de la cámara. En las Nikon ya está restado en el RAW por lo que es 0. No es recomendable tocarlo.
  • MEDIAN FILTER PASSES: pasos de filtro mediana en los canales R y B para eliminar artefactos de color en los bordes. Con PPG/AHD usar 1 ó 2, con AFD como mucho 1. En ISOs altas se puede usar hasta 10, aunque es lento.
  • ES MEDIAN FILTER PASSES: pasos del filtro mediana sensible a ejes de Paul Lee, más información en su página. Útil para imágenes donde AHD equivoca claramente la dirección de interpolación.
  • EECI REFINE: pasos del refinado de la interpolación basado en el algoritmo EECI, implementación de Paul Lee, más información en su página. Para ISOs altas se puede probar con un valor > 4, aunque es lento.
  • SNAPSHOT: (arriba a la izquierda) fija el último revelado para las comparaciones antes/después.
Teclas/Ratón:
  • TAB: conmuta el modo pantalla completa.
  • ENTER: revela.
  • SPACE: conmuta con el revelado anterior (mantener pulsado).
  • ARRASTRAR el ratón sobre la imagen: desplazamiento.
  • RUEDA del ratón sobre la imagen: zoom.
  • DOBLE CLICK del ratón sobre la imagen: volver a zoom x1.
Otras características:
  • De momento toda la salida (pantalla, TIFF, JPEG) es en sRGB con gamma sRGB exacta (que no 2.2). Los TIFF llevan esa información incrustada, por lo que pueden abrirse con cualquier visor de imágenes sin problemas.
  • Los TIFFs y JPEGs se guardan en el mismo directorio donde estuviera en RAW con el mismo nombre, pero con la extensión adecuada.
  • Más información sobre la versión 0.65 en concreto (cambios, errores conocidos, cosas por hacer...) en la primera entrada de este tema, junto con los enlaces para descargar.
Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Última edición por ManuelLlorens; 23-ene-2009 a las 11:55.
  #117 (permalink)  
Antiguo 23-ene-2009, 01:07
Avatar de tonilupi
Habitual
 
Fecha de Ingreso: julio-2005
Ubicación: Palma de Mallorca
Mensajes: 386
Manuel, gracias por tu dedicación, vaya manualillo nos has brindado, yo iba tocando hasta conseguir el mejor resultado.

Tengo una pregunta sobre la salida, en jpg en mi caso, y es que la imagen queda muy apagada, no se si técnicamente sería cosa de la gamma (si no recuerdo mal DCRAW puede entregar la imagen sin corrección de gamma).

Luego desde gimp con las curvas de color "levanto" los colores y me queda niquelada.

Salut
__________________
[U]ToniLupi[/U]

Mis imágenes en [URL="http://www.pbase.com/tonilupi"]http://www.pbase.com/tonilupi[/URL]

Eos 400D + 100mm macro f2.8 USM
  #118 (permalink)  
Antiguo 23-ene-2009, 01:11
Avatar de LArasanz
Lleva poco por aquí
 
Fecha de Ingreso: agosto-2008
Ubicación: Barcelona
Mensajes: 134
Cita:
Iniciado por ManuelLlorens Ver Mensaje
Bueno pues ahí va eso:

...

Un saludo:

Manuel...


Cuando programas eres de los que documentas todo el codigo, verdad?

Es, a mi parecer, justo lo que hacia falta. Una sencilla explicacion de para que sirve cada control. Chapeau. Me quito el sombrero y quedo a tus pies.

Animo y seguid así.

Saludos
__________________
Lluis Arasanz
(Creciendo y aprendiendo...)

Si quieres ver mis Fotos, sigue el enlace. No olvides dejar tus comentarios!!!

http://picasaweb.google.es/Lluis.Arasanz
  #119 (permalink)  
Antiguo 23-ene-2009, 12:00
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Cita:
Iniciado por tonilupi Ver Mensaje
Manuel, gracias por tu dedicación, vaya manualillo nos has brindado, yo iba tocando hasta conseguir el mejor resultado.

Tengo una pregunta sobre la salida, en jpg en mi caso, y es que la imagen queda muy apagada, no se si técnicamente sería cosa de la gamma (si no recuerdo mal DCRAW puede entregar la imagen sin corrección de gamma).

Luego desde gimp con las curvas de color "levanto" los colores y me queda niquelada.
¿Con perfectRAW? En perfectRAW la gamma ya está aplicada tanto en pantalla como en la salida a disco (bien sea TIFF o JPEG). El aspecto descontrastado y desaturado de los revelados de perfectRAW es debido a que nosotros no hacemos ajustes a la imagen por defecto, como sí hacen otros reveladores. El resultado está pensado para pasarlo a un buen editor de imágenes y aplicar en él lo que quieras (contraste, saturación, ajustes locales, etc). En el futuro aplicaremos curvas y saturación antes de la conversión al espacio de color de salida para maximizar la calidad del resultado.

Otro ajuste que nosotros no hacemos es el enfoque. Un buen algoritmo de enfoque está más allá de nuestras posibilidades actuales, en un momento dado pondremos un USM de calidad, pero no dejará de ser un USM.

La única diferencia, por tanto, con dcraw está en la aplicación de la gamma.
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos
  #120 (permalink)  
Antiguo 23-ene-2009, 17:07
Lleva poco por aquí
 
Fecha de Ingreso: septiembre-2007
Ubicación: Costa Rica
Mensajes: 23
Hola Manuel, aca dejo el resultado del reveleado en PPG parametros por defecto, convertido a jpg tomado del tiff, sin ningun tratamiento:



y aca el resultado en PPG, con el balance de blancos en Camara, los demas pararametros por defecto, tambien tomado del tiff:



como se puede apreciar el balance de blancos en auto de una dominante azul y asi sucede con otros algoritmos como el bilinear y el AHD, en la version 0.6 no era tan notoria la diferencia.
Claro que con el balance de la camara los colores salen muy fieles y el resultado es excelente. Gracias por todos tus esfuerzos y por este gran programa. Saludos

Última edición por Sipa; 23-ene-2009 a las 17:10.
  #121 (permalink)  
Antiguo 23-ene-2009, 17:33
Avatar de NaVaS
Lleva poco por aquí
 
Fecha de Ingreso: noviembre-2008
Ubicación: Murcia - Zaragoza
Mensajes: 177
Lo he pasado al otro hilo.

Última edición por NaVaS; 25-ene-2009 a las 10:35.
  #122 (permalink)  
Antiguo 23-ene-2009, 17:50
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Algunos resultados de velocidad sobre las pruebas de memoria que ando haciendo.

Los resultados Sparse son con mis buffers en cachitos (he rehecho todo el código, el de arriba está obsoleto), los Normal son contiguos. Comparo con y sin la librería Hoard. Está claro que reservar y liberar memoria no es un problema (harían falta muchas ejecuciones para notar la diferencia), y que al copiar entre buffers sí tendremos un retardo, tardan aproximadamente el doble con y sin Hoard.

La buena noticia es que utilizando SSE2 podemos reducir esa diferencia a una décima y media de segundo en la copia de 300 megas, lo que viene a ser inapreciable. Es decir, que entre la versión que está subida ahora (normal memcpy con MSVCRT) que tarda 0,5109 s en mover 300 megas y la próxima versión que subiré (sparse memcpy SSE2 con Hoard) que tardará 0,6453 s en mover el mismo buffer, la diferencia es de 0,15 segundos. Al repetir ese proceso con los 5 buffer que mueve 5·0,15 = 0,75 segundos de retardo total en el revelado de una imagen de 300 megas (las Hasselblad). No está nada mal. Eso si hay memoria suficiente, si no tardará menos en el primer revelado y más en los siguientes. El tiempo extra para reservar y liberar esos buffers es totalmente despreciable como se ve en los datos de abajo.

El mérito de la codificación del memcpy con SSE2 es de William Chan, al que mandaré un mail si acabamos utilizando su código, como pide en su página. Para qué reinventar la rueda.

Todas las pruebas con cachos de buffer de 2^25 = 33.554.432 bytes (mejor usar trozos potencia de 2 mientras sea posible), o sea, unos 33 megas. Al mover 300 megas salen 8 cachos de ese tamaño y otro más pequeño de 31.564.544 bytes, todo eso se gestiona internamente.

Con MSVCRT:
  • Sparse alloc + free (10000 executions/300 Mb): elapsed time = 2.172s
  • Normal alloc + free (10000 executions/300 Mb): elapsed time = 0.156s
  • Sparse memcpy (10 executions/300 Mb): elapsed time = 9.578s
  • Normal memcpy (10 executions/300 Mb): elapsed time = 5.109s
Con Hoard:
  • Sparse alloc + free (10000 executions/300 Mb): elapsed time = 1.500s
  • Normal alloc + free (10000 executions/300 Mb): elapsed time = 0.141s
  • Sparse memcpy (10 executions/300 Mb): elapsed time = 9.328s
  • Normal memcpy (10 executions/300 Mb): elapsed time = 5.031s
Con Hoard y SSE2:
  • Sparse memcpy SSE2 (10 executions/300 Mb): elapsed time = 6.453s
  • Normal memcpy SSE2 (10 executions/300 Mb): elapsed time = 3.640s
Ahora me queda implementar una función que lea los píxeles de los buffers dispersos de uno en uno y ya lo tendré todo.

Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Última edición por ManuelLlorens; 25-ene-2009 a las 01:37.
  #123 (permalink)  
Antiguo 23-ene-2009, 17:55
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Cita:
Iniciado por Sipa Ver Mensaje
como se puede apreciar el balance de blancos en auto de una dominante azul y asi sucede con otros algoritmos como el bilinear y el AHD, en la version 0.6 no era tan notoria la diferencia.
Claro que con el balance de la camara los colores salen muy fieles y el resultado es excelente. Gracias por todos tus esfuerzos y por este gran programa. Saludos
Es raro, yo diría que tanto amarillo engaña a dcraw. El caso es que no he cambiado nada que pueda hacer distintos los resultados entre la 0.6 y la 0.65. ¿Puedes revelarla con la última versión de dcraw a ver qué hace? Eso o súbeme la imagen a algún sitio para que pruebe.

Gracias. Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Última edición por ManuelLlorens; 23-ene-2009 a las 18:01.
  #124 (permalink)  
Antiguo 23-ene-2009, 23:12
Lleva poco por aquí
 
Fecha de Ingreso: septiembre-2007
Ubicación: Costa Rica
Mensajes: 23
Cita:
Iniciado por ManuelLlorens Ver Mensaje
Es raro, yo diría que tanto amarillo engaña a dcraw. El caso es que no he cambiado nada que pueda hacer distintos los resultados entre la 0.6 y la 0.65. ¿Puedes revelarla con la última versión de dcraw a ver qué hace? Eso o súbeme la imagen a algún sitio para que pruebe.

Gracias. Un saludo:
Hola Manuel, aca esta el revelado con la ultima version de dcraw, convertida a jpg y reducida de tamaño unicamente, saludos


Última edición por Sipa; 23-ene-2009 a las 23:21.
  #125 (permalink)  
Antiguo 24-ene-2009, 10:01
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Cita:
Iniciado por Sipa Ver Mensaje
Hola Manuel, aca esta el revelado con la ultima version de dcraw, convertida a jpg y reducida de tamaño unicamente, saludos
Entiendo que con el balance de blancos automático, ¿verdad? Voy a buscar un RAW de tu cámara y depurar a ver por qué ocurre.

[...]

Pues Sipa, siento decirte que he sido incapaz de reproducir lo que a ti te ocurre. He tomado un RAW de la Sony A-100 (de raws.fotosite.pl). Lo he revelado con dcraw.exe último código de Coffin, dcraw.exe con nuestras modificaciones (sin usar gamma) y perfectRAW (quitando la gamma para poder compararlo con el de Coffin y luego con gamma para descartar que fuera el cálculo de la gamma el que mete colores extraños), todos ellos con balance de blancos automático, y en todos obtengo idéntico resultado (e idénticos multiplicadores). Sí es cierto que el auto se desvía considerablemente del de la cámara, pero eso no me parece significativo.

He comparado el código de nuestra DLL (que es también el de nuestro ejecutable) línea a línea con el último código de Coffin y no hay nada que pueda explicar lo tuyo. He aprovechado para limpiar mi código y dejarlo tan idéntico al de Coffin como ha sido posible, arreglando alguna línea en blanco, algún tabulador de más. Es el primer paso para separar todo mi código del de Coffin y dejarlo en un include a parte. Es decir, que no ha sido trabajo en vano.

Si el revelado de arriba con dcraw lo has hecho con -a, pásame tu ARW a ver qué le pasa; en caso contrario, repítelo con -a, a ver si era eso.

Es un poco absurdo subir esto, porque son píxel a píxel idénticos:
dcraw de Coffin:

dcraw nuestro:

perfectRAW 0.65 (sin gamma):

perfectRAW 0.65 (con gamma sRGB exacta):

perfectRAW 0.65 (con gamma sRGB exacta y balance de blancos de la cámara):


Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Última edición por ManuelLlorens; 24-ene-2009 a las 11:28.
  #126 (permalink)  
Antiguo 24-ene-2009, 18:03
Lleva poco por aquí
 
Fecha de Ingreso: septiembre-2007
Ubicación: Costa Rica
Mensajes: 23
Hola Manuel

Menudo curro te has fajado, excelente trabajo y muy ilustrativo, voy a seguir ensayando, no soy muy ducho en estas lides pero con respuestas como estas se va aprendiendo muchisimo, te enviare por mail el ARw, muchas gracias y saludos
  #127 (permalink)  
Antiguo 24-ene-2009, 22:08
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Cita:
Iniciado por Sipa Ver Mensaje
Menudo curro te has fajado, excelente trabajo y muy ilustrativo, voy a seguir ensayando, no soy muy ducho en estas lides pero con respuestas como estas se va aprendiendo muchisimo, te enviare por mail el ARw, muchas gracias y saludos
Bueno, siempre viene bien darle un repaso a la aplicación, así que gracias a ti.

Respecto a tu imagen, si revelo con dcraw última versión con código de Coffin y la opción -a, balance de blancos automático, el resultado es idéntico al de perfectRAW pero sin gamma claro.

Los multiplicadores lo dicen todo:
De la cámara:
2.016582 1.000000 1.385056 1.000000
Automáticos:
1.115889 1.000527 7.662307 1.000000

Fíjate en el valor del multiplicador azul. Es decir que la imagen tiene tanto amarillo que engaña al balance de blancos automático que cree que la imagen se ha hecho bajo una fuente de luz muy amarilla... tipo lámpara de sodio, y al compensar aparecen esos azules.

Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Última edición por ManuelLlorens; 25-ene-2009 a las 01:35.
  #128 (permalink)  
Antiguo 24-ene-2009, 22:10
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Gracias Guillermo por poner el manual en su sitio .

Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos
  #129 (permalink)  
Antiguo 24-ene-2009, 23:16
Habitual
 
Fecha de Ingreso: febrero-2007
Ubicación: Barcelona
Mensajes: 271
Primero de todo deciros que el trabajo que hacéis es digno de admiración, y me encanta leeros aunque no entienda casi nada de lo que decís, jejeje, es que me gusta programar, pero claro, a otro nivel.

El mini-manual o explicación de que hace cada parámetro, creo que era imprescindible para que los neófitos podamos echaros una mano, a mi en concreto me ha ido muy bien para no perder el tiempo tocando cosas que no me iban a dar ningún resultado.

Hoy he empezado a usar el programa, y después de darle muchas vueltas a una imagen, la he pasado al PS y la he retocado, pero cuando me disponía a darle el toque final "estampar la firma" me he dado cuenta que las dos lineas de píxeles inferiores no están ¿?, os pego una captura. Os puedo asegurar que no he movido la capa ni nada parecido, el Tiff sale tal cual, y lo he probado con un par de RAW's.



Revelado con el algoritmo PPG y un RAW de una 40D.

Un saludo.
__________________
Galerías en:
http://hgonzag.deviantart.com
http://hgonzag.imagekind.com/

Última edición por cLIP; 24-ene-2009 a las 23:20.
  #130 (permalink)  
Antiguo 25-ene-2009, 01:00
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Cita:
Iniciado por Vlihada Ver Mensaje
Flipo con vosotros...
Como os lo currais...
Se me había pasado contestarte Vlihada. Gracias.

Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos
  #131 (permalink)  
Antiguo 25-ene-2009, 01:09
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Cita:
Iniciado por cLIP Ver Mensaje
Primero de todo deciros que el trabajo que hacéis es digno de admiración, y me encanta leeros aunque no entienda casi nada de lo que decís, jejeje, es que me gusta programar, pero claro, a otro nivel.
Pues muchas gracias hombre. Programes al nivel que programes, si programas, es cuestión de ponerse las pilas. ¡Ánimo! Aprende un poco de C, bájate el código de Coffin y aprenderás muchas cosas sobre cómo se revelan los RAWs y, si tienes dudas pregunta por aquí, que entre unos y otros intentaremos contestarte .

Cita:
Iniciado por cLIP Ver Mensaje
El mini-manual o explicación de que hace cada parámetro, creo que era imprescindible para que los neófitos podamos echaros una mano, a mi en concreto me ha ido muy bien para no perder el tiempo tocando cosas que no me iban a dar ningún resultado.
Sí, está claro que hacía falta algo así... ¡pero me daba un perezón escribirlo!

Cita:
Iniciado por cLIP Ver Mensaje
Hoy he empezado a usar el programa, y después de darle muchas vueltas a una imagen, la he pasado al PS y la he retocado, pero cuando me disponía a darle el toque final "estampar la firma" me he dado cuenta que las dos lineas de píxeles inferiores no están ¿?, os pego una captura. Os puedo asegurar que no he movido la capa ni nada parecido, el Tiff sale tal cual, y lo he probado con un par de RAW's.
Eso es porque Coffin no recorta ni un sólo pixel de los que trae el RAW, como sí hacen ACR y la mayoría de reveladores. En el caso de la esos RAWs está claro que debería quitar esos píxeles que no aportan nada. Es cuestión de cortarlos y punto. Pondré una opción en alguna futura versión para que se puedan recortar píxeles de los bordes (tipo margen izquierdo, derecho, arriba y abajo), o sea para hacer lo que dice tu nick: clip! .

A mí, en algunas imágenes de mi E-300, me sale un tono rojizo en la parte izquierda, es un cable que pasa cerca del sensor y al calentarse mete radiación infrarroja. Se nota más con ISOs altas y cuando la cámara lleva mucho tiempo encendida, lo tuyo puede ser algo similar. Obviamente con ACR no los ves porque los recorta, pero prefiero tenerlos y decidir yo si los corto que no tenerlos nunca, ¿no crees?

El caso es que en RAWs de la 40D que tengo para probar no me pasa, quizás sea cosa de tu cámara, aunque no se podría considerar un defecto si el programa de la propia Canon recorta esos píxeles. ¿Te pasa con las opciones de perfectRAW por defecto?

Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Última edición por ManuelLlorens; 25-ene-2009 a las 01:35.
  #132 (permalink)  
Antiguo 25-ene-2009, 01:46
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
He optimizado un poco más mi código (pasando la estructura que contiene mis buffers dispersos por referencia en vez de por valor) y he ganado una pizca de tiempo. Queda así la cosa:

Con hoard y SSE2:
  • Sparse memcpy SSE2 (10 executions/300 Mb): elapsed time = 6.297s
  • Normal memcpy SSE2 (10 executions/300 Mb): elapsed time = 3.531s
No viene nada mal.

Y estos son los resultados de la función que lee el buffer píxel a píxel:
  • Sparse read ushort (1000000000 executions/300 Mb): elapsed time = 11.563s
  • Normal read ushort (1000000000 executions/300 Mb): elapsed time = 11.515s
Ambas funciones leen píxel a píxel (16 bits) todo el buffer de 300 Mb mil millones de veces y lo hacen en un tiempo impresionante, la verdad. Tened en cuenta que son sólo lecturas y que la caché hará que vayan a toda velocidad. Está claro que en eso no se va notar ningún retraso.

Si intercalamos una escritura en medio (con lo que deshabilitamos la caché) el resultado cambia mucho (y es más representativo):
  • Sparse read ushort (10 executions/300 Mb): elapsed time = 4.516s
  • Normal read ushort (10 executions/300 Mb): elapsed time = 4.016s
Eso es lo que tarda en leer el buffer entero de 300 Mb 10 veces y guardar cada 16 bits en otro buffer de los normales. Lo más curioso de este resultado es que es más rápido que el memcpy con SSE2 de arriba. Tengo que mirarlo porque a lo mejor es de verdad más rápido.
________________________________________

Pues sí, lo cierto es que ahora va más rápido, ¡qué cosas! Entonces el resultado definitivo es:
  • Sparse new memcpy (10 executions/300 Mb): elapsed time = 5.531s
  • Normal memcpy SSE2 (10 executions/300 Mb): elapsed time = 3.437s
Fijaos que este resultado de 5.531s hay que compararlo con el resultado inicial con MSVCRT y los buffers contiguos, que era de 5.109s. Es decir que el retardo por usar buffers dispersos será pasar de 0.5109 s a 0.5531 s por cada buffer de 300 megas, como son 5 tendremos (0.5531-0.5109)·5 = 0.2, es decir sólo dos décimas de segundo en el revelado completo con todos los buffers intermedios de una imagen de 300 megas. Creo que es un resultado definitivo.

Ese era el único ladrillo que me faltaba, ahora me queda encajarlo todo y asegurarme de que todo funciona bien.

Éste es el código final:
Código:
#define BUFFER_POWER  0x19
#define BUFFER_SIZE   0x2000000 // 2^BUFFER_POWER
#define BUFFER_MASK   0x1ffffff  // 2^BUFFER_POWER-1

struct SparseBuffer{
  int n;
  size_t size;
  void **subBuffers;
};

void FreeSparseBuffer(struct SparseBuffer *buf){
  int i;

  if(buf->subBuffers){
    for(i=0;i<buf->n;i++){
      if(buf->subBuffers[i]) free(buf->subBuffers[i]);
    }
    free(buf->subBuffers);
    buf->subBuffers=NULL;
  }
}

void AllocSparseBuffer(struct SparseBuffer *buf,size_t size){  
  int i;
  
  buf->n=(int)(size >> BUFFER_POWER);
  if(size - buf->n*BUFFER_SIZE > 0) buf->n++;
  buf->subBuffers=(void **)calloc(buf->n,sizeof buf->subBuffers);
  merror(buf->subBuffers,"AllocSparseBuffer");
  buf->size=size;

  for(i=0;i<buf->n;i++) buf->subBuffers[i]=NULL;

  for(i=0;i<buf->n;i++){
    if(i<buf->n-1)
      buf->subBuffers[i]=(unsigned char *)malloc(BUFFER_SIZE);
    else
      buf->subBuffers[i]=(unsigned char *)malloc(size & BUFFER_MASK);
    if(!buf->subBuffers[i]){
      FreeSparseBuffer(buf);
      break;
    }
  }  
}

void CopyFromSparseBuffer(void *dst,struct SparseBuffer *buf){
  unsigned int i;

  for(i=0;i<buf->size;i+=4)    
    ((unsigned int *)dst)[i >> 2]=((unsigned int *)buf->subBuffers[i >> BUFFER_POWER])[(i & BUFFER_MASK) >> 2];
}

void CopyToSparseBuffer(struct SparseBuffer *buf,void *org){
  unsigned int i;

  for(i=0;i<buf->size;i+=4)
    ((unsigned int *)buf->subBuffers[i >> BUFFER_POWER])[(i & BUFFER_MASK) >> 2]=((unsigned int *)org)[i >> 2];
}

__inline unsigned short GetWordFromSparseBuffer(struct SparseBuffer *buf,unsigned long offset){
  return ((unsigned short *)buf->subBuffers[offset >> BUFFER_POWER])[(offset & BUFFER_MASK) >> 1];  
}

#undef BUFFER_SIZE
Las funciones críticas son CopyToSparseBuffer y GetWordFromSparseBuffer, que son las que más veces se ejecutarán. Yo no soy capaz de optimizarlas más, si a alguno se le ocurre algo que me lo diga.

Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Última edición por ManuelLlorens; 30-ene-2009 a las 01:41.
  #133 (permalink)  
Antiguo 25-ene-2009, 01:59
Avatar de NaVaS
Lleva poco por aquí
 
Fecha de Ingreso: noviembre-2008
Ubicación: Murcia - Zaragoza
Mensajes: 177
Manuel, el tema de poner un cuenta-gotas para el balance de blancos está en mente a corto plazo? o quizás para la versión con la nueva interfaz.

Cada vez me gusta mas PerfectRaw
Ese minitutorial seguro que trae más adeptos.

Otra cosa, podríais abrir algun hilo para que los novatos trabajemos con raws y aprendamos como sacar partido a ellos con PR.
La prueba que hice para enfoque iría por ejemplo en ese hilo, en este hilo quizá no tenga sentido.

Un saludo.

Última edición por NaVaS; 25-ene-2009 a las 02:04.
  #134 (permalink)  
Antiguo 25-ene-2009, 02:10
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Cita:
Iniciado por NaVaS Ver Mensaje
Manuel, el tema de poner un cuenta-gotas para el balance de blancos está en mente a corto plazo? o quizás para la versión con la nueva interfaz.

Cada vez me gusta mas PerfectRaw
Ese minitutorial seguro que trae más adeptos.

Otra cosa, podríais abrir algun hilo para que los novatos trabajemos con raws y aprendamos como sacar partido a ellos con PR.
La prueba que hice para enfoque iría por ejemplo en ese hilo, en este hilo quizá no tenga sentido.

Un saludo.
Lo de los cuentagotas, y también parches rectangulares y elípticos, irá en el nuevo interfaz.

Lo de abrir un nuevo hilo está hecho, gracias por la sugerencia, pero vamos que temas podéis abrir todos, no sólo los administradores.

Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos
  #135 (permalink)  
Antiguo 25-ene-2009, 11:00
Habitual
 
Fecha de Ingreso: febrero-2007
Ubicación: Barcelona
Mensajes: 271
Cita:
El caso es que en RAWs de la 40D que tengo para probar no me pasa, quizás sea cosa de tu cámara, aunque no se podría considerar un defecto si el programa de la propia Canon recorta esos píxeles. ¿Te pasa con las opciones de perfectRAW por defecto?
Si revelo por defecto obtengo una imagen de 3908x2602 con unas preciosas bandas azuladas, jajajaja.


Si revelo con PS obtengo una imagen de 3888x2592 , o sea que ya está con el "crop" hecho, jejje, o con el clip

Bueno, ahora me pasaré por el hilo de mejoras para escribir mi carta de los reyes magos, jejeje.

Gracias y un saludo.

Cita:
Otra cosa, podríais abrir algun hilo para que los novatos trabajemos con raws y aprendamos como sacar partido a ellos con PR.
La prueba que hice para enfoque iría por ejemplo en ese hilo, en este hilo quizá no tenga sentido.

Un saludo.
Voto por ese hilo, así podremos empezar a saber manejar PerfectRaw y aprender un poco de que leches hablan estos monstruos de programadores
__________________
Galerías en:
http://hgonzag.deviantart.com
http://hgonzag.imagekind.com/
  #136 (permalink)  
Antiguo 25-ene-2009, 11:44
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Cita:
Iniciado por cLIP Ver Mensaje
Si revelo por defecto obtengo una imagen de 3908x2602 con unas preciosas bandas azuladas, jajajaja.
¿Y eso te pasa en todos tus RAWs? Es de lo más curioso. En ese recorte se "manchan" de azul tres píxels, cuatro por si acaso. Si quitas cuatro de arriba y de abajo obtienes precisamente el alto que PS te da para la imagen.

Un duda que tengo es la siguiente: los programas como PTLens ¿trabajan igual de bien sobre una imagen recortada? Obviamente no, entonces, ¿qué tamaño esperan que tenga la imagen, la de PS o la de dcraw? Supongo que la de PS que es la misma que la de los JPEGs que entrega cada cámara. Creo que es algo que habrá que tener en cuenta, pero es una pena desperdiciar esos píxeles extra porque, precisamente, uno de los usos más interesantes de esos píxeles extras (desde mi punto de vista) es que al usar PTLens tienes más margen para evitar recortar algo que estaba muy cerca de los bordes.

La única solución 100% efectiva sería pedir al autor de PTLens, Tom Niemann, que calibre de nuevo las cámaras y lentes para el nuevo tamaño de imagen, pero claro, eso es mucho trabajo para él. Aunque tal vez pueda "ajustar" la calibración teniendo en cuenta el nuevo tamaño de la imagen. Me he puesto en contacto con él, a ver qué dice (cuando he tenido una lente que su programa no soportaba correctamente me ha contestado en unas pocas horas y me ha pasado una versión corregida casi inmediatamente. No puedo por tanto dejar de recomendaros que echéis un vistazo a este estupendo programa si aún no lo conocéis).

Esto dice el manual de PTLens:

"It is especially important not to crop an image prior to correcting rectilinear distortion. The field of view of your image must match the field of view used for calibration. Cropping an image reduces the field of view and results will not be accurate. The same holds true if you enlarge the canvas in Photoshop prior to invoking PTLens as this effectively increases the field of view."

Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Última edición por ManuelLlorens; 25-ene-2009 a las 12:24.
  #137 (permalink)  
Antiguo 25-ene-2009, 15:51
Habitual
 
Fecha de Ingreso: febrero-2007
Ubicación: Barcelona
Mensajes: 271
Cita:
¿Y eso te pasa en todos tus RAWs? Es de lo más curioso. En ese recorte se "manchan" de azul tres píxels, cuatro por si acaso. Si quitas cuatro de arriba y de abajo obtienes precisamente el alto que PS te da para la imagen.
Pues sí pensaba que era algo común...
__________________
Galerías en:
http://hgonzag.deviantart.com
http://hgonzag.imagekind.com/
  #138 (permalink)  
Antiguo 25-ene-2009, 23:54
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Esto es lo que me contesta Tom Niemann (ya os dije que era diligente en sus respuestas):

"A difference in 20 pixels, in an image that is 2000 pixels wide, is only one percent. Even less on larger images. The resulting difference won't be noticeable".

Vamos que mi preocupación era en vano.

Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos
  #139 (permalink)  
Antiguo 26-ene-2009, 00:12
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Cita:
Iniciado por cLIP Ver Mensaje
Pues sí pensaba que era algo común...
Tampoco tiene mayor importancia, ¿no? Prueba a calentar un poco la cámara a base de tirar muchas fotos y cuando notes la batería calentita dispara varias con la ISO más alta y con una exposición muy larga (de noche claro). Así verás si el azul (que probablemente es un cable demasiado cerca del sensor) se extiende más allá de los píxeles que ves ahora.

Si es así, tal vez sí puedas reclamar si está en garantía. Si no, no vuelvas a preocuparte porque es normal y por quitar 3 píxeles no pierdes nada.

Lo más raro es que salga azul... si es ruido térmico debería salir rojo . En este artículo hablan de algo parecido en las E-300 (como la mía) y en varios sitios se afirma que es algo normal en todas las cámaras.

Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Última edición por ManuelLlorens; 26-ene-2009 a las 00:15.
  #140 (permalink)  
Antiguo 26-ene-2009, 08:57
Habitual
 
Fecha de Ingreso: febrero-2007
Ubicación: Barcelona
Mensajes: 271
Preocuparme no me preocupa porque revelando con CameRAW nunca había visto esto, así que será normal.

Muchas gracias y un saludo.
__________________
Galerías en:
http://hgonzag.deviantart.com
http://hgonzag.imagekind.com/
  #141 (permalink)  
Antiguo 26-ene-2009, 17:09
Habitual
 
Fecha de Ingreso: abril-2008
Ubicación: Coruña
Mensajes: 280
Cita:
Iniciado por ManuelLlorens Ver Mensaje
Vale, ya lo he podido probar, aquí tienes el código corregido:
Gracias otra vez, Manuel. Lo he probado con un print a la consola y funciona a la perfección. Para lo de multibyte creo que voy a tener que cambiar de compilador (hasta ahora funcionaba con DevC++). A ver si me pongo estos días con ello.

Un saludo.

PD: He probado la última versión que has subido con las primeras mejoras en la gestión de la memoria y la diferencia me pareció muy notable. Muchas gracias por el curro.
  #142 (permalink)  
Antiguo 27-ene-2009, 01:06
Lleva poco por aquí
 
Fecha de Ingreso: septiembre-2007
Ubicación: Costa Rica
Mensajes: 23
Hola Manuel, he notado que sin marcar la opcion snapshot, esta funciona de todas maneras, como si fuera automatica, se coloca el cursor sobre la foto, y se mantiene presionada la barra espaciadora un momento y despues funciona, muestra el revelado anterior. Lo hago notar por cualquier cosa, saludos
  #143 (permalink)  
Antiguo 27-ene-2009, 10:17
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Cita:
Iniciado por Sipa Ver Mensaje
Hola Manuel, he notado que sin marcar la opcion snapshot, esta funciona de todas maneras, como si fuera automatica, se coloca el cursor sobre la foto, y se mantiene presionada la barra espaciadora un momento y despues funciona, muestra el revelado anterior. Lo hago notar por cualquier cosa, saludos
En realidad ese es precisamente el funcionamiento del tema. Si no está marcado snapshot cada nuevo revelado muestra el anterior al mantener la barra espaciadora pulsada. Si se marca snapshot entonces el revelado actual (sobre el que se marca) se usará permanentemente como comparación al pulsar la barra espaciadora en lugar de hacerlo con el revelado inmediatamente anterior.

Supongo que es un poco confuso todo el tema, pero es una medida provisional para entender mejor lo que hace cada parámetro del revelado, el interfaz definitivo lo implementará de modo diferente.

Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos
  #144 (permalink)  
Antiguo 27-ene-2009, 10:55
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Cita:
Iniciado por Lassus Ver Mensaje
Gracias otra vez, Manuel. Lo he probado con un print a la consola y funciona a la perfección. Para lo de multibyte creo que voy a tener que cambiar de compilador (hasta ahora funcionaba con DevC++). A ver si me pongo estos días con ello.
Pues sí, pásate a VC++ que tiene un entorno mucho más cómodo (a mí Dev-C++ se realentizaba de vez en cuando). Aunque seguro que puedes hacer lo mismo con Dev-C++.

Cita:
Iniciado por Lassus Ver Mensaje
PD: He probado la última versión que has subido con las primeras mejoras en la gestión de la memoria y la diferencia me pareció muy notable. Muchas gracias por el curro.
Pues ya verás cuando suba la siguiente. Es algo más rápida (aunque ya no sé hasta qué punto son percepciones mías, bueno el primer revelado sí es objetivamente más rápido y eso es como entrar en una casa con un hall grande, luego parece toda más grande) y consume mucha menos memoria. Además mola cómo se adapta ella solita a la máquina y a la imagen. Aunque externamente no ha cambiado nada.

Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos
  #145 (permalink)  
Antiguo 27-ene-2009, 11:01
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Cita:
Iniciado por Lassus Ver Mensaje
Un saludo.
Oye, Lassus, ¿cómo andas de tiempo? ¿Te animas a intentar "arreglar" AFD en los píxeles difíciles. Sería procesar la imagen con AFD, luego detectar los píxeles más difíciles con mi algoritmo y finalmente aplicar una media simple en esos píxeles. Tienen que ser pocos, para eso a mi algoritmo se le pone un umbral exigente. El resultado sería un AFD sin píxeles feos. La otra alternativa es AHD en los ejes, AFD en las texturas y una media en los píxeles feos.

Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos
  #146 (permalink)  
Antiguo 29-ene-2009, 11:46
Habitual
 
Fecha de Ingreso: abril-2008
Ubicación: Coruña
Mensajes: 280
Cita:
Iniciado por ManuelLlorens Ver Mensaje
Oye, Lassus, ¿cómo andas de tiempo? ¿Te animas a intentar "arreglar" AFD en los píxeles difíciles. Sería procesar la imagen con AFD, luego detectar los píxeles más difíciles con mi algoritmo y finalmente aplicar una media simple en esos píxeles. Tienen que ser pocos, para eso a mi algoritmo se le pone un umbral exigente. El resultado sería un AFD sin píxeles feos. La otra alternativa es AHD en los ejes, AFD en las texturas y una media en los píxeles feos.
Manuel, yo lo intento, aunque en este momento no sabría ni por dónde empezar. Miraré el código de AFD con calma y si veo que me entero de algo me pongo manos a la obra. Perdona que no haya respondido antes, últimamente me conecto poco.

Ayer en un momento de inspiración por la noche hice un algoritmo basado en "pixel grouping" ponderando la dirección de interpolación en función de los gradientes (lo he llamado WPG) y que juraría que mejora a AFD. Además es aceptablemente rápido (al estilo de los últimos VCD), es muy cortito y sencillo y apenas consume memoria. Déjame trastear un poco más con ello (estoy buscando una fórmula óptima para enfocar a tope sin que se disparen los "píxeles alegres") y mañana pongo algún resultado.

La gestión de memoria se nota muchísimo en equipos con poca RAM. Gracias por el curro.
  #147 (permalink)  
Antiguo 29-ene-2009, 17:20
Avatar de Nino
Habitual
 
Fecha de Ingreso: enero-2005
Ubicación: Ávila
Mensajes: 268
Hola de nuevo.
Después de trastear un poco con la última versión, 0.65 SSE(3), me he dado cuenta que al interpolar con el algoritmo AFD aparece en los límites de la imagen (exactamente a 9 píxeles de éste por cada lado, en los raw de mi eos 5D) un incremento drástico en la luminosidad, que tiene como efecto la aparición de un "marco" de 9 píxeles.
Este fenómeno no se da al interpolar con los otros algoritmos.
No creo que tenga demasiada importancia, pero me ha parecido curioso.
Un saludo.
  #148 (permalink)  
Antiguo 29-ene-2009, 17:21
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Ya casi tengo casi lista la próxima versión 0.65 con la gestión de memoria nueva. He arreglado un bug en el soporte de la Pentax K100D y he incorporado la última versión del código de Coffin.

Sólo me queda arreglar el uso de memoria al grabar el TIFF, lo demás ya funciona bien. Cuando lo tenga lo subiré todo.

Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos

Última edición por ManuelLlorens; 29-ene-2009 a las 17:44.
  #149 (permalink)  
Antiguo 29-ene-2009, 17:22
Avatar de ManuelLlorens
Hágase la luz
 
Fecha de Ingreso: abril-2008
Ubicación: Madrid
Mensajes: 873
Enviar un mensaje por MSN a ManuelLlorens
Cita:
Iniciado por Nino Ver Mensaje
Hola de nuevo.
Después de trastear un poco con la última versión, 0.65 SSE(3), me he dado cuenta que al interpolar con el algoritmo AFD aparece en los límites de la imagen (exactamente a 9 píxeles de éste por cada lado, en los raw de mi eos 5D) un incremento drástico en la luminosidad, que tiene como efecto la aparición de un "marco" de 9 píxeles.
Este fenómeno no se da al interpolar con los otros algoritmos.
No creo que tenga demasiada importancia, pero me ha parecido curioso.
Un saludo.
Creo que estará arreglado en la próxima versión que suba, ya me contarás.

Un saludo:
__________________
Manuel Llorens

Olympus E-510, E-300
Mis fotos
  #150 (permalink)  
Antiguo 30-ene-2009, 00:49
Habitual
 
Fecha de Ingreso: diciembre-2006
Ubicación: Madriz y Cantabria
Mensajes: 201
Cita:
Iniciado por ManuelLlorens Ver Mensaje
Bueno pues ahí va eso:

Instalación:
  • Descomprimir el contenido del .ZIP en una carpeta. Instalar la fuente .TTF en el directorio de fuentes de Windows. Ejecutar el .EXE.
Configuración:


...




Manuel, he estado missing unos días. Gracias por este pequeño manual y por tu esfuerzo y dedicación.

Un cordial saludo.
Tema Cerrado

Marcadores

Herramientas
Desplegado

Normas de Publicación
No puedes crear nuevos temas
No puedes responder mensajes
No puedes subir archivos adjuntos
No puedes editar tus mensajes

Los Códigos BB están Activado
Las Caritas están Activado
[IMG] está Activado
El Código HTML está Desactivado
Trackbacks are Activado
Pingbacks are Activado
Refbacks are Activado

Ir al Foro