PDA

Ver la versión completa : Compilar para Linux



tonilupi
29/05/2008, 18:18
Hola, en qué estado se encuentran las fuentes y/o el uso de librerías para intentar compilar alguna de las versiones existentes bajo linux?

Saludos

ManuelLlorens
29/05/2008, 19:19
Pues es una buena pregunta. Voy a intentar contestarte.

En principio TODO el código que hemos desarrollado es multiplataforma.
Como entornos de desarrollo hemos utilizado exclusivamente DEV-C++ que compila con MinGW (es decir, gcc) y Visual Studio .NET 2005.
Como lenguajes de programación C y C#.
Módulos:
dcraw.dll: debería compilar tal cual está en Linux con gcc, para generar una librería dinámica .so.
colormng.dll (incluye LCMS): con un sólo cambio en el include lcms.h debería compilar en Linux, esto aún no está subido al SVN de Google Code.
perfectImage.dll: debería compilar tal cual en linux.
Código C#: debería compilar en Mono con pequeños cambios. Habrá que cambiar las referencias a las DLLs por referencias a los SOs. Hay una llamada al API de Windows en el revelador para obtener la memoria RAM libre, habrá que sustituirlo por un Performance Counter o una llamada al API similar de Unix (si existe algo así, desconozco completamente la programación en Unix).Las instrucciones para ir compilando cada uno de los módulos son otro asunto. Si te pones a ello ve preguntando.

Puedes acceder al código fuente instrucciones aquí http://code.google.com/p/perfectraw/source/checkout

Un saludo y suerte si te pones a ello:

PerroVerd
29/05/2008, 19:58
Todos los ejecutables que no requieren librerías funcionan directamente si tienes instalado mono y unas cuantas dependencias (winforms y alguna otra, ya te lo miraré)

Las librerías son otra historia, hay que compilarlas nativamente y de momento sigo peleado con el mono-gmcs

tonilupi
29/05/2008, 23:24
PerroVerd, de momento llevo unos días intentando que corriera perfectRAW sobre wine pero no hay forma, me da errores de asignación de memoria y además me pide que instale las librerías para windows de mono y ya le he instalado la v7 y la v8.


Si así funcionara pues estaría solucionado de momento, pero como no es así me decidí a abrí
ir este post.

Saludos

tonilupi
10/06/2008, 00:34
PerroVerd, ¿cómo tienes el tema?

Yo, después de pelearme unos días con el mono-develop parece que lo tengo funcionando (el mono, no el dcraw :)), ahora estoy en la tarea de generar esa librería dinámica.

Necesito ayuda para esto para hacerlo con el mono.

Saludos

ManuelLlorens
10/06/2008, 14:56
PerroVerd, ¿cómo tienes el tema?

Yo, después de pelearme unos días con el mono-develop parece que lo tengo funcionando (el mono, no el dcraw :)), ahora estoy en la tarea de generar esa librería dinámica.

Necesito ayuda para esto para hacerlo con el mono.

Saludos
La librería dinámica tienes que generarla con el compilador de C, gcc. Mono es para la parte interfaz, en C#. Tendrás que modificar código seguro para que la parte C# coja la librería dinámica (.so) porque ahora busca una DLL (.dll). ¡Ánimo!

Tengo instalado un Ubuntu, algún día me pondré a probar gcc+Mono, pero de momento yo no puedo ayudarte más.

Un saludo:

tonilupi
11/07/2008, 19:48
Bueno, dcraw ha compilado sin problemas y ya tengo la librería dcraw.so, ahora estoy intentando compilar perfectRAW con mono.

De momento estoy parado con el WindowsApplication4 , en los repositorios de los fuentes no encuentro ninguna archivo con ese nombre.

Por lo que he podido encontrar ese parece un nombre por defecto que VB "noseque versión" le pone a sus proyectos, además por hacer referencia a los botones parece un form.

Venga, decid algo que estoy parao :Palomitas::Palomitas::Palomitas:

