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 |
![]() |
|
|||
|
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 |
|
||||
|
Cita:
Un saludo: |
|
||||
|
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 |
|
||||
|
Cita:
Un saludo: |
|
||||
|
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
), aunque el problema es el que ya dije, de eso estoy seguro.Un saludo: |
|
|||
|
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. |
|
||||
|
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 |
|
||||
|
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:
Última edición por ManuelLlorens; 22-ene-2009 a las 09:44. |
|
|||
|
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
|
|
||||
|
Cita:
¿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: |
|
||||
|
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: |
|
|||
|
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. |
|
||||
|
Flipo con vosotros...
Como os lo currais... |
|
||||
|
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 |
|
||||
|
Bueno pues ahí va eso:
Instalación:
Última edición por ManuelLlorens; 23-ene-2009 a las 11:55. |
|
||||
|
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 |
|
||||
|
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 |
|
||||
|
Cita:
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. |
|
|||
|
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. |
|
||||
|
Lo he pasado al otro hilo.
Última edición por NaVaS; 25-ene-2009 a las 10:35. |
|
||||
|
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:
Un saludo: Última edición por ManuelLlorens; 25-ene-2009 a las 01:37. |
|
||||
|
Cita:
Gracias. Un saludo: Última edición por ManuelLlorens; 23-ene-2009 a las 18:01. |
|
|||
|
Cita:
![]() Última edición por Sipa; 23-ene-2009 a las 23:21. |
|
||||
|
Cita:
[...] 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: Última edición por ManuelLlorens; 24-ene-2009 a las 11:28. |
|
|||
|
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
|
|
||||
|
Cita:
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: Última edición por ManuelLlorens; 25-ene-2009 a las 01:35. |
|
|||
|
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. |
|
||||
|
Cita:
.Cita:
Cita:
. 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: Última edición por ManuelLlorens; 25-ene-2009 a las 01:35. |
|
||||
|
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:
Y estos son los resultados de la función que lee el buffer píxel a píxel:
Si intercalamos una escritura en medio (con lo que deshabilitamos la caché) el resultado cambia mucho (y es más representativo):
________________________________________ Pues sí, lo cierto es que ahora va más rápido, ¡qué cosas! Entonces el resultado definitivo es:
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
Un saludo: Última edición por ManuelLlorens; 30-ene-2009 a las 01:41. |
|
||||
|
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. |
|
||||
|
Cita:
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: |
|
|||
|
Cita:
![]() 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:
![]()
__________________
Galerías en: http://hgonzag.deviantart.com http://hgonzag.imagekind.com/ |
|
||||
|
Cita:
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: Última edición por ManuelLlorens; 25-ene-2009 a las 12:24. |
|
|||
|
Cita:
pensaba que era algo común...
__________________
Galerías en: http://hgonzag.deviantart.com http://hgonzag.imagekind.com/ |
|
||||
|
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: |
|
||||
|
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: Última edición por ManuelLlorens; 26-ene-2009 a las 00:15. |
|
|||
|
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/ |
|
|||
|
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. |
|
|||
|
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
|
|
||||
|
Cita:
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: |
|
||||
|
Cita:
Cita:
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: |
|
|||
|
Cita:
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. ![]() |
|
||||
|
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. |
|
||||
|
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: Última edición por ManuelLlorens; 29-ene-2009 a las 17:44. |
|
||||
|
Cita:
Un saludo: |
|
|||
|
Cita:
Manuel, he estado missing unos días. Gracias por este pequeño manual y por tu esfuerzo y dedicación. Un cordial saludo. |
![]() |
| Marcadores |
| Herramientas | |
| Desplegado | |
|
|