Estimados,
qué haríais vosotros para escanear 750mil documentos en mes - mes y medio?
Tenéis idea de cual es el rendimiento de un escaner 'industrial'?
La idea es escanear esa burrada de documentos y pasarlos por un OCR, meterlos en un servidor de ficheros, e indexarlos con google appliance.
Estaba pensando en contratrar un par de personas de perfil bajo para llevar a cabo la tarea, pero mi cuello de botella está en el número de máquinas, que no se cuantas necesito.
Para más inri, los documentos están en árabe :-/
Muchas gracias! Y perdon por el muy OT
El Miércoles, 12 de Septiembre de 2007 17:26, miguel gmail escribió:
Estimados,
qué haríais vosotros para escanear 750mil documentos en mes - mes y medio?
Tenéis idea de cual es el rendimiento de un escaner 'industrial'?
La idea es escanear esa burrada de documentos y pasarlos por un OCR, meterlos en un servidor de ficheros, e indexarlos con google appliance.
Estaba pensando en contratrar un par de personas de perfil bajo para llevar a cabo la tarea, pero mi cuello de botella está en el número de máquinas, que no se cuantas necesito.
Para más inri, los documentos están en árabe :-/
Muchas gracias! Y perdon por el muy OT
Cuantos meses tienes para hacerlo? Se pueden hacer automaticamente o es una a una? Presupuesto? Si es para abrir nueva linea de negocio merece la pena si es puntual y no pensais en volver a hacer, mejor empresa externa, por lo menos el escaneado.
En automatico tienes maquinas de 20 por minuto, solo es cuestion de soltar money --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Cuantos meses tienes para hacerlo?
Lo decido yo (y mi jefe, vaya).
La idea es hacerlo entre uno y dos meses. Mejor tirando a uno.
Se pueden hacer automaticamente o es una a una?
Ni idea. No he visto las hojas.
Presupuesto?
El que calculemos:
- tanto1 para N escaneres (a definir el tanto1 y N) - tanto para que subcontrates los curritos de mover el papel fisico (yo les diré los recursos que necesito, y que ellos se lo curren) - tanto para el google appliance - tanto para el OCR - doy por hecho que el servidor de ficheros estará disponible
Es decir. Hay dos incognitas a evaluar en esta ecuacion, asumiendo unas condiciones de contorno de realizar el trabajo en un periodo de uno a dos meses (ya digo, mejor un mes que dos). Las incognitas son, el numero de escaneres que hacen falta y las personas.
Si es para abrir nueva linea de negocio merece la pena
No es asunto nuestro; el cliente paga, el cliente manda. Realmente han sido ellos los que nos han dicho lo que querían y cómo lo querían.
si es puntual y no pensais en volver a hacer, mejor empresa externa, por lo menos el escaneado.
No conocemos el mercado de allí... se nos plantean muchas incógnitas.
Cuanto pueden ocupar 750mil documentos de texto? (aprox)
En automatico tienes maquinas de 20 por minuto, solo es cuestion de soltar money
Y en manual? NO más de dos o tres, supongo, no?
El money... creo que no será obstaculo aquí.
El Miércoles, 12 de Septiembre de 2007 22:07, miguel gmail escribió:
Cuantos meses tienes para hacerlo?
Lo decido yo (y mi jefe, vaya).
La idea es hacerlo entre uno y dos meses. Mejor tirando a uno.
Se pueden hacer automaticamente o es una a una?
Ni idea. No he visto las hojas.
Pues es un dato importante, de 10 a 15 segundos a mano (depende del escaner y tipo de papel) a 20 paginas por minuto o mas en uno automatico
Presupuesto?
El que calculemos:
Otro dato, los papelitos son importantes como documento historico o una vez escaneados iran a la basura. Si son importantes casi que olvidate del escaneo automatico. Si son tipo papel cebolla a manita tocara, si son tipo pergamino, vamos algo durillos a manita y si no son un tamaño no extandar a manita. El OCR no te va a valer cualquiera, uno de arabe y muy expecializado.
A mano calcula sobre 10 segundos por pagina y si el papel es delicado se te puede ir a 15 mas despues el proceso de tratamiento y revision. Lo mejor seria meterlo despues en una base de datos documental, con lo que el pdf se deberia descartar, lo que dijo carlos el dejavu y creo que propietarios hay alguno mas bastante bueno.
Esto es muy complicado, lo mejor para el tratamiento del papel fisico empresa externa, hay muchas que solo se dedican a esto y tienen maquinas que a ti no te saldria rentable para un proyecto, a parte de experiencia. Lo de OCR y como almacenarlo ya lo podeis hacer vosotros.
Cuando lo consigais pasa una nota por aqui para decirnos como te ha ido --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Se pueden hacer automaticamente o es una a una?
Ni idea. No he visto las hojas.
Pues es un dato importante, de 10 a 15 segundos a mano (depende del escaner y tipo de papel) a 20 paginas por minuto o mas en uno automatico
Este es un dato muy interesante.
No quiero pensar en la que les espera a los que contratemos para este trabajo, dios mio. Que locura. Que aburrimiento.
Otro dato, los papelitos son importantes como documento historico o una vez escaneados iran a la basura. Si son importantes casi que olvidate del escaneo automatico. Si son tipo papel cebolla a manita tocara, si son tipo pergamino, vamos algo durillos a manita y si no son un tamaño no extandar a manita. El OCR no te va a valer cualquiera, uno de arabe y muy expecializado.
Estas son unas ideas muy muy interesantes.
Que tipo de papel es el que permite procesado automático?
Digamos que un montón de hojas A3-A4, de espesor 'normal' no perfectamente apiladas, contarían para escaneado automático?
A mano calcula sobre 10 segundos por pagina y si el papel es delicado se te puede ir a 15 mas despues el proceso de tratamiento y revision.
Ups, 'tratamiento y revisión'. Eso acojona, con perdón. Es en Arabe, y como yo de arabe no se... pues tendre que delegarlo a gente de bajo nivel y poco comprometida. Genial.
Lo mejor seria meterlo despues en una base de datos documental, con lo que el pdf se deberia descartar, lo que dijo carlos el dejavu y creo que propietarios hay alguno mas bastante bueno.
Por qué hay que descartar el pdf? No es que le tenga ningun cariño particular, pero cual es la razon para descartarlo?
Esto es muy complicado, lo mejor para el tratamiento del papel fisico empresa externa, hay muchas que solo se dedican a esto y tienen maquinas que a ti no te saldria rentable para un proyecto, a parte de experiencia. Lo de OCR y como almacenarlo ya lo podeis hacer vosotros.
Me estas convenciendo. A ver si convenzo a mis jefes.
He hecho unos números de 'servilleta':
Asumiendo 20 dias por mes, 8 horas por día, me salen los siguientes números, pensando en terminar en un mes:
Escaneado manual, a 3 pag/minuto: 26 escáneres Escaneado manual, a 6 pag/minuto: 13 escáneres Escaneado automático: 20 pag/minuto: 4 escáneres
De locos.
Más preguntas que se me ocurren:
- Hay alguna forma de añadir meta información, tales como autor, fecha de creación del documento (la del papel, no la digital, obviamente)? - El sw OCR forma parte del OCR? Si no es así, como creo... cómo se enlazan los procesos de escaneo y ocr?
Muchas gracias!
(ayudais un montón)
El Jueves, 13 de Septiembre de 2007 11:38, miguel gmail escribió:
Se pueden hacer automaticamente o es una a una?
Ni idea. No he visto las hojas.
Pues es un dato importante, de 10 a 15 segundos a mano (depende del escaner y tipo de papel) a 20 paginas por minuto o mas en uno automatico
Este es un dato muy interesante.
No quiero pensar en la que les espera a los que contratemos para este trabajo, dios mio. Que locura. Que aburrimiento.
Deberian mandarte unas cuantas hojas del tipo de papel que es, parece mentira pero seun que escaners le metes una mas gorda o delgada y hacer puñetas las previsiones
Otro dato, los papelitos son importantes como documento historico o una vez escaneados iran a la basura. Si son importantes casi que olvidate del escaneo automatico. Si son tipo papel cebolla a manita tocara, si son tipo pergamino, vamos algo durillos a manita y si no son un tamaño no extandar a manita. El OCR no te va a valer cualquiera, uno de arabe y muy expecializado.
Estas son unas ideas muy muy interesantes.
Que tipo de papel es el que permite procesado automático?
Digamos que un montón de hojas A3-A4, de espesor 'normal' no perfectamente apiladas, contarían para escaneado automático?
Si valdria para automatico, lo de apilado da igual porque las teneis que cuadrar un poco antes de meterlas al escaner
A mano calcula sobre 10 segundos por pagina y si el papel es delicado se te puede ir a 15 mas despues el proceso de tratamiento y revision.
Ups, 'tratamiento y revisión'. Eso acojona, con perdón. Es en Arabe, y como yo de arabe no se... pues tendre que delegarlo a gente de bajo nivel y poco comprometida. Genial.
Lo mejor seria meterlo despues en una base de datos documental, con lo que el pdf se deberia descartar, lo que dijo carlos el dejavu y creo que propietarios hay alguno mas bastante bueno.
Por qué hay que descartar el pdf? No es que le tenga ningun cariño particular, pero cual es la razon para descartarlo?
Pos manias, porque el tratar pdfs en linux no esta conseguido y cualquier otro formato va con la gorra (vamos que va bien).
Esto es muy complicado, lo mejor para el tratamiento del papel fisico empresa externa, hay muchas que solo se dedican a esto y tienen maquinas que a ti no te saldria rentable para un proyecto, a parte de experiencia. Lo de OCR y como almacenarlo ya lo podeis hacer vosotros.
Me estas convenciendo. A ver si convenzo a mis jefes.
Lo malo es que es en casa del cliente y claro esta el problema de que se quede con el trabajo :) o se lo de el cliente despues de algunas pruebas.
Maquinas mira de xerox, canon y hay marcas que no las conoce nadie pero en cuanto miras los precios sabes porque. Eso si, te salen las hojitas hasta planchadas
He hecho unos números de 'servilleta':
esos son lo mejores y por mucho que luego afines casi siempre quedan bien
Asumiendo 20 dias por mes, 8 horas por día, me salen los siguientes números, pensando en terminar en un mes:
Escaneado manual, a 3 pag/minuto: 26 escáneres Escaneado manual, a 6 pag/minuto: 13 escáneres Escaneado automático: 20 pag/minuto: 4 escáneres
De locos.
Me quedaria con la de 6 paginas de momento hasta que hableis con algun fabricante de escaners y os de datos ms exactos
Ten en cuenta que eso solo es el escaneado el proceso posterior se debe comer su tiempo. Renombrado de ficheros o pueden ser 1 2 3 4 ?
Más preguntas que se me ocurren:
- Hay alguna forma de añadir meta información, tales como autor, fecha
de creación del documento (la del papel, no la digital, obviamente)?
Si que se puede hacer o bien en la misma maquina antes de escanear o despues los pdf con pdftk y un pequeño script no hay problema. O con un proyecto de esos con el adobe que no creo resulte muy complicado comprar la version super chachi En pdf deberas preguntar que seguridad quieren
- El sw OCR forma parte del OCR? Si no es así, como creo... cómo se
enlazan los procesos de escaneo y ocr?
eiiinnn??? OCR es el programa de reconocimiento en si Si teneis que comprar maquinas y veo que si ya que es todo en casa del cliente que sean buenas, canon tiene una linea de esas y viene con todo integrado metes el papelito y te sale "ocerrado" e indexado (claro que al arabe pos no se)
Muchas gracias!
(ayudais un montón)
Nosotros estubimos a punto de hacer uno de 300mil hojas de papel cebolla nada mas y nada menos (es un papel que soplas y se rompe). Pero la inversion costaba mas que lo ganado, aun asi ofertaron al concurso, menos mal que no salio, tambien era en casa del cliente.
Y poco mas puedo contar --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2007-09-13 a las 11:38 +0200, miguel gmail escribió:
Lo mejor seria meterlo despues en una base de datos documental, con lo que el pdf se deberia descartar, lo que dijo carlos el dejavu y creo que propietarios hay alguno mas bastante bueno.
Por qué hay que descartar el pdf? No es que le tenga ningun cariño particular, pero cual es la razon para descartarlo?
Yo he tenido que estudiarme hojas de características de chips en pdf escaneado, de fabricantes serios, y se me secaban las pestañas intentando descifrarlos. No me gusta.
El PDF está fantástico cuando el documento original es digital: es decir, el texto es texto. Es horrible con los escaneados de papel (IMO).
Escaneado manual, a 3 pag/minuto: 26 escáneres Escaneado manual, a 6 pag/minuto: 13 escáneres Escaneado automático: 20 pag/minuto: 4 escáneres
De locos.
Mira este vídeo:
http://www.atiz.com/bookdrive_diy.php
Más preguntas que se me ocurren:
- Hay alguna forma de añadir meta información, tales como autor, fecha
de creación del documento (la del papel, no la digital, obviamente)?
Depende del formato de salida. DjVu y PDF lo tienen previsto.
- El sw OCR forma parte del OCR? Si no es así, como creo... cómo se
enlazan los procesos de escaneo y ocr?
OCR es software, sólo software. Y gordo.
La entrada debe ser un formato gráfico (los baratos se enganchan al escanner). La salida es básicamente ascii, pero pueden integrarse con el Word, por ejemplo, entregando un documento básicamente formateado con sus fuentes de letra y todo - pero digo básicamente porque es para que el aspecto visual sea parecido, pero no para crear un documento word correcto en el que las páginas refluyan al cambiar los formatos.
- -- Saludos Carlos E.R.
Cuando lo consigais pasa una nota por aqui para decirnos como te ha ido
De momento no hay mucho que contar.
El proyecto de instalar GSA (Google Search Appliance) se ha caído, debido a un problema de licencias del GSA. Resulta que:
1. Por un lado, Google no vende en Emiratos. Así que el cliente nos pidió que lo compraramos nosotros.
2. Comprandolo nosotros, no se puede transferir la licencia a una tercera parte. Esto es, se quedarían sin soporte durante los dos años que hay de soporte.
Como no podemos hacerlo con GSA por un tema legal, hemos propuesto una solución, y esta basada en Lucene (soft libre):
http://lucene.apache.org/java/docs/
Eso sí, en lugar de una persona, serán / seremos dos personas, y dedicadas a tiempo completo. Mas pasta.
Veremos si el cliente acepta la propuesta :-/
El 12/09/07, miguel gmail escribió:
qué haríais vosotros para escanear 750mil documentos en mes - mes y medio?
Pedir presupuesto a alguna empresa especializada en gestión documental, creo que por el volumen de hojas no sería una mala opción ;-).
Tenéis idea de cual es el rendimiento de un escaner 'industrial'?
Ni idea :-/, pero si además necesitas tratarlo como texto (y en árabe), el proceso será más lento.
Saludos,
El 12/09/07, Camaleón noelamac@gmail.com escribió:
El 12/09/07, miguel gmail escribió:
qué haríais vosotros para escanear 750mil documentos en mes - mes y medio?
Pedir presupuesto a alguna empresa especializada en gestión documental, creo que por el volumen de hojas no sería una mala opción ;-).
Tenéis idea de cual es el rendimiento de un escaner 'industrial'?
Ni idea :-/, pero si además necesitas tratarlo como texto (y en árabe), el proceso será más lento.
esto no es tarea del scanner, pero si del software !!!! el scaner solamente enviara la imagen al software y este hace el trabajo de reconocimiento (o lo que sea)
salu2
Ni idea :-/, pero si además necesitas tratarlo como texto (y en árabe), el proceso será más lento.
esto no es tarea del scanner, pero si del software !!!! el scaner solamente enviara la imagen al software y este hace el trabajo de reconocimiento (o lo que sea)
Se puede automatizar la tarea del OCR?
Google se que tiene uno, pero no tengo ni idea de como funciona.
POr cierto, el que tiene, creo recordar que fue liberado.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2007-09-12 a las 22:13 +0200, miguel gmail escribió:
Se puede automatizar la tarea del OCR?
Google se que tiene uno, pero no tengo ni idea de como funciona.
POr cierto, el que tiene, creo recordar que fue liberado.
Aquí necesitas un OCR de los de pago y de los buenos.
- -- Saludos Carlos E.R.
El 12/09/07, miguel gmail miguel.listas@gmail.com escribió:
Ni idea :-/, pero si además necesitas tratarlo como texto (y en árabe), el proceso será más lento.
esto no es tarea del scanner, pero si del software !!!! el scaner solamente enviara la imagen al software y este hace el trabajo de reconocimiento (o lo que sea)
Se puede automatizar la tarea del OCR?
siiii.. una vez que tengas los archivos scaneados... creas un script y lo automatizas !!! :D
salu2
Pedir presupuesto a alguna empresa especializada en gestión documental, creo que por el volumen de hojas no sería una mala opción ;-).
NO conocemos el mercado de allí... Me imagino que para la parte fea contratarán un par de 'pakis'.
Tenéis idea de cual es el rendimiento de un escaner 'industrial'?
Ni idea :-/, pero si además necesitas tratarlo como texto (y en árabe), el proceso será más lento.
Fabricantes?
Se me ocurren: HP, Xerox, ... alguna más de tamaño industrial?
El 12/09/07, miguel gmail escribió:
NO conocemos el mercado de allí... Me imagino que para la parte fea contratarán un par de 'pakis'.
¿Dónde (lugar físico) tienes que escanear los documentos? ¿Qué formato de salida necesitas (texto plano, rtf...)?
Fabricantes?
Se me ocurren: HP, Xerox, ... alguna más de tamaño industrial?
No entiendo por qué buscas una máquina y no un servicio :-? Si para algo puntual no le veo sentido, ni alquilar por horas ni comprar... pero bueno, marcas de fabricantes de equipos de gran volumen, ocr, se me ocurre Konica-Minolta, Ricoh, más ideas de máquinas en Linuxprinting:
http://openprinting.org/printer_list.cgi
Saludos,
¿Dónde (lugar físico) tienes que escanear los documentos? ¿Qué formato de salida necesitas (texto plano, rtf...)?
Ein? Lugar físico? Pues supongo que un sótano lúgubre y húmedo. Bueno, humedo no, aquello es el pu** desierto, y hace un calor de mil demonios.
El formato de salida lo definiré yo... estaba pensando en pdf.
Importa tanto eso?
Fabricantes?
Se me ocurren: HP, Xerox, ... alguna más de tamaño industrial?
No entiendo por qué buscas una máquina y no un servicio :-? Si para algo puntual no le veo sentido, ni alquilar por horas ni comprar...
El cliente así lo quiere. Suena raro, lo se, pero es así. Básicamente nos ha dicho: Tengo 750mil documentos en papel, quiero que los escaneeis, les paseis un OCR y los indexeis usando el google appliance.
Señor, sí señor, 'sus órdenes, señor.
pero bueno, marcas de fabricantes de equipos de gran volumen, ocr, se me ocurre Konica-Minolta, Ricoh, más ideas de máquinas en Linuxprinting:
Muchas gracias. Mañana empiezo a mirar especificaciones. A ver si los fabricantes me contestan tan rápido como google.
Aprovecho: Impresionante google. Les mandé una consulta por un formulario web, y tardaron 5 minutos, de reloj, en llamarme un preventa..
Les digo que qué rapidez, y el tío me contesta que sí, que como el buscador.
Qué risas.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2007-09-13 a las 00:28 +0200, miguel gmail escribió:
El formato de salida lo definiré yo... estaba pensando en pdf.
Dejavú.
- -- Saludos Carlos E.R.
El formato de salida lo definiré yo... estaba pensando en pdf.
Dejavú.
Diablos, lo que me ha costado entenderte. Querías decir Djvu! :D
Cómo de bueno es? Lo pregunto porque te he leído despotricar contra los OCR libres desde siempre.
Me estoy parando a pensar ahora cómo es el proceso, y me asaltan dudas:
1. Escanear la hoja... Cual es el resultado de esta operación?
2. Me imagino que será un jpg, o un pdf.
3. Cómo se realiza el proceso de OCR sobre lo que sea que salga del escaner?
4. Una vez se haya realizado el OCR... cual es el resultado? En que formato viene el texto?
Muchas gracias!
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2007-09-13 a las 10:49 +0200, miguel gmail escribió:
El formato de salida lo definiré yo... estaba pensando en pdf.
Dejavú.
Diablos, lo que me ha costado entenderte. Querías decir Djvu! :D
Oops O:-)
DjVu, es la grafía correcta.
Cómo de bueno es? Lo pregunto porque te he leído despotricar contra los OCR libres desde siempre.
MUY bueno.
No es un OCR, es un formato gráfico especializado precisamente en documentos escaneados, para su posterior visualización y distribución electrónica, que es precisamente el caso. Es un formato para archivado que compite con el PDF. Puede también incluir una capa de texto en formato texto sacado del OCR.
Pero el PDF los gráficos los guarda internamente como jpgs: el PDF se usa simplemente porque es una forma práctica de poner un libro con las fotos, o sea, un multipágina.
Hay dos herramientas principales para crear .djvu, una comercial y otra libre. La libre funciona, pero es linea de comandos con muchas opciones que hay que ajustar mediante prueba y error hasta conseguir el resultado apetecible. No es práctico para tantos documentos.
La comercial no la he probado, pero se supone que automatiza el proceso,, y facilita hacer cosas que yo no he hecho, como separar el plano monocolor o añadir texto.
Mira en:
http://en.wikipedia.org/wiki/Djvu pue eso. http://djvu.sourceforge.net/ software libre http://www.djvu.org/ noticias, foro, galería http://any2djvu.djvuzone.org/ public server http://www.lizardtech.com/ comercial
http://www.lizardtech.com/download/dl_options.php?page=plugins plugines para iexplorer, firefox, safari, windows, linux, mac.
En http://mybook.bibalex.org/?v=c tienes ejemplos en árabe (Egyptian Arabic Illustrated Childrens Stories). Por ejemplo, http://mybook.bibalex.org/book.php?b=005040 (panel derecho) parece un documento (36 páginas) sobre las pirámides de la "Biblioteca Alexandrina".
El konkeror lo soporta, puede mostrar los miniiconos. Pero no lo soporta el gimp, ni puedes incluir las fotos en el OOo, aunque se pueden reconvertir facilmente a graficos que sí.
Me estoy parando a pensar ahora cómo es el proceso, y me asaltan dudas:
Escanear la hoja... Cual es el resultado de esta operación?
Me imagino que será un jpg, o un pdf.
Yo lo haría a PNG. Luego, a jpg o pdf como postproceso que puedes ajustar. Los escaneres que convierten directamente a PDF lo hacen con mala calidad. El jpg está bien, pero no siempre lo hace con la calidad que te interesa (o sí). El PNG permite convertir a cualquier formato posteriormente - incluyendo DjVu.
Una posibilidad (que hacen las bibliotecas serias) es ofrecer la documentación en varios formatos.
Luego el PNG se puede borrar una vez hechos todos los procesamientos (producto final aceptado). Si el resultado no gusta, con el PNG puedes volver a procesarlo sin necesidad de escanear de nuevo.
- Cómo se realiza el proceso de OCR sobre lo que sea que salga del escaner?
Ni idea.
No tiene que ver con el DjVu ni el pdf: los formatos de almacenamiento se limitan a eso, a almacenar.
- Una vez se haya realizado el OCR... cual es el resultado? En que
formato viene el texto?
Depende del programa de OCR. Puede ser ASCII, o lo que sea que usen los árabes, que no lo se.
- -- Saludos Carlos E.R.
Cómo de bueno es? Lo pregunto porque te he leído despotricar contra los OCR libres desde siempre.
MUY bueno.
Viniendo de tí me lo creo!
No es un OCR, es un formato gráfico especializado precisamente en documentos escaneados, para su posterior visualización y distribución electrónica, que es precisamente el caso. Es un formato para archivado que compite con el PDF. Puede también incluir una capa de texto en formato texto sacado del OCR.
Vale. Entonces... por qué más abajo sugieres PNG??
Te refieres a que el proceso sea:
suite escaner dejavu SW OCR | | | papel -> .djv -> PNG -> .pdf (o .doc, o .loquesea)
Es así? (espero que no se rompa mi muestra de ascii art)
Pero el PDF los gráficos los guarda internamente como jpgs: el PDF se usa simplemente porque es una forma práctica de poner un libro con las fotos, o sea, un multipágina.
Hay dos herramientas principales para crear .djvu, una comercial y otra libre. La libre funciona, pero es linea de comandos con muchas opciones que hay que ajustar mediante prueba y error hasta conseguir el resultado apetecible. No es práctico para tantos documentos.
Tal vez, si los documentos tienen calidad similar, se puedan usar ajustes similares, y meterlo todo en un batch.
La comercial no la he probado, pero se supone que automatiza el proceso,, y facilita hacer cosas que yo no he hecho, como separar el plano monocolor o añadir texto.
Lo investigaré (si es que el diagrama de arriba es correcto)
En http://mybook.bibalex.org/?v=c tienes ejemplos en árabe (Egyptian Arabic Illustrated Childrens Stories). Por ejemplo, http://mybook.bibalex.org/book.php?b=005040 (panel derecho) parece un documento (36 páginas) sobre las pirámides de la "Biblioteca Alexandrina".
Oichs, qué cosas tan bonitas!
El konkeror lo soporta, puede mostrar los miniiconos. Pero no lo soporta el gimp, ni puedes incluir las fotos en el OOo, aunque se pueden reconvertir facilmente a graficos que sí.
Me estoy parando a pensar ahora cómo es el proceso, y me asaltan dudas:
Escanear la hoja... Cual es el resultado de esta operación?
Me imagino que será un jpg, o un pdf.
Yo lo haría a PNG. Luego, a jpg o pdf como postproceso que puedes ajustar. Los escaneres que convierten directamente a PDF lo hacen con mala calidad. El jpg está bien, pero no siempre lo hace con la calidad que te interesa (o sí). El PNG permite convertir a cualquier formato posteriormente - incluyendo DjVu.
O sea, salida del escaner como PNG, y luego convertirlo a djv... por qué? No lo veo :-?
Una posibilidad (que hacen las bibliotecas serias) es ofrecer la documentación en varios formatos.
Luego el PNG se puede borrar una vez hechos todos los procesamientos (producto final aceptado). Si el resultado no gusta, con el PNG puedes volver a procesarlo sin necesidad de escanear de nuevo.
- Cómo se realiza el proceso de OCR sobre lo que sea que salga del escaner?
Ni idea.
... me lo tendrán que contar los proveedores de OCR, quienes sean.
He visto en la wiki de OCR unos cuantos. Pero no tengo ni idea de cuales son mejores o peores... alguien tiene alguna idea?:
* ABBYY FineReader OCR * GOCR * Falcon32 * IPStudio * Microsoft Office Document Imaging * NovoDynamics VERUS * Ocrad * Ocropus * OmniPage * Readiris * SmartScore * Tesseract (software) * TopSoft TopOCR
No tiene que ver con el DjVu ni el pdf: los formatos de almacenamiento se limitan a eso, a almacenar.
Entiendo.
Pero me queda ver en qué etapa aparece el djv :-?
electrónica, que es precisamente el caso. Es un formato para archivado que compite con el PDF. Puede también incluir una capa de texto en formato texto sacado del OCR.
Me falta una cosa. Qué quieres decir con 'puede incluir una capa de texto en formato texto sacado del OCR??
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2007-09-13 a las 19:03 +0200, miguel gmail escribió:
electrónica, que es precisamente el caso. Es un formato para archivado que compite con el PDF. Puede también incluir una capa de texto en formato texto sacado del OCR.
Me falta una cosa. Qué quieres decir con 'puede incluir una capa de texto en formato texto sacado del OCR??
Es un formato que contiene varias "capas" de datos. Puede tener una capa de blanco y negro con las letras (que es la que se envía antes por web) de una resolución suficiente para ser legible con facilidad, y otra capa a otra resolución con los colores. Me parece recordar que el color de fondo también puede ir aparte (el color del papel).
Y puede tener otra capa (fichero incluido, si prefieres decirlo así) que contiene el texto en formato texto, con diversas utilidades, como indexado, archivado, busqueda electrónica de un docuemento que contenga cierta frase...
Ese "capeado" es el que soy incapaz de generar. No se como hacerlo con las herramientas libres. Y se puede, sin embargo.
Todo esto seguro que lo explica en los enlaces que puse; yo hablo de memoria y tendré imprecisiones y errores.
Pe, Wikipedia:
DjVu (pronounced déjà vu) is a computer file format designed primarily to store scanned images, especially those containing text and line drawings. It uses technologies such as image layer separation of text and background/images, progressive loading, arithmetic coding, and lossy compression for bitonal images. This allows for high quality, readable images to be stored in a minimum of space, so that they can be made available on the web.
DjVu has been promoted as an alternative to PDF, actually outperforming PDF on most scanned documents. The DjVu developers report that color magazine pages compress to 4070KB, black and white technical papers compress to 1540KB, and ancient manuscripts compress to around 100KB; all of these are significantly better than the typical 500KB required for a satisfactory JPEG image. Like PDF, DjVu can contain an OCRed text layer, making it easy to perform cut and paste and text search operations.
...
DjVu divides a single image into many different images, then compresses them separately. To create a DjVu file, the initial image is first separated into three images: a background image, a foreground image, and a mask image. The background and foreground images are typically lower-resolution color images (e.g., 100dpi); the mask image is a high-resolution bilevel image (e.g., 300dpi) and is typically where the text is stored. The background and foreground images are then compressed using a wavelet-based compression algorithm named IW44. The mask image is compressed using a method called JB2 (similar to JBIG2). The JB2 encoding method identifies nearly-identical shapes on the page, such as multiple occurrences of a particular character in a given font, style, and size. It compresses the bitmap of each unique shape separately, and then encodes the locations where each shape appears on the page. Thus, instead of compressing a letter "e" in a given font multiple times, it compresses the letter "e" once (as a compressed bit image) and then records every place on the page it occurs.
In 2002 the DjVu file format was chosen by the Internet archive as the format in which its Million Book Project provides scanned public domain books online (along with TIFF and PDF).
DjVu format will be used by the One Laptop per Child project in order to easily supply existing paper books in an eBook format. The advantage of DjVu is that it is highly compressed and it does not require any font support. [1]
...
PDF is most useful when the original source is an electronic document such as a Microsoft Word doc or TeX file. Such documents benefit most from the vector graphics technology that underlies PDF. DjVu files can be marginally smaller but only deliver a high resolution image, possibly enriched with the associated text.
DjVu is very good for image files, and has especially been optimized for scanned text and images. If one has a set of scanned pages from a book or article, DjVu is superior to PDF. However, PDF could be better if the scanned raster images can be transformed into high quality vector graphics, for instance by applying optical character recognition to the scanned image, identifying the fonts, and carefully proofreading the resulting file. This procedure is often undesirable or time/cost prohibitive. Suitable fonts might not be available, or one may want to preserve the original document more exactly, including signatures, marginal comments, paper texture, or other markings. In such cases, DjVu is the better choice.
- -- Saludos Carlos E.R.
El 13/09/07, miguel gmail escribió:
Te refieres a que el proceso sea:
suite escaner dejavu SW OCR | | |papel -> .djv -> PNG -> .pdf (o .doc, o .loquesea)
Es así? (espero que no se rompa mi muestra de ascii art)
En GMail se mantiene "intacto" (el ascii).
Pero no ve el motivo de dar dos pasos en lugar de uno... ¿porqué pasarlo a png si djvu (o cualquier programa que permita ocr) puede grabarlo directamente a formato pdf, doc, xml, txt? ¿Necesitas el formato gráfico para algo?
- ABBYY FineReader OCR
Este viene con los escáneres de "estar por casa", al menos el paquete básico.
- OmniPage
También accesible al consumidor medio.
- Readiris
También accesible al consumidor medio.
- Tesseract (software)
Este es el de Google.
Saludos,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2007-09-13 a las 19:10 +0200, Camaleón escribió:
Pero no ve el motivo de dar dos pasos en lugar de uno... ¿porqué pasarlo a png si djvu (o cualquier programa que permita ocr) puede grabarlo directamente a formato pdf, doc, xml, txt? ¿Necesitas el formato gráfico para algo?
No puedes generar un DjVu directamente. Necesitas generarlo con un programa o conjunto de programas que analizan la imagen ya escaneada y grabada en un formato gráfico adecuado. Es un formato final, no intermedio.
De hecho, las herramientas libres DjVu necesitan que les pases las imagenes en formato PNM, que es enorme. Yo genero PNGs, y luego convierto uno a PNM, de ahí a DjVu, y entonces borro el PNM. El png lo guardo temporalmente o lo borro definitivamente (o pasa al backup). Si fuera para una biblioteca de incunables igual lo guardaba offline en caja fuerte.
El DjVu es el que se deja para acceso del público por internet, porque es ligero en transmisión y en recursos del cliente que lo visualiza. También se puede hacer en PDF, pero resulta menos ideal (ver comparativa en wikipedia). O en jpg. Esos dos formatos, en las bibliotecas que lo usan, lo añaden al lado para que la gente no se queje de que no sabe lo que es djvu y no sabe donde pinchar para instalar el plugin en el windows o el suse :-P
(En suse hay un rpm en la distro: más fácil imposible)
Mira un sitio que usa djvu como presenta un libro:
http://www.archive.org/details/CaesarInAbyssinia
Si instalas antes el plugin en el firefox, puedes ver las páginas como texto o como gráfico, a elegir.
Espera, me parece que ese sitio no usa el plugin interno, sino uno en java que se carga al vuelo, el "JavaDjVu". Jo, vaya gracia... no deja descargar el fichero :-(
En cambio, en "http://mybook.bibalex.org/book.php?b=005040" sí se usa el plugin propio del navegador, y tienes acceso al fichero djvu real.
- -- Saludos Carlos E.R.
El 13/09/07, Carlos E. R. escribió:
No puedes generar un DjVu directamente. Necesitas generarlo con un programa o conjunto de programas que analizan la imagen ya escaneada y grabada en un formato gráfico adecuado. Es un formato final, no intermedio.
Ah, buf... eh, espera un momento... (iniciando modo "malo-maloso") >:-):
How can one scan a printed book to a djvu file? http://planetdjvu.opendoc.it/viewtopic.php?p=957#957
"(...) under Windows the main app to scan and save directly in DjVu file format is Lizardtech Document Express Professional Edition (http://www.lizardtech.com/products/doc/professional.php). It manages the scanner via TWAIN interface.
You can check also Scan Station (http://www.versis.co.uk/Scan-Station.htm). It has also the capability to scan directly in DjVu (and PDF)."
Luego es posible, hay algunos programas que sí vuelcan a formato djvu directamente... además, con twain (ji, ji :-P)
Mira un sitio que usa djvu como presenta un libro:
Ah, eh, está muy bien... me gusta la herramienta en java, es un visor muy currado, aunque es un poco lento, pero es que son 400 páginas de César en Abisinia :-)
Por cierto, el texto tiene algunos (bastantes) fallos... por ejemplo, no reconoce la "AE" de "Caesar"... dentro del libro hay más errores en el texto, pero seguramente sea por la codificación que usan en el plugin, no por el formato en sí...
Si instalas antes el plugin en el firefox, puedes ver las páginas como texto o como gráfico, a elegir.
Espera, me parece que ese sitio no usa el plugin interno, sino uno en java que se carga al vuelo, el "JavaDjVu". Jo, vaya gracia... no deja descargar el fichero :-(
Se ve bien, aunque sólo lo he podido cargar una vez, a la segunda me ha saltado un error de excepción de java: "java.io.IOException: Invalid DjVu File Format"
En cambio, en "http://mybook.bibalex.org/book.php?b=005040" sí se usa el plugin propio del navegador, y tienes acceso al fichero djvu real.
Hum, quizá dentro de unos añitos, cuando el visor djvu venga "de serie" con SuSE :-)
Saludos,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2007-09-13 a las 21:34 +0200, Camaleón escribió:
El 13/09/07, Carlos E. R. escribió:
No puedes generar un DjVu directamente. Necesitas generarlo con un programa o conjunto de programas que analizan la imagen ya escaneada y grabada en un formato gráfico adecuado. Es un formato final, no intermedio.
Este correo tuyo me ha llegado por triplicado:
- -*- 1
Received: by 10.114.170.1 with SMTP id s1mr800656wae.1189712108391; Thu, 13 Sep 2007 12:35:08 -0700 (PDT) Received: by 10.141.29.13 with HTTP; Thu, 13 Sep 2007 12:34:14 -0700 (PDT) Message-ID: b23e69e70709131234v7476571au6383cd6ec3a0b74a@mail.gmail.com Date: Thu, 13 Sep 2007 21:34:14 +0200
- -*- 2
Received: by 10.141.48.10 with SMTP id a10mr204597rvk.1189712081382; Thu, 13 Sep 2007 12:34:41 -0700 (PDT) Received: by 10.141.29.13 with HTTP; Thu, 13 Sep 2007 12:34:14 -0700 (PDT) Message-ID: b23e69e70709131234v7476571au6383cd6ec3a0b74a@mail.gmail.com Date: Thu, 13 Sep 2007 21:34:14 +0200
- -*- 3
Received: by 10.140.148.3 with SMTP id v3mr427rvd.1189712054402; Thu, 13 Sep 2007 12:34:14 -0700 (PDT) Received: by 10.141.29.13 with HTTP; Thu, 13 Sep 2007 12:34:14 -0700 (PDT) Message-ID: b23e69e70709131234v7476571au6383cd6ec3a0b74a@mail.gmail.com Date: Thu, 13 Sep 2007 21:34:14 +0200
Curioso. Tú no vas a ver ninguno, claro, gmail los borrará.
Ah, buf... eh, espera un momento... (iniciando modo "malo-maloso") >:-):
¡Mmmm!
How can one scan a printed book to a djvu file? http://planetdjvu.opendoc.it/viewtopic.php?p=957#957
"(...) under Windows the main app to scan and save directly in DjVu file format is Lizardtech Document Express Professional Edition (http://www.lizardtech.com/products/doc/professional.php). It manages the scanner via TWAIN interface.
You can check also Scan Station (http://www.versis.co.uk/Scan-Station.htm). It has also the capability to scan directly in DjVu (and PDF)."
Luego es posible, hay algunos programas que sí vuelcan a formato djvu directamente... además, con twain (ji, ji :-P)
Ja, ja.
Mira un sitio que usa djvu como presenta un libro:
Ah, eh, está muy bien... me gusta la herramienta en java, es un visor muy currado, aunque es un poco lento, pero es que son 400 páginas de César en Abisinia :-)
Es lento, sí. Y posiblemente baje página a página desde el servidor cuando la visualizas.
Por cierto, el texto tiene algunos (bastantes) fallos... por ejemplo, no reconoce la "AE" de "Caesar"... dentro del libro hay más errores en el texto, pero seguramente sea por la codificación que usan en el plugin, no por el formato en sí...
Fácilmente.
Es un proyecto indio, por cierto.
Se puede bajar los ficheros ascii en un tar. Veamos el de cesar, una página cualquiera (00008.txt). [...] ¿Mande?
] " Do not shed any blood among you. You who were ] at the front, go home to your land and possessions and ] continue your farming as before. Do not turn yourself ] against the police and those charged with the mainten- ] ance of order. Do not destroy the roads or oppose the ] advance of my Army, because we do not want your lives, ] your possessions, or your money. But if you destroy ] our roads or try to oppose the advance of my Army, ] then the Italian Army will destroy and kill without pity, ] the aeroplanes will massacre from the air and destroy ] everything that exists." ] ] ¿Aeroplanos? ] ] In the unexpurgated phrase of General Queipo de Llano : ] " All honour to such a grand paper." ] ] Burgos, 1936.
¿El Caesar dijo eso? Que cosa más rara...
Es que no es Caesar de verdad. ¡Es otro! Qué fiasco...
En cambio, en "http://mybook.bibalex.org/book.php?b=005040" sí se usa el plugin propio del navegador, y tienes acceso al fichero djvu real.
Hum, quizá dentro de unos añitos, cuando el visor djvu venga "de serie" con SuSE :-)
Venga ya, viene de serie. Eso es como si me dices que no usas el mysql o el apache porque "no viene de serie". No me vengas con esas.
- -- Saludos Carlos E.R.
El 13/09/07, Carlos E. R. escribió:
Este correo tuyo me ha llegado por triplicado:
Anda... espero que no lo haya hecho también a la lista. Hum, no, al menos en el archivo no aparecen 3 mensajes. Raro :-/.
Curioso. Tú no vas a ver ninguno, claro, gmail los borrará.
Lo raro es que en la lista tampoco aparecen triplicados :-?
Es lento, sí. Y posiblemente baje página a página desde el servidor cuando la visualizas.
Sí, como el Acrobat con los pdf. Le he dicho que vaya a la última página y me he cansado de esperar a visualizarla, al final he cerrado el navegador antes de verla :-)
Es un proyecto indio, por cierto.
Y el mismo que nombran en el foro como programa que permite volcar directamente a formato .djvu (Lizardtech Document Express Professional Edition).
¿El Caesar dijo eso? Que cosa más rara...
Es que no es Caesar de verdad. ¡Es otro! Qué fiasco...
Hum, cierto, parece que el título lo utiliza como "ejemplo", los hechos que narra son de otra índole. En la introducción se puede leer:
" THIS BOOK, which casts a narrow sidelight on an unimportant ! series of massacres known as the Italo-Ethiopian War, bears, I am sorry to say, a title which will disappoint many, Caesar in Abyssinia conjures up a picture of cohorts, horse-hair-crests and Commentaries, all centring round the great Julius himself ungasmasked in the field. (...) My task is rather in this book to show what was the strength and spirit of the Ethiopian armies sent against a European Great Power.
Venga ya, viene de serie. Eso es como si me dices que no usas el mysql o el apache porque "no viene de serie". No me vengas con esas.
A ver, estadísticas del uso e instalaciones de visores djvu en los equipos (incluso en los hand-held), porcentaje de uso, etc. >:-) Ojo, para archivo y clasificación interna no me parece un mal formato.
Saludos,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2007-09-14 a las 09:21 +0200, Camaleón escribió:
El 13/09/07, Carlos E. R. escribió:
Este correo tuyo me ha llegado por triplicado:
Anda... espero que no lo haya hecho también a la lista. Hum, no, al menos en el archivo no aparecen 3 mensajes. Raro :-/.
El archivo los habrá eliminado porque los tres tienen el mismo Message-ID. Pero los demás sí lo habrán recibido, si no tienen otro filtro. A mi me han llegado. Por las horas de los "received" se ve que a suse les llegaron los tres, con medio minuto de diferencia.
Curioso. Tú no vas a ver ninguno, claro, gmail los borrará.
Lo raro es que en la lista tampoco aparecen triplicados :-?
El archivo tendrá un filtro.
Es lento, sí. Y posiblemente baje página a página desde el servidor cuando la visualizas.
Sí, como el Acrobat con los pdf. Le he dicho que vaya a la última página y me he cansado de esperar a visualizarla, al final he cerrado el navegador antes de verla :-)
Eso es el java. O javascript. No me he fijado cual es O:-)
Es un proyecto indio, por cierto.
Y el mismo que nombran en el foro como programa que permite volcar directamente a formato .djvu (Lizardtech Document Express Professional Edition).
Pero así a vuelapluma no he visto ningún libro que me interese.
Venga ya, viene de serie. Eso es como si me dices que no usas el mysql o el apache porque "no viene de serie". No me vengas con esas.
A ver, estadísticas del uso e instalaciones de visores djvu en los equipos (incluso en los hand-held), porcentaje de uso, etc. >:-) Ojo, para archivo y clasificación interna no me parece un mal formato.
Yo ya he dicho que la pega es el poco uso que tiene. Pero como formato en sí es magnífico. Está diseñado para archivado digital de documentos escaneados...
Y en la suse viene de serie. No por defecto, pero sí de serie. Lo mismo que vienen cosas como el apache, tienes que marcarlas para que se instalen.
- -- Saludos Carlos E.R.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2007-09-13 a las 19:00 +0200, miguel gmail escribió:
Cómo de bueno es? Lo pregunto porque te he leído despotricar contra los OCR libres desde siempre.
MUY bueno.
Viniendo de tí me lo creo!
:-)
Pero hay quien discrepa, cuidado. Es bastante desconocido. Que una cosa sea buena no quiere decir que tenga éxito... recuerda la guerra de los formatos de vídeo en España.
No es un OCR, es un formato gráfico especializado precisamente en documentos escaneados, para su posterior visualización y distribución electrónica, que es precisamente el caso. Es un formato para archivado que compite con el PDF. Puede también incluir una capa de texto en formato texto sacado del OCR.
Vale. Entonces... por qué más abajo sugieres PNG??
Te refieres a que el proceso sea:
suite escaner dejavu SW OCR | | |papel -> .djv -> PNG -> .pdf (o .doc, o .loquesea)
Es así? (espero que no se rompa mi muestra de ascii art)
No.
El escaner saca como resultado un fichero gráfico en PNG. De ese, como postproceso, se convierte a todos los demás: JPG, PDF, DjVu, ascii via OCR, etc.
De hecho, en linux al menos, se usa un formato gráfico distinto para hacer esa operación: PNM.
The PNM format is just an abstraction of the PBM, PGM, and PPM formats. I.e. the name 'PNM' refers collectively to PBM, PGM, and PPM.
The name 'PNM' is an acronym derived from 'Portable Any Map.' This derivation makes more sense if you consider it in the con- text of the other Netpbm format names: PBM, PGM, and PPM.
The more general term 'Netpbm format' refers to the PNM formats plus PAM.
Es un formato horriblemente gigantesco, es enorme, sin comprimir. Pero algunos programas de OCR lo usan como origen, y el conversor libre a DjVu también.
La conversión a DjVu es computacionalmente pesada. Bastante más que a jpg. En cambio la lectura es rápida: está diseñado para su transmisión web de modo que la imagen va apareciendo poco a poco según la visualizas, sin tener que esperar a que se descargue entera. Encima el visualizador usa poca memoria.
No encontrarás escaners que saquen directamente DjVu, no lo creo. Pero a PDF sí, incluso en baratos. Bueno, en realidad es el driver que hace la conversión interna; estoy seguro que graba en un formato gráfico intermedio temporalmente.
Pero el PDF los gráficos los guarda internamente como jpgs: el PDF se usa simplemente porque es una forma práctica de poner un libro con las fotos, o sea, un multipágina.
Hay dos herramientas principales para crear .djvu, una comercial y otra libre. La libre funciona, pero es linea de comandos con muchas opciones que hay que ajustar mediante prueba y error hasta conseguir el resultado apetecible. No es práctico para tantos documentos.
Tal vez, si los documentos tienen calidad similar, se puedan usar ajustes similares, y meterlo todo en un batch.
Podría ser. Pero conseguir ficheros DjVu con todas las florituras no es facil con software libre. Yo no lo he conseguido.
Yo uso este proceso:
C44=/usr/bin/c44 PNGTOPNM=pngtopnm
echo Converting $FILE if test -s "$FILE" ; then DIRECTORIO=`dirname "$FILE"` TIPO=`/usr/bin/file -ib "$FILE"` case "$TIPO" in "image/jpeg") $C44 -dpi 240 -slice $SLICE -crcbhalf "$FILE" ;; "image/png") NOMBRE=`basename "$FILE" png` NOMBRECMPLTO=$DIRECTORIO/$NOMBRE echo calculating resolution set -- $(identify -units PixelsPerInch -format "%x %y %z" $FILE) case "$1" in 359.994) DPI=360 ;; 240.005) DPI=240 ;; *) echo resolución $1 no prevista echo -$1- $2 -$3- $4 break ;; esac
echo "Using DPI="$DPI echo calculating PNM. $PNGTOPNM "$FILE" > "$NOMBRECMPLTO"pnm echo converting to djvu #ls -lh "$NOMBRECMPLTO"pnm #$C44 -dpi 240 -slice $SLICE -crcbhalf "$NOMBRECMPLTO"pnm case "$OPT" in # no le gustan los espacios dentro de las comillas "" -low) $C44 -dpi $DPI -slice "19+17+13+9+7+5+3+2+1" -crcbhalf "$NOMBRECMPLTO"pnm ;; -med) $C44 -dpi $DPI -slice "23+19+17+13+9+7+5+3" -crcbhalf "$NOMBRECMPLTO"pnm ;; -hi) $C44 -dpi $DPI -slice "23+19+17+13+9+7+5+3+2+1" "$NOMBRECMPLTO"pnm ;; #-vhi) $C44 -dpi 360 -slice "27+23+19+17+13+9+7+5+3" "$NOMBRECMPLTO"pnm ;; -vhi) $C44 -dpi $DPI -slice "72+11+10+10" "$NOMBRECMPLTO"pnm ;; -ehi) $C44 -dpi $DPI -slice "72+11+10+10" "$NOMBRECMPLTO"pnm ;; #72+11+10+10 esac rm "$NOMBRECMPLTO"pnm ;;
*) echo "Non recognized file type ($TIPO) for this script." exit ;; esac
Nota: se puede convertir de jpg a djvu directamente, pero no es recomendable: es un proceso con doble pérdida.
La comercial no la he probado, pero se supone que automatiza el proceso,, y facilita hacer cosas que yo no he hecho, como separar el plano monocolor o añadir texto.
Lo investigaré (si es que el diagrama de arriba es correcto)
No, no lo era :-)
En http://mybook.bibalex.org/?v=c tienes ejemplos en árabe (Egyptian Arabic Illustrated Childrens Stories). Por ejemplo, http://mybook.bibalex.org/book.php?b=005040 (panel derecho) parece un documento (36 páginas) sobre las pirámides de la "Biblioteca Alexandrina".
Oichs, qué cosas tan bonitas!
Desde luego que lo es, aunque no entiendo ni papa de lo que dice :-)
Yo lo haría a PNG. Luego, a jpg o pdf como postproceso que puedes ajustar. Los escaneres que convierten directamente a PDF lo hacen con mala calidad. El jpg está bien, pero no siempre lo hace con la calidad que te interesa (o sí). El PNG permite convertir a cualquier formato posteriormente - incluyendo DjVu.
O sea, salida del escaner como PNG, y luego convertirlo a djv... por qué? No lo veo :-?
Porque el PNG es un formato "raster", un bitmap mejorado por compresión y portabilidad. El djvu es un formato complejo y procesado.
- Cómo se realiza el proceso de OCR sobre lo que sea que salga del escaner?
Ni idea.
... me lo tendrán que contar los proveedores de OCR, quienes sean.
He visto en la wiki de OCR unos cuantos. Pero no tengo ni idea de cuales son mejores o peores... alguien tiene alguna idea?:
Nop.
A lo mejor tienes que probarlos, porque se trata de árabe. Igual teneis que subcontratar a un árabe entendido en el tema ;-)
Pero me queda ver en qué etapa aparece el djv :-?
Postproceso de la imagen ya escaneada, como formato de visualización y almacenamiento para el usuario final.
- -- Saludos Carlos E.R.
El 2007-09-13 a las 19:00 +0200, miguel gmail escribió:
Lo del escaneo masivo .......
* Creo que vas por mal camino y falta informacion sobre los objetivos.
* ¿El documento final ha de ordenarse, clasificarse, nombrarse, referenciarse relacionarse y ser editable?, por que si es asi ponte en contacto con documentum y te diran scanners que es lo facil y ocr en cuestion, por que lo primero que necesitas para un procesado en que la manopla intervenga lo menos posible es una base de datos documental de narices que pueda adquirir directamente del scanner, procesar, nombrar, meter metadatos, referenciar, clasificar, almacenar en un lado las partes legibles, relacionarlas convirtiendo referencias para busquedas y el resto aparte, esto sobre linux te va a costar encontrarlo y si lo encuentras avisa, esto es carisimo y es llevado a cabo por empresas especializadas, no hay otra solucion (francamente creo que es lo que deberias hacer a la vista del tiempo y ausencia de infraestructura y experiencia en el asunto).
* Si el producto final "solo" ha de ser un documento nombrado, referenciado y clasificado a pseudomano e importacion masiva a las "colecciones" de la estructura del DMS, la ocr solo sirve para indexar el contenido legible (es una tarea en segundo plano), esta tarea ademas puede y debe efectuarse a la hora de importar masivamente y de forma desatendida los documentos a un Sistema Documental asi como tareas desatendidas con los ya importados (caracteristicas generales de cualquier DMS) tsearch en postgre (yo uso DocMGR), indexa el contenido (knowledge-tree, DocMGR y Alfresco desarrollador de documentum creo que esta todavia algo verde y es un proyecto mas alla de un DMS), esto es mucho mas barato pero nada de 6x1 y me llevo dos, calcula de cuatro meses para arriba y no te equivocaras, al menos dos scanners, 2 o 3 personas para el control de alimentacion y clasificado, al menos un operador que entienda Arabe (si son documentos de cierto perfil tecnico, facturas, documentos legales etc, ha de tener cierta cultura) el operador que trate el documento en pantalla (nombrado, referenciado), ha de descansar obligatoriamente cada hora como muy tarde o ser rotado).
* Puedes buscar tambien algun ERMS/ECM con caracteristicas avanzadas documentales.
* En esta segunda opcion (va a ser muy a manopla) yo buscaria un DMS que adquiera directamente del scanner, knowledge-tree las versiones de pago lo hacen, vale una pasta, el operador nombra, referencia y guarda (previa composicion de la estructura documental de almacenamiento que al cliente le interese), las aplicaciones de ocr integradas en el DMS (gocr u otras) ya se encargan periodicamente de repasar los documentos y acceden a diversos tipos de archivos tiff, pdf, word, etc y tsearch indexa el contenido (es decir esto seria un almacenamiento de ficheros del tipo que sean) con su correspondiente gestion documental y control de acceso, versiones, workflows, indexado, busqueda y estaria clasificado en secciones, etc.
* Puedes buscar tambien algun ERMS/ECM con caracteristicas avanzadas documentales.
* Especifica que se pretende conseguir al final y te daremos una solucion y metodo de trabajo (cadena) necesitas un plan de etapas y trabajos previos, en unos u otros casos, que te evite problemas serios incluido el fiasco total.
Hola.
hace años que no toco este tema, Pero lo primero (no me he leido todos los comentarios y es posible que ya se indicase), es saber exactamente lo que tienes entre las manos.
El volumen lo conocemos.
Los documentos son manuscritos (o tienen partes manuscritas) si o no.
Los documentos Son en un formato (como una factura).
Que porcentaje de error estas dispuesto a tener.
El documento final, lo desea en hoja de calculo, base de datos, texto, etc.
Es un unico tipo de documento con un solo formato, o multiples tipos de formatos.
Calidad de la imagen original. (no solamente que se vea bien, sino que las hojas no estén dobladas, rotas, etc.)
Presupuesto.
Creo que respondiendo a las preguntas anteriores, se puede hacer una idea mas o menos de lo que necesita (Tipo de scaners, OCR o ICR, Gestión documental o no, etc.)
Un saludo.
jose maria escribió:
El 2007-09-13 a las 19:00 +0200, miguel gmail escribió:
Lo del escaneo masivo .......
Creo que vas por mal camino y falta informacion sobre los objetivos.
¿El documento final ha de ordenarse, clasificarse, nombrarse, referenciarse
relacionarse y ser editable?, por que si es asi ponte en contacto con documentum y te diran scanners que es lo facil y ocr en cuestion, por que lo primero que necesitas para un procesado en que la manopla intervenga lo menos posible es una base de datos documental de narices que pueda adquirir directamente del scanner, procesar, nombrar, meter metadatos, referenciar, clasificar, almacenar en un lado las partes legibles, relacionarlas convirtiendo referencias para busquedas y el resto aparte, esto sobre linux te va a costar encontrarlo y si lo encuentras avisa, esto es carisimo y es llevado a cabo por empresas especializadas, no hay otra solucion (francamente creo que es lo que deberias hacer a la vista del tiempo y ausencia de infraestructura y experiencia en el asunto).
- Si el producto final "solo" ha de ser un documento nombrado, referenciado y
clasificado a pseudomano e importacion masiva a las "colecciones" de la estructura del DMS, la ocr solo sirve para indexar el contenido legible (es una tarea en segundo plano), esta tarea ademas puede y debe efectuarse a la hora de importar masivamente y de forma desatendida los documentos a un Sistema Documental asi como tareas desatendidas con los ya importados (caracteristicas generales de cualquier DMS) tsearch en postgre (yo uso DocMGR), indexa el contenido (knowledge-tree, DocMGR y Alfresco desarrollador de documentum creo que esta todavia algo verde y es un proyecto mas alla de un DMS), esto es mucho mas barato pero nada de 6x1 y me llevo dos, calcula de cuatro meses para arriba y no te equivocaras, al menos dos scanners, 2 o 3 personas para el control de alimentacion y clasificado, al menos un operador que entienda Arabe (si son documentos de cierto perfil tecnico, facturas, documentos legales etc, ha de tener cierta cultura) el operador que trate el documento en pantalla (nombrado, referenciado), ha de descansar obligatoriamente cada hora como muy tarde o ser rotado).
- Puedes buscar tambien algun ERMS/ECM con caracteristicas avanzadas
documentales.
- En esta segunda opcion (va a ser muy a manopla) yo buscaria un DMS que
adquiera directamente del scanner, knowledge-tree las versiones de pago lo hacen, vale una pasta, el operador nombra, referencia y guarda (previa composicion de la estructura documental de almacenamiento que al cliente le interese), las aplicaciones de ocr integradas en el DMS (gocr u otras) ya se encargan periodicamente de repasar los documentos y acceden a diversos tipos de archivos tiff, pdf, word, etc y tsearch indexa el contenido (es decir esto seria un almacenamiento de ficheros del tipo que sean) con su correspondiente gestion documental y control de acceso, versiones, workflows, indexado, busqueda y estaria clasificado en secciones, etc.
- Puedes buscar tambien algun ERMS/ECM con caracteristicas avanzadas
documentales.
- Especifica que se pretende conseguir al final y te daremos una solucion y
metodo de trabajo (cadena) necesitas un plan de etapas y trabajos previos, en unos u otros casos, que te evite problemas serios incluido el fiasco total.
--------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2007-09-13 a las 22:00 +0200, Pedro Marquina escribió:
El volumen lo conocemos.
Los documentos son manuscritos (o tienen partes manuscritas) si o no.
Y también es crucial saber si están encuadernados o no, y si son frágiles.
- -- Saludos Carlos E.R.
El 13/09/2007 22:12:51 Carlos E. R. escribió:
robin.listas> robin.listas> Y también es crucial saber si están encuadernados o no, y si son frágiles.
Lo de la encuadernación me recuerda que en Google se pueden encontrar múltiples artículos (fundamentalmente los técnicos) sobre las pruebas piloto de digitalización de los Registros Civiles españoles, que hizo la empresa Indra.
Lo del escaneo masivo .......
- Creo que vas por mal camino y falta informacion sobre los objetivos.
Tienes razón.
No tengo requerimientos como tales.
Parece que el alcance de este 'proyecto' es la implementacion del GSA (Google Search Appliance) para digitalizar los 40mil docs, unas750mil paginas. Así, con esos nombres y apellidos.
Lo que me jo** es que creen que el GSA es como la aspirina, que todo lo cura, y para todo viene bien, por lo que sus expectativas no serán cubiertas.
- ¿El documento final ha de ordenarse, clasificarse, nombrarse, referenciarse
relacionarse y ser editable?, por que si es asi ponte en contacto con documentum y te diran scanners que es lo facil y ocr en cuestion, por que lo primero que necesitas para un procesado en que la manopla intervenga lo menos posible es una base de datos documental de narices que pueda adquirir directamente del scanner, procesar, nombrar, meter metadatos, referenciar, clasificar, almacenar en un lado las partes legibles, relacionarlas convirtiendo referencias para busquedas y el resto aparte, esto sobre linux te va a costar encontrarlo y si lo encuentras avisa, esto es carisimo y es llevado a cabo por empresas especializadas, no hay otra solucion (francamente creo que es lo que deberias hacer a la vista del tiempo y ausencia de infraestructura y experiencia en el asunto).
Esa es justo la idea que estuve pensando anoche.
El documentum les vendría muy, pero que muy bien.
- Si el producto final "solo" ha de ser un documento nombrado, referenciado y
clasificado a pseudomano e importacion masiva a las "colecciones" de la estructura del DMS, la ocr solo sirve para indexar el contenido legible (es una tarea en segundo plano), esta tarea ademas puede y debe efectuarse a la hora de importar masivamente y de forma desatendida los documentos a un Sistema Documental asi como tareas desatendidas con los ya importados (caracteristicas generales de cualquier DMS) tsearch en postgre (yo uso DocMGR), indexa el contenido (knowledge-tree, DocMGR y Alfresco desarrollador de documentum creo que esta todavia algo verde y es un proyecto mas alla de un DMS), esto es mucho mas barato pero nada de 6x1 y me llevo dos, calcula de cuatro meses para arriba y no te equivocaras, al menos dos scanners, 2 o 3 personas para el control de alimentacion y clasificado, al menos un operador que entienda Arabe (si son documentos de cierto perfil tecnico, facturas, documentos legales etc, ha de tener cierta cultura) el operador que trate el documento en pantalla (nombrado, referenciado), ha de descansar obligatoriamente cada hora como muy tarde o ser rotado).
- Puedes buscar tambien algun ERMS/ECM con caracteristicas avanzadas
documentales.
- En esta segunda opcion (va a ser muy a manopla) yo buscaria un DMS que
adquiera directamente del scanner, knowledge-tree las versiones de pago lo hacen, vale una pasta, el operador nombra, referencia y guarda (previa composicion de la estructura documental de almacenamiento que al cliente le interese), las aplicaciones de ocr integradas en el DMS (gocr u otras) ya se encargan periodicamente de repasar los documentos y acceden a diversos tipos de archivos tiff, pdf, word, etc y tsearch indexa el contenido (es decir esto seria un almacenamiento de ficheros del tipo que sean) con su correspondiente gestion documental y control de acceso, versiones, workflows, indexado, busqueda y estaria clasificado en secciones, etc.
- Puedes buscar tambien algun ERMS/ECM con caracteristicas avanzadas
documentales.
Buff, voy a pasar tu mail por un intérprete. Tengo que leerlo un poco más despacio!
- Especifica que se pretende conseguir al final y te daremos una solucion y
metodo de trabajo (cadena) necesitas un plan de etapas y trabajos previos, en unos u otros casos, que te evite problemas serios incluido el fiasco total.
A ver, esto es un poco despelote.
Lo que el cliente _dice_ que quiere: Digitalizar e indexar con GSA su fondo documental (creo que de contratos) en papel, y poder realizar búsquedas.
Lo que yo creo que necesitan: Una solución que aparte de indexar, categorize los documentos tal y como dices. por autor, por fecha de creación, por tipo de documento, etc...
Y efectivamente, a raíz de todo esto, pienso que la estimación inicial de tiempo no es correcta, y seguramente la herramienta que han escogido ellos, tampoco.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2007-09-14 a las 10:59 +0200, miguel gmail escribió:
Lo que el cliente _dice_ que quiere: Digitalizar e indexar con GSA su fondo documental (creo que de contratos) en papel, y poder realizar búsquedas.
Lo que yo creo que necesitan: Una solución que aparte de indexar, categorize los documentos tal y como dices. por autor, por fecha de creación, por tipo de documento, etc...
Parte contratante y contratada, asunto del contrato, monto, duración, subcontratos (por indice), substituye a, es substituido por, fechas... Es una base de datos que luego referencie al documento escaneado para los detalles.
Lo de menos es el formato gráfico en el que se guarde el documento. Lo importante es meter a mano los datos de los contratos: no creo que eso se pueda automatizar, salvo que cada contrato tenga un formulario de cabecera (en papel) que lo describa.
- -- Saludos Carlos E.R.
El Viernes, 14 de Septiembre de 2007 10:59, miguel gmail escribió:
A ver, esto es un poco despelote.
Lo que el cliente _dice_ que quiere: Digitalizar e indexar con GSA su fondo documental (creo que de contratos) en papel, y poder realizar búsquedas.
* Si desean usar GSA que sea a posteriori es decir cuando los documentos esten en una base documental aunque teniendo implementado un DMS potente que te los pone en red, GSA puede ser un añadido y ojo por que hay muchas herramientas de indexado y busqueda de codigo abierto.
Lo que yo creo que necesitan: Una solución que aparte de indexar, categorize los documentos tal y como dices. por autor, por fecha de creación, por tipo de documento, etc...
Y efectivamente, a raíz de todo esto, pienso que la estimación inicial de tiempo no es correcta, y seguramente la herramienta que han escogido ellos, tampoco.
* Bueno, en la opcion creo que mas barata, aunque muy efectiva y pocos errores o ninguno en comparacion con labores automatizadas y cerradas, la cosa deberia ir asi.
* Te bajas software de OCR ya sea para linux o windows para Arabe, Readiris creo que tiene uno especializado si no hay demos al edonkey y eliges el que mejor te vaya con el peinado, aqui uno para linux http://www.vividata.com/be_xtr_overview.html , mira las caracteristicas sobre arabe, una vez elegido el fabricante dara scanners recomendados, gran volumen, medio, etc.
* Instala DocMGR (usa postgre) o Knowledge-tree (usa Mysql), asi que mira los requerimientos de acceso de GSA si ese va a ser el final.
* Se inicia el desgrapado, clasificado, de los documentos en cajas o carpetas donde conste, destino de coleccion o subcoleccion, numerado y por orden (importante el orden con el listado, que no haya que volver a revisarlo y emparejarlo), y segun numero, se referencia, fecha, autor, confidencialidad o no, etc .... (es decir se añade un listado a cada caja/carpeta si el software de escaneado o scanner no permite esto de forma facil o casi automatico pasa de ello, tira por el listado manual), esta ultima parte es un trabajo importante por que permitira que los trabajos anteriores y posteriores puedan hacerlo meros introductores de datos (a la vista del idioma de los documentos) y debe intervenir alguien por la parte del cliente o similar.
* Se crea la estructura en el DMS de colecciones, subcolecciones, etc, usuarios, permisos de lectura, modificacion, edicion, borrado, insercion de objetos o no, etc, de acuerdo con la conveniencia de los clientes ambas herramientes tienen controles muy granulares, yo haria una subcarpeto o subcoleccion por caja/carpeta esto te permite localizar o solucionar errores de forma facil y migrar masivamente despues documentos o colecciones completas a otra estructura del arbol del DMS o una nueva es un simple click ..... Esto en una pizarra pensando un poco en cuatro o cinco dias se puede llegar perfectamente a una decision, procurando que sea lo mas granular posible pensando en su escalamiento, purga, borrado de antiguos es decir en una gestion futura y mantenimiento, que por este lado tienes una linea de ingresos.
* Hechas las pruebas de escaneado con documentos buscando el mejor resultado en mi opinion el peso es poco importante ha de ser legible, convertible y visibles luego en el DMS como listados o Iconos con el contenido visible (el propio DMS ya ofrece la descarga en diferentes formatos incluido pdf) , se almacenan o convierten en tiff, ps, u otro a tu conveniencia (parecen ser documentos legales con caracteres bien legibles) en directorio relacionado esto es muy automatico con unos scanners y una sola persona alimentando y vigilando varios scanners.
* Se finaliza una caja/carpeta se pasa a los introductores de datos (varios) que efectuan la importacion masiva desde los directorios con un mero click (el DMS les va pasan el ocr produciento uno de texto y tsearch va indexando de forma desatendida), al DMS empleando el tiempo en colocar las referencias del listado, renombrando y relacionando "hojas" que son ficheros separados pero constituyen un unico documento si los scanners o herramientas usadas no soportan esta caracteristica de forma nativa (vamos que pueden unirse a posteriori).
* Control de errores, depurado de la herramienta de indexado segun la instalacion.
* Mantenimiento de la instalacion que puede estar a vuestro cargo, los usuarios ya pueden subir los documentos que produccan en distintos formatos, word, pdf, etc, y almacenarlos de forma ordenada, asi como los documentos que entren en papel a la empresa se escanean y se importan al DMS, si la empresa no obliga a esto no se hara es muy facil guardar-como y a cascarla.
* Presenta un plan de etapas lo mas exaustivo posible, ademas del como y el por que de las cosas presente y trabajo futuro, es decir que no sea un trabajo puntual si no algo de beneficio mutuo.
* Pierde algo de tiempo en decidir el DMS puede que tal o cual caracterisca no la incorpore y necesites trabajar algo mas, pero ya sabes que en el mundo del Codigo Abierto no hay limitacion, un dinero al proyecto y te sirven en bandeja esa tal o cual caracteristica.
* PD. Puede que lo de la gestion documental "no" te lo hayan pedido pero a ti te facilitara la tarea y control y una vez visto se ha de ser muy bobo para que no vean las bondades del asunto y hay tienes la segunda parte contratante de la tercera parte.
El 13/09/07, miguel gmail escribió:
Ein? Lugar físico? Pues supongo que un sótano lúgubre y húmedo. Bueno, humedo no, aquello es el pu** desierto, y hace un calor de mil demonios.
Me refería al país. Si los documentos y los equipos que vas a utilizar para escanear están en España o Arabia Saudí :-). Como has dicho que no conoces el mercado, he descartado España como lugar de escaneo. De todas formas, aunque no conozcas el mercado puedes investigar precios, tiempos y metodologías (programas y equipos utilizados).
El formato de salida lo definiré yo... estaba pensando en pdf.
Importa tanto eso?
Hombre, importar, importar... tendrás que saber cómo quieres la salida de todo ese tocho de documentos y más aún si es para árabe y según sea su destino (consulta web, archivo, programa, base de datos...). Ah, también necesitarás un traductor de árabe para verificar el resultado del ocr.
El cliente así lo quiere. Suena raro, lo se, pero es así.
Os pueden enviar el resultado del ocr digitalizado (pdf, txt, xml...) y sólo tenéis que indexarlo.
Aprovecho: Impresionante google. Les mandé una consulta por un formulario web, y tardaron 5 minutos, de reloj, en llamarme un preventa..
Les digo que qué rapidez, y el tío me contesta que sí, que como el buscador.
Qué risas.
:-)
Saludos,
Ein? Lugar físico? Pues supongo que un sótano lúgubre y húmedo. Bueno, humedo no, aquello es el pu** desierto, y hace un calor de mil demonios.
Me refería al país. Si los documentos y los equipos que vas a utilizar para escanear están en España o Arabia Saudí :-). Como has dicho que no conoces el mercado, he descartado España como lugar de escaneo. De todas formas, aunque no conozcas el mercado puedes investigar precios, tiempos y metodologías (programas y equipos utilizados).
Es emiratos - Abu Dhabi (que todo lo queréis saber :P)
<mode offtopic on>
Si tuviese que ir a trabajar a arabia saudi, aparte de pagarme lo que no está escrito en el corán, sólo entraría en el país completamente borracho. Aquello es un país medieval.
<mode offtopic off>
El problema de externalizar el escaneado es que NO se pueden sacar los documentos del edificio donde están. De esto me acabo de enterar.
El formato de salida lo definiré yo... estaba pensando en pdf.
Importa tanto eso?
Hombre, importar, importar... tendrás que saber cómo quieres la salida de todo ese tocho de documentos y más aún si es para árabe y según sea su destino (consulta web, archivo, programa, base de datos...). Ah, también necesitarás un traductor de árabe para verificar el resultado del ocr.
Ni hablar. Los traductores son lo suficientemente malos como para fiarme de mi ingles, sobre un texto mal traducido, para deducir que el OCR se ha hecho mal.
El cliente así lo quiere. Suena raro, lo se, pero es así.
Os pueden enviar el resultado del ocr digitalizado (pdf, txt, xml...) y sólo tenéis que indexarlo.
Eso sería lo ideal! Pero ya digo, los documentos no salen del edificio de ninguna manera.
El 13/09/07, miguel gmail escribió:
Es emiratos - Abu Dhabi (que todo lo queréis saber :P)
Es que el escenario que propones es un poco "peculiar", por eso :-).
El problema de externalizar el escaneado es que NO se pueden sacar los documentos del edificio donde están. De esto me acabo de enterar.
:-O :-O :-O
Al menos sí podrás alquilar el equipo por tiempo ¿no? Al final te va a tocar sub-sub-sub contratar los servicios de digitalización de Google X-)
Ni hablar. Los traductores son lo suficientemente malos como para fiarme de mi ingles, sobre un texto mal traducido, para deducir que el OCR se ha hecho mal.
Miguel, el proceso de escaneo + ocr es, básicamente, poner el original (si son hojas sueltas se puede automatizar), escanear con el programa a resolución alta para texto -y en árabe supongo que mayor aún-, seleccionar el área de escaneo (por lo general toda la superficie), y guardar el resultado en formato editable (que para eso es ocr) como texto plano, xml, pdf o similar, no sé si djvu es editable. Si la salida es un formato imagen (jpeg) el ocr no te hace ninguna función :-?
Lo del traductor te hará falta para evaluar el contenido (la calidad) de la salida, es decir, comprobar que si en el original pone "casa" en el texto digitalizado no pone "pasa", por hace falta una persona que sepa árabe.
Los ocr caseros fallan más que una escopeta de feria (en español y en inglés, en árabe supongo que más aún :-P)
Saludos,
El Jueves, 13 de Septiembre de 2007 12:15, Camaleón escribió:
Los ocr caseros fallan más que una escopeta de feria (en español y en inglés, en árabe supongo que más aún :-P)
y tanto, en tiempos pedimos precio para uno bueno y salia por 1millon de pelas. (6 mil euros) que risa cuando algun jefe propuso hacerlo con uno de los que salen en esos baratos de 80 euros --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2007-09-13 a las 12:15 +0200, Camaleón escribió:
El 13/09/07, miguel gmail escribió:
Es emiratos - Abu Dhabi (que todo lo queréis saber :P)
Es que el escenario que propones es un poco "peculiar", por eso :-).
El problema de externalizar el escaneado es que NO se pueden sacar los documentos del edificio donde están. De esto me acabo de enterar.
:-O :-O :-O
Je. Me lo sospechaba O:-)
Además, necesita saber si están encuadernados o son hojas sueltas o soltables. Porque si están encuadernados implica usar un escaner orbital de los que comentamos el otro dia, y entonces la velocidad de escaneo baja una barbaridad.
Ni hablar. Los traductores son lo suficientemente malos como para fiarme de mi ingles, sobre un texto mal traducido, para deducir que el OCR se ha hecho mal.
Miguel, el proceso de escaneo + ocr es, básicamente, poner el original (si son hojas sueltas se puede automatizar), escanear con el programa a resolución alta para texto -y en árabe supongo que mayor aún-, seleccionar el área de escaneo (por lo general toda la superficie), y guardar el resultado en formato editable (que para eso es ocr) como texto plano, xml, pdf o similar, no sé si djvu es editable. Si la salida es un formato imagen (jpeg) el ocr no te hace ninguna función :-?
Los formatos como el DjVu guardan el texto gráficamente más una copia textual salida del OCR automático sin corrección - o con ella -, pero no es más que el texto en ASCII de otro fichero que se le ha pegado internamente. Creo que si se hace bien puedes incluso pinchar y cortar con el ratón, vamos, que el texto está posicionado. No se como se hace eso.
El PDF hace lo mismo, o muy similar.
Lo del traductor te hará falta para evaluar el contenido (la calidad) de la salida, es decir, comprobar que si en el original pone "casa" en el texto digitalizado no pone "pasa", por hace falta una persona que sepa árabe.
Más que un traductor es un documentalista del edificio que conozca los documentos y compare original con "ocerreado". No hace falta que traduzca, sino que evalue. Depende de la calidad del OCR (probarlo con documentos iguales a los originales) si hará falta mucha corrección o no. Puede que tenga que contratar una sala entera de correctores a manuense.
Los ocr caseros fallan más que una escopeta de feria (en español y en inglés, en árabe supongo que más aún :-P)
Por eso le dije que necesitaba uno de los buenos y caros.
- -- Saludos Carlos E.R.
On 12/09/2007, miguel gmail miguel.listas@gmail.com wrote:
Estimados,
qué haríais vosotros para escanear 750mil documentos en mes - mes y medio?
Tenéis idea de cual es el rendimiento de un escaner 'industrial'?
En mi trabajo, tenemos un area que se encarga de ese tema, actualmente superan el millon de imagenes por mes, y lo realizan con 8 scanners Canon 3080 (existen equipos de mucho mayor desempeño, aunque los que tenemos llevan mas de 4 años sin parar, claro que necesitan mantenimiento periodico) , el proceso lo hacen bastante rapidos, segun las consultas que les hice, me comentan que el secreto esta en el orden con que manejan los documentos.
La idea es escanear esa burrada de documentos y pasarlos por un OCR, meterlos en un servidor de ficheros, e indexarlos con google appliance.
Estaba pensando en contratrar un par de personas de perfil bajo para llevar a cabo la tarea, pero mi cuello de botella está en el número de máquinas, que no se cuantas necesito.
Para más inri, los documentos están en árabe :-/
En este caso, no pasan las imagenes por un OCR, y menos en arabe, pero si, por cada imagen, registran cierta informacion en una base de datos y las relacionan.
Saludos
JCarlos --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
En mi trabajo, tenemos un area que se encarga de ese tema, actualmente superan el millon de imagenes por mes, y lo realizan con 8 scanners Canon 3080 (existen equipos de mucho mayor desempeño, aunque los que
me apunto el modelo.
tenemos llevan mas de 4 años sin parar, claro que necesitan mantenimiento periodico) , el proceso lo hacen bastante rapidos, segun las consultas que les hice, me comentan que el secreto esta en el orden con que manejan los documentos.
Uff... tendré que pensar en el modelo de trabajo. NO quiero que revuelvan todos los papeles.
En este caso, no pasan las imagenes por un OCR, y menos en arabe, pero si, por cada imagen, registran cierta informacion en una base de datos y las relacionan.
Creo que el appliance se le puede conectar el OCR... tengo que investigarlo un poco más.
El mié, 12-09-2007 a las 17:26 +0200, miguel gmail escribió:
Estimados,
qué haríais vosotros para escanear 750mil documentos en mes - mes y medio?
Tenéis idea de cual es el rendimiento de un escaner 'industrial'?
La idea es escanear esa burrada de documentos y pasarlos por un OCR, meterlos en un servidor de ficheros, e indexarlos con google appliance.
Estaba pensando en contratrar un par de personas de perfil bajo para llevar a cabo la tarea, pero mi cuello de botella está en el número de máquinas, que no se cuantas necesito.
Para más inri, los documentos están en árabe :-/
Muchas gracias! Y perdon por el muy OT
Subcontratalo
Subcontratalo
Yo soy el subcontratado :D
El Miércoles, 12 de Septiembre de 2007 22:13, miguel gmail escribió:
Subcontratalo
Yo soy el subcontratado :D
Lo cual demuestra que la m....... (con perdon) siempre se escurre pa bajo
:)
salud y a por el toro --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Pues un poco como resumen del proyectito (alguien lo pidio):
Escaneres:
2x Canon 7080DR Estos escaneres escanean bastante rápido, y se pueden usar separadores (paginas especiales) para separar documentos entre sí.Se puede usar una raiz comun en el nombre de los ficheros generados, facilitando generar una convención de nombres. Escaneamos a 300dpi (aunque estos escaneres podían hacerlo hasta 600dpi) debido a que algunos OCR afirman que funcionan mejor a 300dpi.
OCR:
Necesitaba uno que reconociese tanto inglés como árabe. Por el inglés no hay problema, pero el arabe es otro cantar. Encontramos un sw egipcio con buenas referencias en ministerios de Emiratos:
http://www.sakhr.com/products/OCR/Default.aspx?sec=Product&item=OCR
sobre el papel ofrecía un buen número de caraterísticas: - gran soporte de árabe - procesado automático de imágenes - posibilidad de enseñarle: El ocr devuelve errores para ciertos caracteres. A veces, algunos caracteres no eran reconocidos (los indicaba con un caracter especial) y otras veces eren simplemente reconocidos erroneamente. El paquete te permite seleccionar aquellos caracteres no reconocidos o reconocidos erroneamente y enseñarle cual era el caracter adecuado en esos casos. - solo soportaba como formatos de salida rtf, art (un formato suyo) y xml. Así que tuvimos que usar rtf. - coste asumible: 1500 USD - API disponible en la version platinium.
Sobre el papel muy bien, pero cuando lo pusimos a trabajar era un autentico desastre. En los documentos en ingles tenía una precisión del 50%, en árabe, las más veces producía documentos en blanco. Estuvimos en contacto con el soporte, lo miraron ellos, lo revisaron ellos. No fueron capaces de ponerlo a funcionar. Así que lo devolvimos. No os lo recomiendo en absoluto, ni por el producto ni por el soporte post venta, son un auténtico desastre.
El otro que probamos se llama ReadIris: http://www.irislink.com/c2-532-189/OCR-Software---Product-list.aspx Sobre el papel, la lista de características no era tan completa:
- soporte de arabe e ingles - no tiene soporte para procesar imagenes automaticamente (si tuviese eso, estaría cerca de la perfección). - mayor numero de formatos de salida (doc, rtf, pdf, txt...) - coste: realmente tirado de precio: menos de 90€ !!! - no se le puede enseñar. - no hay un teléfono donde acudir, no se si quiera si hay soporte... Para tener ese coste han reducido a la mínima expresión varios departamentos como soporte y ventas.
El único problema que nos dio fue que para poder procesar ficheros en árabe es que hay que usarlo con la GUI en arabe, si no funcionaba bastante mal. En ingles tiene una precisión del 99% o más. Es realmente bueno. En árabe tiene una precisión de un 80%, que comparado con la otra basura nos pareció el paraíso musulmán. Hay que hacer un poco de edición manual, pero nada realmente preocupante. Nos hubiese gustado poder hacerlo automáticamente, pero visto lo visto, nos dimos con un canto en los dientes.
Google Search Appliance: Es una maquinita realmente curiosa. Es realmente sencilla de administrar y configurar, no es cara para la funcionalidad que ofrece. Pero nos vino con un par de bugs, que nos retrasaron considerablemente la ejecución del proyecto. No obstante tengo que decir que el soporte de Google fué impresionante. Nos ayudaron mucho una vez les contamos el problema. Por cierto, el técnico que me tocó, resultó ser español, una máquina el tío.
Pues eso es todo. No mucho, como podeís ver. Espero que le pueda ayudar a alguien.
Slds, miguel
2007/9/12 miguel gmail miguel.listas@gmail.com:
Estimados,
qué haríais vosotros para escanear 750mil documentos en mes - mes y medio?
Tenéis idea de cual es el rendimiento de un escaner 'industrial'?
La idea es escanear esa burrada de documentos y pasarlos por un OCR, meterlos en un servidor de ficheros, e indexarlos con google appliance.
Estaba pensando en contratrar un par de personas de perfil bajo para llevar a cabo la tarea, pero mi cuello de botella está en el número de máquinas, que no se cuantas necesito.
Para más inri, los documentos están en árabe :-/
Muchas gracias! Y perdon por el muy OT
-- Saludos, miguel
Los agujeros negros son lugares donde dios dividió por cero.
Black holes are places where god divided by zero.
Hace unos dias salió un articulo sobre el tema en Linux Magazine: http://www.linux-mag.com/id/5320
En el habla de un par de aplicaciones de Google:
Tesseract http://code.google.com/p/tesseract-ocr/
y Ocropus http://code.google.com/p/ocropus/ que trabaja con la aplicación anterior como base.
Has usado alguna de estas?
Luego el articulo describe el gscan2pdf, que el resultado del escaneo lo entrega en archivo pdf: http://gscan2pdf.sourceforge.net
Aparece otro que segun dice el articulo tiene resultados similares al tesseract: VueScan (http://www.hamrick.com).
Despues otros ya mas o menos conocidos:
GNU Ocrad (http://www.gnu.org/software/ocrad/ocrad.html)
GOCR (http://jocr.sourceforge.net)
Otro proyecto discontinuado: Clara OCR http://www.geocities.com/claraocr/
Salu2
El 12/03/08, miguel gmail miguel.listas@gmail.com escribió:
Pues un poco como resumen del proyectito (alguien lo pidio):
Escaneres:
2x Canon 7080DR Estos escaneres escanean bastante rápido, y se pueden usar separadores (paginas especiales) para separar documentos entre sí.Se puede usar una raiz comun en el nombre de los ficheros generados, facilitando generar una convención de nombres. Escaneamos a 300dpi (aunque estos escaneres podían hacerlo hasta 600dpi) debido a que algunos OCR afirman que funcionan mejor a 300dpi.
OCR:
Necesitaba uno que reconociese tanto inglés como árabe. Por el inglés no hay problema, pero el arabe es otro cantar. Encontramos un sw egipcio con buenas referencias en ministerios de Emiratos:
http://www.sakhr.com/products/OCR/Default.aspx?sec=Product&item=OCR
sobre el papel ofrecía un buen número de caraterísticas:
- gran soporte de árabe
- procesado automático de imágenes
- posibilidad de enseñarle: El ocr devuelve errores para ciertos
caracteres. A veces, algunos caracteres no eran reconocidos (los indicaba con un caracter especial) y otras veces eren simplemente reconocidos erroneamente. El paquete te permite seleccionar aquellos caracteres no reconocidos o reconocidos erroneamente y enseñarle cual era el caracter adecuado en esos casos.
- solo soportaba como formatos de salida rtf, art (un formato suyo) y
xml. Así que tuvimos que usar rtf.
- coste asumible: 1500 USD
- API disponible en la version platinium.
Sobre el papel muy bien, pero cuando lo pusimos a trabajar era un autentico desastre. En los documentos en ingles tenía una precisión del 50%, en árabe, las más veces producía documentos en blanco. Estuvimos en contacto con el soporte, lo miraron ellos, lo revisaron ellos. No fueron capaces de ponerlo a funcionar. Así que lo devolvimos. No os lo recomiendo en absoluto, ni por el producto ni por el soporte post venta, son un auténtico desastre.
El otro que probamos se llama ReadIris: http://www.irislink.com/c2-532-189/OCR-Software---Product-list.aspx Sobre el papel, la lista de características no era tan completa:
- soporte de arabe e ingles
- no tiene soporte para procesar imagenes automaticamente (si tuviese
eso, estaría cerca de la perfección).
- mayor numero de formatos de salida (doc, rtf, pdf, txt...)
- coste: realmente tirado de precio: menos de 90€ !!!
- no se le puede enseñar.
- no hay un teléfono donde acudir, no se si quiera si hay soporte...
Para tener ese coste han reducido a la mínima expresión varios departamentos como soporte y ventas.
El único problema que nos dio fue que para poder procesar ficheros en árabe es que hay que usarlo con la GUI en arabe, si no funcionaba bastante mal. En ingles tiene una precisión del 99% o más. Es realmente bueno. En árabe tiene una precisión de un 80%, que comparado con la otra basura nos pareció el paraíso musulmán. Hay que hacer un poco de edición manual, pero nada realmente preocupante. Nos hubiese gustado poder hacerlo automáticamente, pero visto lo visto, nos dimos con un canto en los dientes.
Google Search Appliance: Es una maquinita realmente curiosa. Es realmente sencilla de administrar y configurar, no es cara para la funcionalidad que ofrece. Pero nos vino con un par de bugs, que nos retrasaron considerablemente la ejecución del proyecto. No obstante tengo que decir que el soporte de Google fué impresionante. Nos ayudaron mucho una vez les contamos el problema. Por cierto, el técnico que me tocó, resultó ser español, una máquina el tío.
Pues eso es todo. No mucho, como podeís ver. Espero que le pueda ayudar a alguien.
Slds, miguel
2007/9/12 miguel gmail miguel.listas@gmail.com:
Estimados,
qué haríais vosotros para escanear 750mil documentos en mes - mes y medio?
Tenéis idea de cual es el rendimiento de un escaner 'industrial'?
La idea es escanear esa burrada de documentos y pasarlos por un OCR, meterlos en un servidor de ficheros, e indexarlos con google appliance.
Estaba pensando en contratrar un par de personas de perfil bajo para llevar a cabo la tarea, pero mi cuello de botella está en el número de máquinas, que no se cuantas necesito.
Para más inri, los documentos están en árabe :-/
Muchas gracias! Y perdon por el muy OT
-- Saludos, miguel
Los agujeros negros son lugares donde dios dividió por cero.
Black holes are places where god divided by zero.
-- Saludos, miguel
Los agujeros negros son lugares donde dios dividió por cero.
Black holes are places where god divided by zero.
Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
--------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2008/3/12 Juan Erbes jerbes@gmail.com:
Hace unos dias salió un articulo sobre el tema en Linux Magazine: http://www.linux-mag.com/id/5320
En el habla de un par de aplicaciones de Google:
Tesseract http://code.google.com/p/tesseract-ocr/
Dice que era uno de los OCR buenos en... 1995!!! Además, no soporta árabe.
y Ocropus http://code.google.com/p/ocropus/ que trabaja con la aplicación anterior como base.
Están preparándose para sacar la versión... alpha!!
Has usado alguna de estas?
Por 90€ que nos costó la otra no, no hemos probado estas. Además, están están los motivos que he indicado antes.
Luego el articulo describe el gscan2pdf, que el resultado del escaneo lo entrega en archivo pdf: http://gscan2pdf.sourceforge.net
Aparece otro que segun dice el articulo tiene resultados similares al tesseract: VueScan (http://www.hamrick.com).
Despues otros ya mas o menos conocidos:
GNU Ocrad (http://www.gnu.org/software/ocrad/ocrad.html)
GOCR (http://jocr.sourceforge.net)
Por 90€ no nos complicamos la vida en este caso...
El 12/03/08, miguel gmail miguel.listas@gmail.com escribió:
2008/3/12 Juan Erbes jerbes@gmail.com:
Hace unos dias salió un articulo sobre el tema en Linux Magazine: http://www.linux-mag.com/id/5320
En el habla de un par de aplicaciones de Google:
Tesseract http://code.google.com/p/tesseract-ocr/
Dice que era uno de los OCR buenos en... 1995!!! Además, no soporta árabe.
y Ocropus http://code.google.com/p/ocropus/ que trabaja con la aplicación anterior como base.
Están preparándose para sacar la versión... alpha!!
Has usado alguna de estas?
Por 90€ que nos costó la otra no, no hemos probado estas. Además, están están los motivos que he indicado antes.
Luego el articulo describe el gscan2pdf, que el resultado del escaneo lo entrega en archivo pdf: http://gscan2pdf.sourceforge.net
Aparece otro que segun dice el articulo tiene resultados similares al tesseract: VueScan (http://www.hamrick.com).
Despues otros ya mas o menos conocidos:
GNU Ocrad (http://www.gnu.org/software/ocrad/ocrad.html)
GOCR (http://jocr.sourceforge.net)
Por 90€ no nos complicamos la vida en este caso...
Estube mirando las caracteristicas de esas aplicaciones, y no he visto que funcionen bajo Opensuse. Bajo que sistema operativo funcionan?
Salu2 --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Estube mirando las caracteristicas de esas aplicaciones, y no he visto que funcionen bajo Opensuse. Bajo que sistema operativo funcionan?
windows xp
(por favor, no empecemos un debate sobre lo maloso que es el sw privativo, y si no tiene nada que ver con la tematica de la lista)
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2008-03-13 a las 12:43 +0100, miguel gmail escribió:
Estube mirando las caracteristicas de esas aplicaciones, y no he visto que funcionen bajo Opensuse. Bajo que sistema operativo funcionan?
windows xp
(por favor, no empecemos un debate sobre lo maloso que es el sw privativo, y si no tiene nada que ver con la tematica de la lista)
No problem.
Pero coincide con mi idea de que en linux no hay buenos OCRs. Los que he probado son peores que el que venía con mi escaner para windows. Ojalá me equivoque.
- -- Saludos Carlos E.R.
El 13/03/08, Carlos E. R. robin.listas@telefonica.net escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Pero coincide con mi idea de que en linux no hay buenos OCRs. Los que he probado son peores que el que venía con mi escaner para windows. Ojalá me equivoque.
Google contribuye con un proyecto para linux
http://code.google.com/p/ocropus/
Saludos
Roberto --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
El 2008-03-13 a las 15:42 +0100, Roberto P escribió:
Pero coincide con mi idea de que en linux no hay buenos OCRs. Los que he probado son peores que el que venía con mi escaner para windows. Ojalá me equivoque.
Google contribuye con un proyecto para linux
Que según Miguel es alpha todavía. No es usable.
- -- Saludos Carlos E.R.
El 13/03/08, Carlos E. R. robin.listas@telefonica.net escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Google contribuye con un proyecto para linux
Que según Miguel es alpha todavía. No es usable.
Bueno, pero se espera que antes de fin de año se tenga una version final.
Saludos,
Roberto --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
2008/3/13, Roberto P pinroberto@googlemail.com:
El 13/03/08, Carlos E. R. robin.listas@telefonica.net escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Pero coincide con mi idea de que en linux no hay buenos OCRs. Los que he probado son peores que el que venía con mi escaner para windows. Ojalá me equivoque.
Google contribuye con un proyecto para linux
Gracias por la noticia!
Hace mas de un dia yo escribí en este hilo:
"En el habla de un par de aplicaciones de Google:
Tesseract http://code.google.com/p/tesseract-ocr/
y Ocropus http://code.google.com/p/ocropus/ que trabaja con la aplicación anterior como base."
Por otro lado, no veo que sentido tiene abrir un hilo en la lista sobre un trabajo para el cual no se usa software de codigo abierto, y menos de Opensuse.
Salu2 --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID: alpine.LSU.1.00.0803131646070.6321@nimrodel.valinor
El 2008-03-13 a las 13:27 -0200, Juan Erbes escribió:
Por otro lado, no veo que sentido tiene abrir un hilo en la lista sobre un trabajo para el cual no se usa software de codigo abierto, y menos de Opensuse.
Porque no ha abierto un hilo sobre eso.
El correo original fué en 2007-09-12, y preguntaba sobre como escanear un montón de documentos en árabe. Al final de la discusión le pedimos que nos contara como quedara la cosa cuando lo solucionara.
Y eso ha hecho.
No le busques tres pies al gato.
- -- Saludos Carlos E.R.
Por otro lado, no veo que sentido tiene abrir un hilo en la lista sobre un trabajo para el cual no se usa software de codigo abierto, y menos de Opensuse.
Pues vale. Me parece estupendo.
Me pregunto por qué no planteamos a opensuse que te haga moderador de la lista.
2008/3/13, miguel gmail miguel.listas@gmail.com:
Por otro lado, no veo que sentido tiene abrir un hilo en la lista sobre un trabajo para el cual no se usa software de codigo abierto, y menos de Opensuse.
Pues vale. Me parece estupendo.
Me pregunto por qué no planteamos a opensuse que te haga moderador de la lista.
Demos vuelta las cosas:
Yo hace un tiempo plantee el tema de la edicion de video en formato AVCHD. Si yo habriría un nuevo hilo llamado "edicion de video en formato AVCHD", y detallo que la solución es utilizar el Sony Vegas 8.0a en adelante para esa tarea (que no viene para Linux), a vos te parece que escribir eso sería algo coherente dentro de una lista sobre Linux?
Salu2 --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Demos vuelta las cosas:
Yo hace un tiempo plantee el tema de la edicion de video en formato AVCHD. Si yo habriría un nuevo hilo llamado "edicion de video en formato AVCHD", y detallo que la solución es utilizar el Sony Vegas 8.0a en adelante para esa tarea (que no viene para Linux), a vos te parece que escribir eso sería algo coherente dentro de una lista sobre Linux?
En esta lista sí, sin duda. Hemos hablado de cosas mucho más OT que esta. Si lo fueses a hacer te diría que es mala idea porque en esa lista son pelín más estrictos con la temática.
En esta lista tenemos bastante buen rollo, y los OT, siempre que sean presentados de forma adecuada, se han aceptado desde siempre. O al menos, desde que yo pertenezco a la lista, hace unos 5 años y pico.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Content-ID: alpine.LSU.1.00.0803131957510.6321@nimrodel.valinor
El 2008-03-13 a las 14:04 -0200, Juan Erbes escribió:
Demos vuelta las cosas:
Yo hace un tiempo plantee el tema de la edicion de video en formato AVCHD. Si yo habriría un nuevo hilo llamado "edicion de video en formato AVCHD", y detallo que la solución es utilizar el Sony Vegas 8.0a en adelante para esa tarea (que no viene para Linux), a vos te parece que escribir eso sería algo coherente dentro de una lista sobre Linux?
Pues claro que si.
Si hablas de que estás intentando hacer lo que sea en o con linux, se discute el tema, y al fina se ve que no hay tu tia y tienes que hacerlo con tal otra cosa, que no es linux, pues yo considero que es bueno saberlo.
- -- Saludos Carlos E.R.
2008/3/13, Juan Erbes jerbes@gmail.com:
Gracias por la noticia!
Hace mas de un dia yo escribí en este hilo:
Si, lo acepto no he leido todo el hilo...mea culpa.
Por otro lado, no veo que sentido tiene abrir un hilo en la lista sobre un trabajo para el cual no se usa software de codigo abierto, y menos de Opensuse.
El colistero utilizó correctamente las netiquetes y colocó un OT en el asunto. Creo que cada quien es libre de leer o no este hilo.
Creo que en esta lista se encuentran muchas personas que tienen que trabajar con software, muchas veces propietario, que buscan soluciones de software libre y que, como en este caso, no lo encuentran. De algo tenemos que comer.
Saludos,
Roberto --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Juan Erbes escribió:
2008/3/13, Roberto P pinroberto@googlemail.com:
El 13/03/08, Carlos E. R. robin.listas@telefonica.net escribió:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Pero coincide con mi idea de que en linux no hay buenos OCRs. Los que he probado son peores que el que venía con mi escaner para windows. Ojalá me equivoque.
Google contribuye con un proyecto para linux
Gracias por la noticia!
Hace mas de un dia yo escribí en este hilo:
"En el habla de un par de aplicaciones de Google:
Tesseract http://code.google.com/p/tesseract-ocr/
y Ocropus http://code.google.com/p/ocropus/ que trabaja con la aplicación anterior como base."
Por otro lado, no veo que sentido tiene abrir un hilo en la lista sobre un trabajo para el cual no se usa software de codigo abierto, y menos de Opensuse.
Salu2
Es un tema viejo que se trato en la lista e intentó hacer con linux. Como no se quedo nada en concreto le solicitamos que cuando acabase el proyecto nos dijese como habia ido. Para una vez que alguien se molesta en decir como acabo todo lo medio regañan. --------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Hola Miguel
Yo he utilizado hace unos cuantos años el programa Adobe Acrobat para escanear y reconocer el texto. El que utilizaba era el 3.0, hoy van por el 8.1, por lo que es posible que soporten el Arabe y hasta en una de esas tienes soporte para Linux. Con resoluciones de 8dpi tenia muchos errores, pero con 12 o 14 si el texto era claro era superior al 95%. Si todavìa tienen mucho trabajo, le escriben a la empresa y seguro que te contestaran.
Alfredo
miguel gmail escribió:
Estube mirando las caracteristicas de esas aplicaciones, y no he visto que funcionen bajo Opensuse. Bajo que sistema operativo funcionan?
windows xp
(por favor, no empecemos un debate sobre lo maloso que es el sw privativo, y si no tiene nada que ver con la tematica de la lista)
--------------------------------------------------------------------- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org
Yo he utilizado hace unos cuantos años el programa Adobe Acrobat para escanear y reconocer el texto. El que utilizaba era el 3.0, hoy van por el 8.1, por lo que es posible que soporten el Arabe y hasta en una de esas tienes soporte para Linux. Con resoluciones de 8dpi tenia muchos errores, pero con 12 o 14 si el texto era claro era superior al 95%. Si todavìa tienen mucho trabajo, le escriben a la empresa y seguro que te contestaran.
Creo recordar (o sea, me puedo equivocar), que Adobe no soportaba árabe.
-
admin-listas -
alfredodelaiti＠netscape.net -
Camaleón -
Carlos E. R. -
francisco F.
-
jose maria -
Josep M. Queralt -
Juan Carlos Bravo Celis -
Juan Erbes -
lluis -
miguel gmail -
Pedro Marquina -
Roberto P -
Victor Hugo dos Santos