Saludos

ManuelLlorens
12/07/2008, 01:58
Bueno, dcraw ha compilado sin problemas y ya tengo la librería dcraw.so, ahora estoy intentando compilar perfectRAW con mono.
¡Guau! :drool2:


De momento estoy parado con el WindowsApplication4 , en los repositorios de los fuentes no encuentro ninguna archivo con ese nombre.
Sí, es que los controles los estaba desarrollando en un proyecto a parte que no he subido... pasa de los controles personalizados de momento, cambia los WindowsApplication4.pButton por Button a secas, sólo tienes que reemplazarlos dentro del método de inicialización del formulario. De momento con eso te vale. Ejemplo:


private void InitializeComponent()
{
this.openFileDialog1 = new System.Windows.Forms.OpenFileDialog();
this.label3 = new System.Windows.Forms.Label();
this.button3 = new WindowsApplication4.pButton(); // Cambiar por new Button();
this.groupBox2 = new System.Windows.Forms.GroupBox();
this.FreeMem = new System.Windows.Forms.Label();
this.button1 = new WindowsApplication4.pButton();
this.pictureBox1 = new System.Windows.Forms.PictureBox();
this.label2 = new System.Windows.Forms.Label();
this.numericUpDown3 = new System.Windows.Forms.NumericUpDown();
this.label7 = new System.Windows.Forms.Label();
this.label1 = new System.Windows.Forms.Label();
this.label8 = new System.Windows.Forms.Label();
this.numericUpDown4 = new System.Windows.Forms.NumericUpDown();
this.label10 = new System.Windows.Forms.Label();
this.label9 = new System.Windows.Forms.Label();
this.numericUpDown5 = new System.Windows.Forms.NumericUpDown();
this.trackBar1 = new System.Windows.Forms.TrackBar();
this.numericUpDown2 = new System.Windows.Forms.NumericUpDown();
this.label4 = new System.Windows.Forms.Label();
this.numericUpDown1 = new System.Windows.Forms.NumericUpDown();
this.label5 = new System.Windows.Forms.Label();
this.trackBar2 = new System.Windows.Forms.TrackBar();
this.groupBox1 = new System.Windows.Forms.GroupBox();
this.textBox1 = new System.Windows.Forms.TextBox();
this.pButton1 = new WindowsApplication4.pButton();
this.label6 = new System.Windows.Forms.Label();
this.label11 = new System.Windows.Forms.Label();
this.thresholdControl = new System.Windows.Forms.NumericUpDown();
this.medianControl = new System.Windows.Forms.NumericUpDown();
this.label12 = new System.Windows.Forms.Label();
this.label13 = new System.Windows.Forms.Label();
this.listBox1 = new System.Windows.Forms.ListBox();
this.label14 = new System.Windows.Forms.Label();
this.listBox2 = new System.Windows.Forms.ListBox();
this.numericUpDown6 = new System.Windows.Forms.NumericUpDown();
this.numericUpDown7 = new System.Windows.Forms.NumericUpDown();
this.numericUpDown8 = new System.Windows.Forms.NumericUpDown();
this.numericUpDown9 = new System.Windows.Forms.NumericUpDown();
this.label15 = new System.Windows.Forms.Label();
this.label16 = new System.Windows.Forms.Label();
this.label17 = new System.Windows.Forms.Label();
this.label18 = new System.Windows.Forms.Label();
this.label20 = new System.Windows.Forms.Label();
this.listBox3 = new System.Windows.Forms.ListBox();
this.levelEdgeStr = new System.Windows.Forms.Label();
this.levelCellSld = new System.Windows.Forms.TrackBar();
this.levelCellNum = new System.Windows.Forms.NumericUpDown();
this.pButton2 = new WindowsApplication4.pButton();
this.pButton3 = new WindowsApplication4.pButton();
this.pButton4 = new WindowsApplication4.pButton();
this.groupBox2.SuspendLayout();
((System.ComponentModel.ISupportInitialize)(this.p ictureBox1)).BeginInit();
((System.ComponentModel.ISupportInitialize)(this.n umericUpDown3)).BeginInit();
((System.ComponentModel.ISupportInitialize)(this.n umericUpDown4)).BeginInit();
((System.ComponentModel.ISupportInitialize)(this.n umericUpDown5)).BeginInit();
((System.ComponentModel.ISupportInitialize)(this.t rackBar1)).BeginInit();
((System.ComponentModel.ISupportInitialize)(this.n umericUpDown2)).BeginInit();
((System.ComponentModel.ISupportInitialize)(this.n umericUpDown1)).BeginInit();
((System.ComponentModel.ISupportInitialize)(this.t rackBar2)).BeginInit();
this.groupBox1.SuspendLayout();
((System.ComponentModel.ISupportInitialize)(this.t hresholdControl)).BeginInit();
((System.ComponentModel.ISupportInitialize)(this.m edianControl)).BeginInit();
((System.ComponentModel.ISupportInitialize)(this.n umericUpDown6)).BeginInit();
((System.ComponentModel.ISupportInitialize)(this.n umericUpDown7)).BeginInit();
((System.ComponentModel.ISupportInitialize)(this.n umericUpDown8)).BeginInit();
((System.ComponentModel.ISupportInitialize)(this.n umericUpDown9)).BeginInit();
((System.ComponentModel.ISupportInitialize)(this.l evelCellSld)).BeginInit();
((System.ComponentModel.ISupportInitialize)(this.l evelCellNum)).BeginInit();
this.SuspendLayout();
[...]


Otra cosa que tendrás que cambiar en el código es esto:


// Código no portable a otras plataformas
[DllImport("kernel32")]
static extern void GlobalMemoryStatus(ref MEMORYSTATUS buf);

dado que, obviamente, no tienes un kernel32.dll. Quítalo y quita también esto el cálculo de la memoria libre, comenta todas las líneas del método CheckMem(), ya lo arreglaremos luego.


Venga, decid algo que estoy parao :Palomitas::Palomitas::Palomitas:
Me vas a hacer la puñeta con ésto :D:D:D, yo pensaba pasar de conectarme en vacaciones, pero tendré que pedirle a alguien que me mantenga informado de tus progresos... ¡que suspense! Si conseguimos compilarlo para Linux lo siguiente es MacOS, tiene que ser muy parecido porque tiene gcc y Mono.

Un saludo:

tonilupi
13/07/2008, 05:32
Bueno, esto, ejem..., donde dije digo digo diego.

El hecho es que me lie y lo que compilé sin problemas fue el dcraw de Coffin :o

El otro hecho es que hoy me he puesto con el DCRAW modificado y me da un error,

En la función DCRAW_Process el gcc me devuelve un error de incompatibilidad de tipos entre dos punteros, concretamente donde se iguala image=img

image se define al principio del archivo como variable global siendo un puntero a un array de 4 unsigned shorts y en el módulo DCRAW_Processss no se redefine mientras que img se define como variable local en esa función siendo un puntero a un unsigned short.

No me cuadra esa asignación y no entiendo cómo habéis podido compilarlo tal cual.:Palomitas::Palomitas::Palomitas:

Saludos

ManuelLlorens
14/07/2008, 11:57
Bueno, esto, ejem..., donde dije digo digo diego.

El hecho es que me lie y lo que compilé sin problemas fue el dcraw de Coffin :o

Bueno, no deja de ser un avance ;).


En la función DCRAW_Process el gcc me devuelve un error de incompatibilidad de tipos entre dos punteros, concretamente donde se iguala image=img

image se define al principio del archivo como variable global siendo un puntero a un array de 4 unsigned shorts y en el módulo DCRAW_Processss no se redefine mientras que img se define como variable local en esa función siendo un puntero a un unsigned short.
Ten en cuenta ambas variables son punteros por lo que lo único que guardan es una dirección de memoria no un dato. El modo de declarar la variable importa a la hora de hacer aritmética con ese puntero pero si te fijas después de esa línea no se hace ninguna operación con esos punteros por lo que la asignación es perfectamente válida. De hecho me extraña que gcc de un error y no una advertencia, que es lo que debería dar.

Solucionarlo es fácil, basta con hacer un cast entre los dos tipos de punteros:
Cambia ésto:


image=img;


Por ésto:


image=(ushort (*)[4]) img;


Y compilará sin problemas. Aunque aún habrá más cosas que tocar, supongo.

Un saludo:

tonilupi
14/07/2008, 20:29
Oño, Manuel, el cast era lo que buscaba, recordaba una manera de forzar un desacuerdo de tipos como este pero como me centré en repasar todo lo competente a punteros pasé por alto esto. Es que estoy un poco oxidado :si:

Esta noche lo probaré.

Sobre lo de cambiar otras cosas ya lo he tenido que hacer, pero bueno, cuando lo termine (si lo llego a terminar :icon_smash:) ya lo publicaré.

Salut

tonilupi
18/07/2008, 12:28
Manuel, ya he conseguido generar la libería dinámica libdcraw.so y linkarla con el un ejecutable "test" de mi creación.

A tu código de dcraw le he añadido una función mía para probar, simplemente me devuelve la suma de dos enteros.

Generando la librería .so y linkándola con mi test.c consigo que me devuelva el valor de la suma.

Esto pinta bien.

Ahora a por tu test.c, luego a por perfectRAW.

Salut
_________________________________
Creo que ya tengo funcionando el programita test.c de Manuel enlazado con la librería dinámica dcraw modificado.

Os pongo el resultado del archivo raw 1.cr2 del repositorio svn


Saved state 1
Resultado de leer el RAW: 0
Model: EOS 30D
0.500000
Restored state 1
Scaling with darkness 128, saturation 4095, and
multipliers 1.900861 1.000000 1.429502 1.002098
Saved state 2
Bilinear interpolation...
Saved state 3
Saved state 4
Exposure correction without highlight preservation
Converting to sRGB colorspace using sRGB gamma ...
Saved state 5


Os lo debeis estar pasando de vicio estando de vacaciones, porque lo que es dar señales de vida...;)

Saludos

Tur
26/10/2008, 23:31
Hola a todos,

Llevo un tiempo siguiendo el proyecto desde la distancia, y bueno, he visto que andais tratando de compilar esto en linux, no sé si al final lo habeis conseguido o no.

Yo por mi parte, he estado trasteando con el código que hay en el SVN de google, y con las indicaciones de este hilo y alguna cosa más he sacado esto:

http://img225.imageshack.us/img225/4629/snapshot4es7.th.png (http://img225.imageshack.us/my.php?image=snapshot4es7.png)http://img225.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)
http://img139.imageshack.us/images/thpix.gif (http://g.imageshack.us/thpix.php)

Parece que funciona ;)

De todas formas no sé cual es el estado actual del proyecto. Por lo que he leido, para la versión 1.0 vais a incorporar openGL entre otras cosas, y creo (igual me equivoco) que en el svn no esta subido lo último que estais desarrollando.

En fin, ya me direis algo y si hace falta os cuento los detalles para la adaptación. De hecho me encontrado con un problema un poco "oscuro" que impedia que funcionase correctamente, aunque la solución es aparentemente facil.

Un saludo.

ManuelLlorens
26/10/2008, 23:46
Esto es absolutamente fantástico... ¿qué tal va de velocidad? Comenta, comenta los problemas que has encontrado.

Efectivamente, el código actual no es el último, estamos remodelando varias cosas.

Un saludo:

Tur
27/10/2008, 00:46
Pues de velocidad... con el raw de ejemplo (1.cr2) tarda unos 15-20 segundos en un AMD64 3000 / 1 GB de ram.

No sé si es mucho o poco la verdad, ahora mismo solo tengo windows en una máquina virtual y no puedo comparar.

Mañana cuando tenga un rato os cuento más cosas :)

Saludos.

ariznaf
27/10/2008, 01:42
Bien por tí, TUR. :xmas: :xmas:

Ahora el código está un poco partido en tres cachos, pruebas de opengl, lo del revelador y cambios en la interface.

Nosotros mismos tendremos que juntarlo. Cuando se junte y haya una versión funcional será estupendo si lo puedes pasar a linux.

En principio no debería ser complicado, salvo algunos detalles con los que ya te has peleado, porque las librerías están en C, la interface en .NET (eso correrá con mono) y luego está la parte de opengl que está hecha utilizando Tao y que sí que requerirá algún ajuste, porque Tao parece que usa controles diferentes en windows y en linux.

Tur
27/10/2008, 13:15
Nosotros mismos tendremos que juntarlo. Cuando se junte y haya una versión funcional será estupendo si lo puedes pasar a linux.


Eso mismo, de momento para la versión 0.5 no sé si vale la pena dejar paquetes preparados para linux, si eso cuando tengais la 1.0 mas o menos linsta, sí estaria bien hacer por ejemplo un paquete de fuentes incluyendo los makefiles necesarios para compilar, e incluso algun paquete binario precompilado.

Lo que os vaya contando podeis (si quereis, claro) ir incorporandolo para la siguiente versión.
_________________________________



Voy a empezar por la parte "oscura", la verdad es que esto me costo un buen rato darme cuenta. Y es que despues de que todo compilara correctamente, el programa hacia unos revelados un poco extraños, todo negro o con colores aleatorios :D:D

El problema esta en las estructuras que se comparten entre la libreria de dcraw y el codigo en C#. En principio parece que usar un struct como interfaz de una dll es un poco peligroso, pero bueno, tiene solución.

Resulta que gcc por defecto empaqueta las estructuras de diferente manera que mingw/.net/mono. Es decir, gcc pone los campos unos detras de otro sin huecos entre medio y los otros tres compiladores por defecto tratan de alinear las variables a multiplos de su tamaño (por temas de rendimiento y esas cosas). Un poco de literatura sobre esto: aqui (http://www.tedlogan.com/techblog2.html) o aqui (http://www.delorie.com/djgpp/v2faq/faq22_11.html) .

Por tanto el struct DLL_PARAMETERS compilado en gcc tiene tamaño 120 bytes, y compilado en mono/.net/mingw el tamaño es 128 bytes. Con lo cual se descuadra el acceso a los campos.

Solución A: Ordenar los campos de los structs de forma que se evite el padding, esto sería poner los campos de tipos de dato mas largos antes que los tipos mas pequeños. En este caso sería mover dentro de DLL_PARAMETERS la variable 'double aber[4]' al principio del struct.

Solución B: Un poco más limpia, forzar el mismo empaquetado en el lado de C y de C#.

En el codigo en C (dcraw.h), la estructura DLL_PARAMETERS quedaría:


typedef struct DCRAW_Parameters
{
float threshold; // -n -> buffer 2 *
double aber[4]; // -r/-C -> buffer 2 *
int use_auto_wb; // -a -> buffer 2 *
int use_camera_wb; // -w -> buffer 2 *
unsigned greybox[4]; // -A -> buffer 2
int user_black; // -K -> buffer 2 *
int user_sat; // -S -> buffer 2 *
int test_pattern; // -> buffer 2 -
int level_greens; // -l -> buffer 2 *
float level_edge; // -> buffer 2 *
int level_cell; // -> buffer 2 *
int user_qual; // -q -> buffer 3 *
int four_color_rgb; // -f -> buffer 3 *
int med_passes; // -m -> buffer 4 *
int highlight; // -H -> buffer 4 *
int output_color; // -o -> buffer 5
int use_fuji_rotate; // -J -> buffer 5
float user_gamma; // -g -> buffer 5
float exposure; // -> buffer 4 *
float preserve; // -> buffer 4 *
} __attribute__((packed)) DLL_PARAMETERS;
Y en la parte de C# (dcraw.cs) :


[StructLayout(LayoutKind.Sequential,Pack=1)]
public struct DLL_PARAMETERS
{
public float threshold;
public fixed double aber[4];
public int use_auto_wb;
public int use_camera_wb;
public fixed uint greybox[4];
public int user_black;
public int user_sat;
public int test_pattern;
public int level_greens;
public float level_edge;
public int level_cell;
public int user_qual;
public int four_color_rgb;
public int med_passes;
public int highlight;
public int output_color;
public int use_fuji_rotate;
public float user_gamma;
public float exposure;
public float preserve;
}
Esto habría que hacerlo en todos los structs compartidos entre C y C#.


Luego sigo con los detalles para la compilación, que sino esto queda muy largo.

Venga, un saludo.

tonilupi
27/10/2008, 13:38
Hola Tur, veo que dominas bastante este tema de la programación en Linux.

Yo me perdí y lo dejé hasta ver si salía alguien con más conocimientos que yo.

Visto lo visto me gustaría que compartieras tus avances.

Veo que has usado Mono, podrías publicar el proyecto y yo intentaría compilarlo?

Salut

Tur
27/10/2008, 21:26
Hola,



Veo que has usado Mono, podrías publicar el proyecto y yo intentaría compilarlo?
Salut

Si quieres, ya subire las fuentes modificadas a algun sitio, pero vamos, es corregir cuatro cosas en el código y ya esta. De hecho el proyecto de Visual de Studio se puede abrir directamente con MonoDevelop, sin convertirlo ni nada.
_________________________________
Os pongo los detalles de la compilación de las librerias dcraw y colormng. Es bastante sencillo ;)

Libreria DCRAW:

Cambios en el código:

-> Modificar los structs IMAGE_INFO, DLL_PARAMETERS, DLL_STATE con __attribute__((packed)) tal y como se indica en el post anterior.
-> La cabecera windows.h solo habría que incluirla si se compila para windows:


#ifdef WIN32
#include <windows.h> // added by Manuel Llorens
#endif
-> Se podría hacer lo mismo con las macros DLLIMPORT y __declspec , de todas formas no es necesario ya que se pueden redefinir desde los parametros de gcc (ver makefile).

Compilación:

Este es el makefile que he usado, para probarlo se coloca en la carpeta dcraw (donde estan ahora los ficheros .dev), luego situandonos en ese directorio y ejecutando 'make' se genera dentro del directorio 'bin' la libreria libdcraw.so y el ejecutable normal.


CC=gcc
CFLAGS_DCRAW=-DNO_LCMS -DNO_JPEG
CFLAGS_OPT=-pipe -m3dnow -msse -msse2 -mmmx -mfpmath=sse -ffast-math -O2
CFLAGS_PORT="-D__declspec(x)=" -DDLLIMPORT=
CFLAGS_LIB=-fPIC -c -Wall $(CFLAGS_DCRAW) $(CFLAGS_OPT) $(CFLAGS_PORT) -DBUILDING_DLL=1
CFLAGS_EXE=-lm -Wall $(CFLAGS_DCRAW) $(CFLAGS_OPT) $(CFLAGS_PORT)
LDFLAGS_LIB=-fPIC -shared -lm

all: library executable
library: bin/libdcraw.so
executable: bin/dcraw

bin/libdcraw.so: obj/libdcraw.o
$(CC) $(LDFLAGS_LIB) -o $@ $^

obj/libdcraw.o: src/dcraw.c
$(CC) -c -o $@ $^ $(CFLAGS_LIB)

bin/dcraw: src/dcraw.c
$(CC) -o $@ $^ $(CFLAGS_EXE)

clean:
rm -rf obj/*.o bin/*.so bin/dcraw


Libreria COLORMNG:

Cambios en el código:

-> Igual que con dcraw, los include windows.h hay que rodearlos con un #ifdef WIN32
-> Lo mismo para la función DllMain, rodearla con un #ifdef WIN32
-> Y lo mismo con las definiciones de DLLIMPORT y __declspec, al igual que antes es opcional ya que se anulan despues en el makefile.

Compilación:

El makefile para colormng, este habria que colocarlo y ejecutarlo en el directorio 'src' dentro de perfectRAW. Se genera libcolormng.so


CC=gcc
CFLAGS_OPT=-pipe -m3dnow -msse -msse2 -mmmx -mfpmath=sse -ffast-math -O2
CFLAGS_PORT="-D__declspec(x)=" -DDLLIMPORT=
CFLAGS=-fPIC -c -Wall $(CFLAGS_OPT) $(CFLAGS_PORT) -DBUILDING_DLL=1
LDFLAGS=-fPIC -shared

all: libcolormng.so

libcolormng.so: cmscam02.o cmscgats.o cmserr.o cmsgmt.o cmsio0.o cmslut.o cmsmtrx.o cmspack.o cmsps2.o cmsvirt.o cmsxform.o cmscam97.o cmscnvrt.o cmsgamma.o cmsintrp.o cmsio1.o cmsmatsh.o cmsnamed.o cmspcs.o cmssamp.o cmswtpnt.o colormng.o
$(CC) $(LDFLAGS) -o $@ $^

clean:
rm -f *.so *.o
Las librerias generadas habrá que ponerlas en algun sitio que luego perfectRAW las encuentre. Por ejemplo /usr/local/lib (y ejecutar ldconfig para actualizar la cache de librerias).

Y ya esta, no es muy traumatico, ¿verdad?

PD: en el siguiente fascículo, compilación de perfectRAW con mono.

ManuelLlorens
27/10/2008, 22:30
Genial... cuando subamos el próximo código iremos metiendo cambios permanentes para que compile en linux a partir de ahora. Ya solo nos queda MacOS.

Aunque lo cierto es que la velocidad que comentas es lentísima en comparación con la velocidad en Windows (a mí con una máquina menos potente que la que dices unos 3/5 segundos)... no entiendo muy bien porqué, porque dcraw.dll debería ir igual de rápido, más o menos y es la que se lleva todo el tiempo de ejecución.

Un saludo:

Tur
27/10/2008, 23:31
Genial... cuando subamos el próximo código iremos metiendo cambios permanentes para que compile en linux a partir de ahora. Ya solo nos queda MacOS.

Aunque lo cierto es que la velocidad que comentas es lentísima en comparación con la velocidad en Windows (a mí con una máquina menos potente que la que dices unos 3/5 segundos)... no entiendo muy bien porqué, porque dcraw.dll debería ir igual de rápido, más o menos y es la que se lleva todo el tiempo de ejecución.

Un saludo:

Pues he vuelto a probar, reiniciando, parando servicios y tal, y me da que antes estaba tirando de memoria virtual o algo asi ... ahora tarda unos 9 segundos. Aun asi, hay diferencia con los 3-5 segundos que dices.

A ver si lo prueba alguien más y comparamos.

Saludos.

ManuelLlorens
28/10/2008, 08:58
Pues he vuelto a probar, reiniciando, parando servicios y tal, y me da que antes estaba tirando de memoria virtual o algo asi ... ahora tarda unos 9 segundos. Aun asi, hay diferencia con los 3-5 segundos que dices.

A ver si lo prueba alguien más y comparamos.
Bueno, eso ya es otra cosa... y depende mucho del RAW en cuestión.

Un saludo:

Tur
29/10/2008, 13:45
Bueno, alla voy con el último tocho:

PerfectRAW (usando Mono)

Cambios en el código:

-> Modificar los structs compartidos con la libreria de dcraw, tal y como se indica en el primer post (por el tema del padding y tal).

-> Referencias a las librerias. Esto es fácil, basta con hacer los imports de esta forma (sin la extensión .dll):


DllImport(@"dcraw")]
...
DllImport(@"colormng")]El runtime por si solo, tratará de buscar un fichero llamado 'dcraw.dll' en windows y 'libdcraw.so' en linux.

-> En dcraw.cs cuando se carga la configuración de config.xml, debería evitarse hardcodear la barra de separación de directorios "\", en lugar de eso concatenar la propiedad System.IO.Path.DirectorySeparatorChar, de forma que en windows será "\" y en unix "/" .
-> El tema de la llamada a kernel32 para consultar la memoria libre, ya probaré a ver si funciona bien lo del performance counter que esta entre comentarios. De momento para que compile con quitar ese trozo de código es suficiente.
-> Los controles esos de WindowsApplication4 , como creo que no estan en ninguna parte, se sutituyen por button y ya esta (tal y como indica manuel al principio del hilo).
-> Por ultimo, esta lo del WeifenLuo.WinFormsUI.Docking ... esto no se muy bien qué es, pero he encontrado una versión de la libreria que compila en linux, no se si es muy oficial, y tampoco se si es realmente portable... pero bueno, se puede bajar desde aqui (http://www.mail-archive.com/mono-winforms-list@lists.ximian.com/msg01084.html), se compila y se añade la referencia al proyecto.


Compilación:

-> El proyecto de visual studio se puede abrir directamente con MonoDevelop y compilar. Tambien hay otra opción que no he probado y es usar prj2make-sharp para generar los makefiles... en principio no hace falta, como digo con MonoDevelop se puede abrir y compilar sin problema.
-> La versión de mono debe ser superior a la 1.2.6 , al menos para compilar, ya que hay un bug con los arrays declarados como 'fixed' que hace fallar la compilación.
-> Antes de ejcutarlo, poner el fichero config.xml en el mismo directorio del ejecutable y editarlo para que las rutas a los ficheros .icm sean las correctas.

Creo que no me he dejado nada...


En fin, espero que todo esto os sirva para ir adaptando el proyecto y que sea realmente multiplataforma.

Por mi parte, si necesitais una mano en alguna otra parte del desarrollo, podeis contar conmigo, quiza podría colaborar en algo... lo que me permita el tiempo libre (como os pasa a todos, supongo).

Un saludo.

ManuelLlorens
08/11/2008, 01:18
Disculpa que he dejado este tema aparcado un tiempo, aunque me parece realmente interesante, he estado concentrado terminando AFD para sacar la versión 0.6.


Bueno, alla voy con el último tocho:
-> Los controles esos de WindowsApplication4 , como creo que no estan en ninguna parte, se sutituyen por button y ya esta (tal y como indica manuel al principio del hilo).

Sí, además los hemos quitado de la versión 0.6.


-> Por ultimo, esta lo del WeifenLuo.WinFormsUI.Docking ... esto no se muy bien qué es, pero he encontrado una versión de la libreria que compila en linux, no se si es muy oficial, y tampoco se si es realmente portable... pero bueno, se puede bajar desde aqui (http://www.mail-archive.com/mono-winforms-list@lists.ximian.com/msg01084.html), se compila y se añade la referencia al proyecto.
Es el contenedor para los controles desacoplables. Ahora no se está usando, pero el formulario principal se hereda de un contenedor de esos para el futuro.


Por mi parte, si necesitais una mano en alguna otra parte del desarrollo, podeis contar conmigo, quiza podría colaborar en algo... lo que me permita el tiempo libre (como os pasa a todos, supongo).
Yo creo que tu contribución está clara... ¿no tendrás experiencia programando en MacOS, verdad?

Un saludo:

ManuelLlorens
15/01/2009, 12:53
Dado el próximo cambio de tecnología de .NET a wxWidgets y que nosotros mismos iremos compilando para Windows, Linux y probablemente MacOS, cierro este hilo. Más que nada por ir haciendo un poco de limipeza del foro.