Portada
mis comunidades
otras secciones
#9:
#5 Debieras actualizarte un poco. Hace ya mucho que cuando se habla de estos programas y se alude a los bits se habla de bits por canal.
Pista: cualquier manipulación en 8 bits por canal se refleja en el histograma (deja huecos). En una foto editada a 16 bits por canal y luego convertida a 8 bits, no hay rastros en el histograma. Y tu foto es en gran medida el histograma (hay excepciones, pero no todo pueden ser excepciones).
Yo particularmente no conozco ni contrataría a nadie medianamente profesional en fotografía digital que no edite en 16 bits por canal.
Pista: cualquier manipulación en 8 bits por canal se refleja en el histograma (deja huecos). En una foto editada a 16 bits por canal y luego convertida a 8 bits, no hay rastros en el histograma. Y tu foto es en gran medida el histograma (hay excepciones, pero no todo pueden ser excepciones).
Yo particularmente no conozco ni contrataría a nadie medianamente profesional en fotografía digital que no edite en 16 bits por canal.
#5:
Mientras que GIMP solo permite imágenes RGB con 8bits de profundidad Krita permite imágenes de todo tipo, RGB, CMYK, Lab, etc... a cualquier profundad de color, 8, 16 o 32bits...
Eso es rotundamente falso. Gimp trabaja perfectamente con imágenes a 24 bit de color. Y ojo: no existen los 32 bit de color, son 24 bit de color + 8 de canal alfa.
Y no digo que ese Krita sea malo. Pero no me parece bien ensalzar las virtudes de un programa diciendo falsedades sobre otros.
Eso es rotundamente falso. Gimp trabaja perfectamente con imágenes a 24 bit de color. Y ojo: no existen los 32 bit de color, son 24 bit de color + 8 de canal alfa.
Y no digo que ese Krita sea malo. Pero no me parece bien ensalzar las virtudes de un programa diciendo falsedades sobre otros.
#41:
#35: Para que veas... mucho decir "lo que debería ser GIMP".
Pues yo digo lo contrario, ojalá GIMP jamás sea como "el kriter", porque GIMP tiene muchas ventajas que "el kriter" no tiene, como ser multiplataforma.
Por cierto, que funcione en Windows no solo es bueno para los que usan Windows, también es útil para los que usan ReactOS, que no olvidemos que es un sistema operativo tipo Windows, pero libre y de código abierto.
#33: Eso no es aportar información, es pwnear al bloguero que escribió esa bazofia.
#38: El problema de GIMP es que buena parte del trabajo no se ve a simple vista. GEGL es una biblioteca que para empezar, no es solo para GIMP (puedes usarla en cualquier programa, como por ejemplo, en LibreOffice, o incluso en juegos). Ese trabajo tan útil no saldrá a la luz hasta que lancen la versión de GIMP 2.10 (ahora están intentando lanzar la 2.08).
Cuando lancen esa versión, todo lo bueno de GEGL aparecerá de golpe, por eso parece que en GIMP no se hacen cambios. Ahora mismo lo más que se usa GEGL es en las herramientas de color... pero es que es un uso mínimo de la biblioteca. La biblioteca esa está pensada para edición no destructiva de imágenes.
Pero como dije, es mucho trabajo, y si nadie echa una mano... pues eso, que seguirá siendo mucho trabajo.
Pues yo digo lo contrario, ojalá GIMP jamás sea como "el kriter", porque GIMP tiene muchas ventajas que "el kriter" no tiene, como ser multiplataforma.
Por cierto, que funcione en Windows no solo es bueno para los que usan Windows, también es útil para los que usan ReactOS, que no olvidemos que es un sistema operativo tipo Windows, pero libre y de código abierto.
#33: Eso no es aportar información, es pwnear al bloguero que escribió esa bazofia.
#38: El problema de GIMP es que buena parte del trabajo no se ve a simple vista. GEGL es una biblioteca que para empezar, no es solo para GIMP (puedes usarla en cualquier programa, como por ejemplo, en LibreOffice, o incluso en juegos). Ese trabajo tan útil no saldrá a la luz hasta que lancen la versión de GIMP 2.10 (ahora están intentando lanzar la 2.08).
Cuando lancen esa versión, todo lo bueno de GEGL aparecerá de golpe, por eso parece que en GIMP no se hacen cambios. Ahora mismo lo más que se usa GEGL es en las herramientas de color... pero es que es un uso mínimo de la biblioteca. La biblioteca esa está pensada para edición no destructiva de imágenes.
Pero como dije, es mucho trabajo, y si nadie echa una mano... pues eso, que seguirá siendo mucho trabajo.
#17:
Me parecen un poco injustos los comentarios que hace el articulista. GIMP es un excelente programa, y aunque es cierto que hace tiempo que no añade nuevas funcionalidades, según tengo entendido el problema es que se ha ido quedando sin desarrolladores, y ahora mismo tiene a muy pocos trabajando en el proyecto.
En cuanto a Kirita, quizá ahora sea una buena alternativa, pero eso no quiere decir que lo fuera en el pasado, motivo por el que las distros posiblemente no le daban tanta importancia como a GIMP, y esto no se le ha ocurrido al redactor antes de lanzarse a la piscina de esa manera y hablar gratuitamente de talibanismo.
En cuanto a Kirita, quizá ahora sea una buena alternativa, pero eso no quiere decir que lo fuera en el pasado, motivo por el que las distros posiblemente no le daban tanta importancia como a GIMP, y esto no se le ha ocurrido al redactor antes de lanzarse a la piscina de esa manera y hablar gratuitamente de talibanismo.
#29:
#5 Pffff la que acabas de soltar y encima la gente te vota positivo, con dos huevos 
.
Yo hago retoque de imágenes de infografía y siempre trabajo en 32 bits de punto flotante, esto quiere decir 32 bits POR CANAL osea 128 en total, los formatos más comunes para esto a parte de psd si usas Photoshop son .exr y .hdr.
.Yo hago retoque de imágenes de infografía y siempre trabajo en 32 bits de punto flotante, esto quiere decir 32 bits POR CANAL osea 128 en total, los formatos más comunes para esto a parte de psd si usas Photoshop son .exr y .hdr.
#36:
#31 Por cierto, GIMP está programado en C, y "el kriter" en C++. Adivinad cuál es más óptimo para procesar imágenes. ¿Qué coj...? C y C++ tienen un rendimiento realmente muy parecido, además por el uso de librerías y manejo del lenguaje todos (si, todos) los grandes monstruos del diseño están en C++ vease desde Photoshop, a Nuke, a cualquiera de Autodesk.
#68:
#52 sé lo que quieres decir, pero no es cierto en términos absolutos. C es un subconjunto de C++ hoy en día, lo que quiere decir que el compilador es el mismo, con funciones deshabilitadas cuando compila en C. Si tu haces un for, un while, lo que sea, en C y C++, el código de máquina resultante va a ser idéntico porque de hecho, lo compila el mismo compilador sea C o C++.
Por tanto, un programa en C++ va a ser exactamente igual de rápido que un programa en C que haga lo mismo. Pero (y ahí es donde tienes tu parte de razón) la estructura orientada a objetos de C++ tiende a una programación redundante que acaba realizando más proceso del necesario, mientras que en C se tiende a economizar, el mismo fenómeno que ocurre en ASM. Pero esto es un problema del programador y de diseño y no del lenguaje en sí mismo. Nada te impide en un programa C++ hacer funciones críticas en ASM incluso si lo deseas. Y por supuesto, un buen programador puede hacer código más eficiente en C++ que un mal programador en ASM. Saludos.
Por tanto, un programa en C++ va a ser exactamente igual de rápido que un programa en C que haga lo mismo. Pero (y ahí es donde tienes tu parte de razón) la estructura orientada a objetos de C++ tiende a una programación redundante que acaba realizando más proceso del necesario, mientras que en C se tiende a economizar, el mismo fenómeno que ocurre en ASM. Pero esto es un problema del programador y de diseño y no del lenguaje en sí mismo. Nada te impide en un programa C++ hacer funciones críticas en ASM incluso si lo deseas. Y por supuesto, un buen programador puede hacer código más eficiente en C++ que un mal programador en ASM. Saludos.
#22:
Después de ver el comportamiento del autor al discutir con el anónimo constructivo, la verdad es que lamento haber perdido mi tiempo leyendo esto. Os hago un resumen: GIMP no le gusta, Krita le gusta más, y el mantra "si es open source es bueno y no tiene fallos" le parece mal. Sacadlo de ahí y se queda sin argumentos.
#62:
No estoy de acuerdo para nada con eso. Precisamente una de las pocas cosas que no me gusta (de repeler) de KDE es el pack de programas de imagen (krita y karbon), incompletos y más toscos de utilizar que gimp e inkscape. Un ejemplo es el tema de las herramientas, que lee de forma arbitraria el autor del artículo: en gimp seleccionas la herramienta y la utilizas. En krita debes seleccionar la brocha y decir qué tipo acción quieres que haga antes de utilizarla (clonar, borrar, pintar...), algo super intuitivo y superrápido cuando se trata de ilustrar [/sarcasmo].
Para ilustración trae las mismas muchas/pocas opciones que trae gimp. Lo mismo para retoque fotográfico, donde Krita se queda o bien se queda corto, por la falta de herramientas, o bien es demasiado complejo a la hora de aplicar los efectos con el sistema de nodos (da más juego, pero es más complejo con diferencia).
Las brochas te las puedes crear tú perfectamente e incluso modificar las que tienes (en ambos programas).
Habla de que es demasiado complejo para edición amateur pero no para de hacer referencias a Photoshop (programa de retoque amateur donde los haya).
Dice que utiliza photoshop, que no ha utilizado krita más que dos o tres veces. Supongo que Gimp lo habrá usado igual de bien. No obstante no duda en configurar la interfaz como Gimp, algo que por supuesto no se puede hacer con Gimp porque la interfaz de Gimp es inconfigurable [/sarcasmo]. Eso sí, siempre con la ventana flotante.
A ese bloguero se le ha ido totalmente la pinza. Ves que alucina con cosas que tiene krita... ¡pero que también están en Gimp! sin embargo en krita mola.
La única ventaja real sobre gimp es el tema de los bits de la imagen, cosa a tener en cuenta para el que realmente lo necesite. Fuera de ahí es más cuestión de costumbres que otra cosa, porque vienen a hacer prácticamente lo mismo (pero no me gusta cómo se hacen, de ahí mi segunda frase).
Por otro lado... si no le gusta gimp que use krita, que para eso hay dos programas leñe.
Para ilustración trae las mismas muchas/pocas opciones que trae gimp. Lo mismo para retoque fotográfico, donde Krita se queda o bien se queda corto, por la falta de herramientas, o bien es demasiado complejo a la hora de aplicar los efectos con el sistema de nodos (da más juego, pero es más complejo con diferencia).
Las brochas te las puedes crear tú perfectamente e incluso modificar las que tienes (en ambos programas).
Habla de que es demasiado complejo para edición amateur pero no para de hacer referencias a Photoshop (programa de retoque amateur donde los haya).
Dice que utiliza photoshop, que no ha utilizado krita más que dos o tres veces. Supongo que Gimp lo habrá usado igual de bien. No obstante no duda en configurar la interfaz como Gimp, algo que por supuesto no se puede hacer con Gimp porque la interfaz de Gimp es inconfigurable [/sarcasmo]. Eso sí, siempre con la ventana flotante.
A ese bloguero se le ha ido totalmente la pinza. Ves que alucina con cosas que tiene krita... ¡pero que también están en Gimp! sin embargo en krita mola.
La única ventaja real sobre gimp es el tema de los bits de la imagen, cosa a tener en cuenta para el que realmente lo necesite. Fuera de ahí es más cuestión de costumbres que otra cosa, porque vienen a hacer prácticamente lo mismo (pero no me gusta cómo se hacen, de ahí mi segunda frase).
Por otro lado... si no le gusta gimp que use krita, que para eso hay dos programas leñe.
#47:
#31 Adivinad cuál es más óptimo para procesar imágenes.
Yo símplemente aclarar que nada es "más óptimo", "óptimo" es lo mejor (superlativo), y por tanto habria que decir "cual de los dos es el óptimo" o "cual de los dos es mejor". Por ejemplo: "Un buen flame requiere de la escritura óptima".
De lo otro, solo hago cuatro retoques, así que me vale cualquier programilla.
Yo símplemente aclarar que nada es "más óptimo", "óptimo" es lo mejor (superlativo), y por tanto habria que decir "cual de los dos es el óptimo" o "cual de los dos es mejor". Por ejemplo: "Un buen flame requiere de la escritura óptima".
De lo otro, solo hago cuatro retoques, así que me vale cualquier programilla.
Comentarios
Mientras que GIMP solo permite imágenes RGB con 8bits de profundidad Krita permite imágenes de todo tipo, RGB, CMYK, Lab, etc... a cualquier profundad de color, 8, 16 o 32bits...
Eso es rotundamente falso. Gimp trabaja perfectamente con imágenes a 24 bit de color. Y ojo: no existen los 32 bit de color, son 24 bit de color + 8 de canal alfa.
Y no digo que ese Krita sea malo. Pero no me parece bien ensalzar las virtudes de un programa diciendo falsedades sobre otros.
#5 Si GIMP no tiene soporte para CMYK, en mi trabajo tendré que seguir usando Macintosh+CreativeSuite, lo que no entiendo es por qué GIMP o su equipo dijo hace años que no incluirían CMYK nativamente por tema de patentes, y ahora aparece en Krita.
#7 gimp si tiene soporte para CMYK. No de forma nativa pero si que lo soporta. Ahora bien, linux lo que necesita urgentemente es un buen curro en el tratamiento de la gestión del color. Es de las pocas cosas que le falta a linux para poder trabajar con impresoras, scaneres y todo lo relacionado en AAGG.
#10 colord
http://www.freedesktop.org/software/colord/
#12 #18 si, eso es muy bonito yo lo tengo en mi distro. Pero a la hora de la verdad con que trabajas ? con el gimp ? no hay programas que utilicen esas herramientas, como dice #18. De momento eso o el simple tratamiento de perfiles icc es casi anecdótico en linux.
#10 linux tiene little CMS (http://www.littlecms.com) distribuida bajo MIT y argyll (http://www.argyllcms.com) distribuida bajo GPL. Las dos no tienen nada que envidiar a ACE de Adobe y son bastante superiores a ColorSync o ICM. Otro tema es que hay pocas aplicaciones suficientemente serias como para soportar gestion de color, pero las herramientas estan ahí.
#5 Se refiere a 8 bits por canal, pero lo ha explicado mal. Si lo prefieres, GIMP puede trabajar en 32 bits (RGBA) pero no en 64 o en 48 (RGB)
#6 -> #5
#5 Debieras actualizarte un poco. Hace ya mucho que cuando se habla de estos programas y se alude a los bits se habla de bits por canal.
Pista: cualquier manipulación en 8 bits por canal se refleja en el histograma (deja huecos). En una foto editada a 16 bits por canal y luego convertida a 8 bits, no hay rastros en el histograma. Y tu foto es en gran medida el histograma (hay excepciones, pero no todo pueden ser excepciones).
Yo particularmente no conozco ni contrataría a nadie medianamente profesional en fotografía digital que no edite en 16 bits por canal.
#5 Pffff la que acabas de soltar y encima la gente te vota positivo, con dos huevos
.
Yo hago retoque de imágenes de infografía y siempre trabajo en 32 bits de punto flotante, esto quiere decir 32 bits POR CANAL osea 128 en total, los formatos más comunes para esto a parte de psd si usas Photoshop son .exr y .hdr.
#26 Me gustaría ver si la gente tuviera que pagar lo que vale el Photoshop cuanta gente pasaba a necesitarlo realmente ...
#28 Ese es otro tema
.
#28 Photoshop no es demasiado caro para lo que el uso que se le puede llegar a dar (y los beneficios que puedes obtener gracias a el si te dedicas a algo del mundillo). Aparte, hace un par de años, no se si aún es igual, podías comprarte 5 licencias de photoshop (o algo asi) por unos 400€ (aprox). Si lo compras entre varios no es nada del otro mundo.
#57 Para uso profesional obviamente no, pero mi comentario era en referencia a todos los usuarios no profesionales que lo usan.
#57 En la página de Adobe el precio de una licencia de CS5 -programa completo no actualización- es de 1.001,82€ (Versión física. Si lo descargas vale 1.027,29€ ¿?)
Uhmmm, creo que para cualquiera que no se dedique a ello de manera profesional no le compensa.
#28 Pues no se que decirte. No creo que a un profesional le resulte cara una licencia para todo lo que ofrece y cómo lo ofrece. Ante estos programas que llevan toda la vida de Dios siendo el mejor yo me quito el sombrero.
Otra cosa es que sea necesario para correcciones típicas de nuestras fotos.
Me parecen un poco injustos los comentarios que hace el articulista. GIMP es un excelente programa, y aunque es cierto que hace tiempo que no añade nuevas funcionalidades, según tengo entendido el problema es que se ha ido quedando sin desarrolladores, y ahora mismo tiene a muy pocos trabajando en el proyecto.
En cuanto a Kirita, quizá ahora sea una buena alternativa, pero eso no quiere decir que lo fuera en el pasado, motivo por el que las distros posiblemente no le daban tanta importancia como a GIMP, y esto no se le ha ocurrido al redactor antes de lanzarse a la piscina de esa manera y hablar gratuitamente de talibanismo.
#17 El tema es que todos vivimos en el presente, y necesitamos algo que funcione en el presente. Tampoco veo que tiene que ver la historia de un programa para valorar su desempeño actual. Y aunque muchas cosas sean opinables y tengan sus circunstancias, siguen siendo un problema.
#17 Siempre se han montado unos flames enormes entre GIMP y Photoshop... y aunque PS era y es superior, siempre salía la típica frase de "la mayoría de la gente no necesita ni el 90% de GIMP, con lo que hay, les sobra". Se le defendía por ser libre, no por otra cosa.
Después de ver el comportamiento del autor al discutir con el anónimo constructivo, la verdad es que lamento haber perdido mi tiempo leyendo esto. Os hago un resumen: GIMP no le gusta, Krita le gusta más, y el mantra "si es open source es bueno y no tiene fallos" le parece mal. Sacadlo de ahí y se queda sin argumentos.
Anda krita de ahí...
Krita el remplazo de Gimp
Krita el remplazo de Gimp
koffice.orgy
Comparación: the GIMP Vs Krita
Comparación: the GIMP Vs Krita
linux.com#2 Y bien? (goto #14 )
Luego... Para decir lo bueno que es Krita no hace falta poner a parir gimp (y con mentiras como galaxias)
Además... para tan bueno que es Krita... me falta el script-fu (y mira que lo busco y lo busco... y no lo encuentro, tan intuitivo que és)
#34 Además... para tan bueno que es Krita... me falta el script-fu
Y me auto contesto: Y el pyhon-fu, y el batch y... bah, paso...
Sí, sí! El Krita le pega mil patadaaaas!
#39 Una palabra: Kross
http://en.wikipedia.org/wiki/Kross_(KDE)
#100 Sigue sin ser tan flexible. Gimp permite perl y phyton como scripting NATIVO (y lo siento... eso mola)
Algo parecido sucede con los servidores Web. Casi todo el mundo utiliza Apache pero Cherokee (que además está hecho por un madrileño) le dá mil y un vueltas: http://www.cherokee-project.com/
#27 Pues ya podía tener la web y la documentación también en castellano. Luego nos quejaremos de que el inglés se come al castellano.
#66: Exacto, un fallo de GIMP es que si pulsas TAB, se van las ventanas sin dejar rastro. Al menos podría tener una entrada en el menú "ventana" que permitiera recuperar esas ventanas que se van al pulsar TAB.
De todas formas, si presionas TAB y desaparecen las ventanas, vuelve a pulsar esa tecla, y reaparecen.
#72: Pues para mi GIMP no es tan incómodo de usar como se dice. Hay cosas que mejoraría, por supuesto, pero de ahí a ponerle tan mal... yo cuando probé "el kriter" no me encontré a gusto ni de lejos.
#67: Cierto, hay programadores que se creen que hacer el programa más universal es prescindir de usar su idioma nativo y poner todo en inglés y solo en inglés.
pues pinta bien, yo también veo a Gimp (lo uso a menudo pero para pequeños retoques) bastante desfasado y falla más que una pistola de feria
Por cierto...
"Hay gente que piensa que algo por el simple hecho de llevar el sello de Software Libre debe ser mejor que lo demás"
Recuerdo que Krita también es software libre, no se si tanto como GIMP (me hago un lío con tanta licencia), pero también lo es. Concretamente Krita es GNU GPL v2 y Gimp es simplemente GPL
Por aportar un poco más de información
http://wiki.gimp.org/index.php/Roadmap
http://www.gimp.org/
#35: Para que veas... mucho decir "lo que debería ser GIMP".
Pues yo digo lo contrario, ojalá GIMP jamás sea como "el kriter", porque GIMP tiene muchas ventajas que "el kriter" no tiene, como ser multiplataforma.
Por cierto, que funcione en Windows no solo es bueno para los que usan Windows, también es útil para los que usan ReactOS, que no olvidemos que es un sistema operativo tipo Windows, pero libre y de código abierto.
#33: Eso no es aportar información, es pwnear al bloguero que escribió esa bazofia.
#38: El problema de GIMP es que buena parte del trabajo no se ve a simple vista. GEGL es una biblioteca que para empezar, no es solo para GIMP (puedes usarla en cualquier programa, como por ejemplo, en LibreOffice, o incluso en juegos). Ese trabajo tan útil no saldrá a la luz hasta que lancen la versión de GIMP 2.10 (ahora están intentando lanzar la 2.08).
Cuando lancen esa versión, todo lo bueno de GEGL aparecerá de golpe, por eso parece que en GIMP no se hacen cambios. Ahora mismo lo más que se usa GEGL es en las herramientas de color... pero es que es un uso mínimo de la biblioteca. La biblioteca esa está pensada para edición no destructiva de imágenes.
Pero como dije, es mucho trabajo, y si nadie echa una mano... pues eso, que seguirá siendo mucho trabajo.
#41 Ojalá pudiera darle más votos al comentario! +++A
Además, se compromete a retirarla si estaba dupe y...
(¿Va a presentarse en las elecciones y está practicando o qué?)
Añado sobre #41: La edición no destructiva de imágenes es un poco esto:
Por ejemplo, imaginad que editáis una foto, y empezáis girándolaporque estaba torcida, luego véis que estaba oscura y decidís aclararla un poco. Luego, pensáis que quizás necesite desviar los tonos al rojo, y lo hacéis. Y es entonces cuando notáis algo raro en la foto, y decidís que hay que girarla un poco más.
Con la edición "destructiva", la actual, ese otro giro sería sobre un giro anterior, con lo que se perdería parte de la calidad de la imagen dos veces. Pero con la "no destructiva", lo que podéis hacer es ir a ese giro anterior, y modificarlo, para que luego se actualice la imagen bien, incluyendo esos retoques de luminosidad y color. Actualmente puedes usar deshacer, pero pierdes esas modificaciones posteriores.
"El kriter" no se que tendrá en este momento, pero yo creo que es mejor apoyar a GIMP, porque no es solo GIMP, es también GEGL, y apoyar GEGL permitirá apoyar a otros programas por detrás.
Es más, incluso los desarrolladores de "el kriter" podrían haber colaborado con los de GIMP en crear una base común de GEGL para los dos programas, y que luego cada programa use la interfaz que prefiera.
#45
krita es una parte de un todo mucho mayor que es koffice (bueno, ya no, ahora se llama calligra y es una suite offimatica completa) Krita ha elegido otro camino que es la integración con kde y todo lo que ello conlleva de beneficios... para lo interoperabilidad ya esta openraster. Y gimp se esta quedando muy atras en muchas cosas... mas que nada porque usa gtk que como libreria es una puta mierda... pero de las grandes.
#79 Simplemente eso que dices no es cierto... pero alla tu. Krita no te obliga a instalar más de qt/kde que gimp de gtk/gnome. Yo tengo los dos instalados en mi ordenador y no "sufro" por ello. Si algo usa gtk no me muero, tengo gimp y algún programa mas basado en gtk... aunque la mayoría de mi software es qt (kate, amarok, kmymoney, kspread, krita, calibre, kstars, okular... no me importa tener algún programita por ahi gtk (o con dependencias de este) como luakit o gimp.
#82: Aquí tienes la lista de correo:
http://lists.xcf.berkeley.edu/lists/gimp-developer/
Mira a ver cuántas personas solo han colaborado para enviar solo algunos parches.
Y por cierto, yo he hecho algún scritpt fffuuu de esos y lo he publicado.
#83: El trabajo de los desarrolladores de GIMP actualmente se está centrando en GEGL, por eso parece que el programa no avanza, pero en el fondo, si que avanza, pero por debajo.
El artículo está muy bien salvo por la introducción. La verdad, no veo quṕe necesidad hay de despotricar de esa manera contra un software para defender las virtudes de otro.
Parece más una especie de pique personal o algo así que una defensa técnica de un software frente a otro.
No estoy de acuerdo para nada con eso. Precisamente una de las pocas cosas que no me gusta (de repeler) de KDE es el pack de programas de imagen (krita y karbon),
incompletos ymás toscos de utilizar que gimp e inkscape. Un ejemplo es el tema de las herramientas, que lee de forma arbitraria el autor del artículo: en gimp seleccionas la herramienta y la utilizas. En krita debes seleccionar la brocha y decir qué tipo acción quieres que haga antes de utilizarla (clonar, borrar, pintar...), algo super intuitivo y superrápido cuando se trata de ilustrar [/sarcasmo].Para ilustración trae las mismas muchas/pocas opciones que trae gimp. Lo mismo para retoque fotográfico, donde Krita se queda o bien se queda corto, por la falta de herramientas, o bien es demasiado complejo a la hora de aplicar los efectos con el sistema de nodos (da más juego, pero es más complejo con diferencia).
Las brochas te las puedes crear tú perfectamente e incluso modificar las que tienes (en ambos programas).
Habla de que es demasiado complejo para edición amateur pero no para de hacer referencias a Photoshop (programa de retoque amateur donde los haya).
Dice que utiliza photoshop, que no ha utilizado krita más que dos o tres veces. Supongo que Gimp lo habrá usado igual de bien. No obstante no duda en configurar la interfaz como Gimp, algo que por supuesto no se puede hacer con Gimp porque la interfaz de Gimp es inconfigurable [/sarcasmo]. Eso sí, siempre con la ventana flotante.
A ese bloguero se le ha ido totalmente la pinza. Ves que alucina con cosas que tiene krita... ¡pero que también están en Gimp! sin embargo en krita mola.
La única ventaja real sobre gimp es el tema de los bits de la imagen, cosa a tener en cuenta para el que realmente lo necesite. Fuera de ahí es más cuestión de costumbres que otra cosa, porque vienen a hacer prácticamente lo mismo (pero no me gusta cómo se hacen, de ahí mi segunda frase).
Por otro lado... si no le gusta gimp que use krita, que para eso hay dos programas leñe.
En windows existe paint .NET, que para las cosas que yo necesito (recortar imagenes etc) es un programa excelentisimo. Existe un tal Pinta que es un port del paint .NET para mono (funciona en linux o mac os x por ejemplo) pero no me termina de ir bien
No sé la cantidad de oportunidades que le he dado a Krita y me parece una auténtica bosta. Salvo que me lo recomiende una persona de confianza, paso de darle más oportunidades.
Lo que dice de GIMP tiene un fondo de razón, al menos en lo que a retoque fotográfico se refiere. Yo lo uso poco porque rara vez me apetece jugar con capas, máscaras, etc.
Para jugar seriamente al retoque fotográfico en SL (sólo al que no necesita tratamiento por zonas y pincelitos) hay que ir a la línea de comandos y tirar de ImageMagick. Mano de santo.
Hace muchos años Krita[2] no es ni intenta ser un reemplazo de Gimp[2] basta ver la descripcion de cada software en su página. Pienso que hay que entender para que estan diseñadas la herramita para utilizarlas en las tareas adecuadas, por ejemplo existe digikam[3] para el manejo de fotos aunque no soy fotografo ni nada de eso esa seria la herramienta que usaria.
[1] "GIMP is the GNU Image Manipulation Program. It is a freely distributed piece of software for such tasks as photo retouching, image composition and image authoring. It works on many operating systems, in many languages. (more...)"
[2] "Krita is a KDE program for sketching and painting, offering an end–to–end solution for creating digital painting files from scratch by masters.
Fields of painting that Krita explicitly supports are concept art, creation of comics and textures for rendering.
Modelled on existing real-world painting materials and workflows, Krita supports creative working by getting out of the way and with snappy response."
[3] digiKam is an advanced digital photo management application for Linux, Windows, and Mac-OSX.
The people who inspired digiKam's design are the photographers like you who want to view, manage, edit, enhance, organize, tag, and share photographs under Linux systems.
Resumen:
"Buaaa! buaaa! no se usar el Gimp... snif snif"
Lo que he leido yo... "buaabuaaabuaaa GIMP caca buaaabuaaabuaaa KDE mola mas"
Uff, hace cosa de 4 o 5 años que probé Krita. No me gustó su interfaz (habrá mejorado mucho seguro) y volví a The Gimp. Actualmente uso PS desde hace 1 año. No me ha costado casi nada adaptarme tras 5 años con The Gimp... así que en el fondo, haciendo un buen uso de las herramientas básicas, no se diferencian tanto. Desconozco el estado actual de The Gimp, pero siempre defenderé, en arte digital o en cualquiera, que la gente en general quiere que las cosas vengan hechas y olvida el poder de un solo pincel.
El principal problema que le veo a GIMP es la interfaz de usuario. Sin llegar a extremos como la de Blender, tiene un sistema de ventanas muy desagradable y aunque en la última versión parecen haberlo mejorado, sigue estándo a años luz de la competencia.
La cantidad de veces que habré tenido que reiniciar la aplicación para que pudiera recuperar algunos paneles/ventanas de diálogo, que de vez en cuando se perdían en una dimensión alternativa y no había forma de hacerlos volver.
A mi me encanta GIMP. Lo único que veo desastroso, es el uso de capas, en este problemas. Cuando creas un efecto, ni la capa de se auto-redimensiona al tamaño de la imagen (peor, recorta la imagen o capa de fondo) y crea capas y máscaras que no vienen a cuento y que hay que borrar a mano, para que el efecto que buscas quede como debería.
Una cosa que me gusta mucho de GIMP es que le da mil vueltas a Photoshop para crear efectos de luces, estrellas, destellos,...
Salu2
#77: Esa es otra, que si quieres usar Krita, te tienes que instalar medio KDE. Es decir, si eres KDEro típico, Krita puede ser de gran interés, sino... pues a lo mejor no te interesa.
#78: Normalmente C es más rápido que C++, por eso se usa en programación de aplicaciones que hacen un uso intensivo del procesador, como vídeo, sistemas operativos...
De todas formas, a veces se hace programación mixta, y unos módulos van en C++ y otros en C.
Adobe Photoshop puede ser una aplicación maravillosa, pero es carísima. Por esta razón GIMP es una excelente alternativa a PS para quienes no puedan comprar el software o se nieguen a usar software pirata.
#40 Pues QT (sin efectos) dibuja las cosas mucho más rapido que GTK, que alguien me lo explique . GTK anteriormente, hace 2 años, tenia unos problemas ENORMES con gtkGL y usar emuladores escritos en GTK, por ejemplo . VisualBoyAdvance , Desmume , y demás iban LENTOS como el ojete , cosa que no pasaba con la versión SDL pura .
#43, ¿y eso qué demonios tiene que ver? Algo mal programado funcionará mal, esté en el lenguaje que esté.
Lo de que sí gimp tiene menos desarrolladores o que tiene poco apoyo es algo que he visto demasiado en los comentarios y puede servir para entender su situación pero no creo que sirva a modo de excusa. Eso no cambia que el desempeño del un programa sea el que es y que para muchos no sea suficiente y ya está. Además esos problemas solo pondrían de manifiesto que el modelo de software libre no es tan bueno como muchas veces se quiere hacer creer.
No parece ser duplicado. Si alguien lo encuentra, que avise y la retiro.
Yo usaba linux hace (muchos) anyos, y creo que nunca llegue a ver Krita funcionar en mi PC, pero si venia oyendo hablar de el. Era como el MsPaint y poco mas...
Quien lo ha visto y quien lo ve
Respecto al Gimp, creo que se ha quedado atras. Lo vengo usando lo menos 5 anyos, y no ha cambiado nada
Tengo que decir que desde que me pasé a linux, lo que menos me ha gustado es el gimp, que quedaba muy por debajo de photoshop (aunque claro, si hablamos de calidad/precio... ). Y me pensaba que directamente era el mejor programa libre que había para estas cosas... Y ahora descubro que hay otros programas como Krita.
Pues nada, a instalarlo toca (creo que no es el que sale en el centro de software).
Por cierto, photoshop corre perfectamente con wine (a partir de la 1.3 de wine creo), pero vamos, sigue siendo muy caro...
Recién instalado, a pesar de lo dicho en #98, sí, es el que viene en el centro de software, así de primeras no tiene mala pinta. A trastearlo toca.
C++ deberia estar prohibido.
Como el tabaco.
No hay binarios para windows?
Gimp, un programa que tengo instalado desde mi época de linux y cada vez uso menos. Ahora mismo con las herramientas de retoque de iPhoto me sobra.
Mucho 16 bit por canal, que si 32 bits en RGBA y no se que más, y después resulta que no hay binarios para Windows y Mac. Pues vaya lástima, llevo tiempo esperando un sustituto para GIMP (o que éstos hagan una aplicación usable).
For Windows and OSX we currently do not provide binary installers, and building on Windows or OSX is difficult. (Which is why we don't have binaries for you.)
Pues haberlo hecho en Java y ya os sirve para todos los sistemas operativos
#94, lo que hace GTK es poco importante. GTK dispone de herencia, relaciones, sobrecarga de métodos (aunque admito que esto ya es un poco trampa) y bueno, casi todo lo que la POO define.
#96, coño, y yo con mi implementación puedo hacer vectores con los tipos que quiera. Desde enteros, floats y chars hasta structs y enums (incluyendo los correspondientes punteros)... estamos en lo mismo, una plantilla que puede funcionar con cualquier tipo.
Por cierto, antes de seguir, estoy empezando a sentirme realmente mal. Después de "envía un comentario" me pone "porque alguien en Internet está equivocado". ¿Esto es un rollo automático o siempre aparece?
#93, ¿quieres que implemente toda la API de vectores de C++ en C con macros por aquí? Vamos a aburrir a todos, te lo aviso.
#95 pues a eso iba, con lo bonito que es mi querido vector para que voy a andar haciendo yo el trabajo sucio. Por cierto que no es la api de c++, es que yo puedo declarar vectores de cualquier clase propia.
Me gusta mucho que traiga por defecto pinceles y herramientas orientados a ilustracion de tan buena calidad.
GIMP puede ser muy bueno como apuntan por ahí, pero siempre le he dado oportunidades y nunca he conseguido modificar una imagen a mi gusto con él y siempre he terminado desesperado para realizar tareas sencillas con otros programas. Krita no lo he probado.
Gimp tiene puntos que están estancados desde hace años, el tema del color es un problema de base que se ha prometido mil veces solventar y que creo que por pura pereza no se ha hecho seriamente. Aun así, sigue siendo una herramienta sumamente potente y en algunos puntos es superior al Photoshop por mucho que se diga (cuando me ha hecho falta he hecho maravillas con scripts y desde la linea de comandos). Me alegro de saber de la existencia del tal Krita, le echaré un vistazo y veré qué sorpresas agradables me puede llevar.
Por otro lado lo que siempre me disgusta de este tipo de artículos es que a menudo se da la impresión de que el mayor problema de The Gimp es tener una interficie gráfica distinta de la del Photoshop y que cambiando simplemente eso pasa a ser una maravilla. Dominar estas herramientas conlleva mucho tiempo y mucha paciencia y el paso de una a la otra se hace muy duro debido mas que nada a la inercia. Yo en tiempos pretéritos era muy muy aficionado al PaintShopPro y lo seguí desde las primeras versiones hasta aproximadamente la 8 (no recuerdo el número). Recuerdo que el paso a The Gimp fue para mi muy traumático y me llevó mucho tiempo y dedicación por lo frustrante que resultaba no encontrar las cosas de inmediato en el sitio habitual (y ojo, tambien el no disponer de herramientas de dibujo vectorial). Habría que intentar ser justos con este tema y admitir que tener una interficie distina no significa ser peor, este mismo comentario se podría hacer respecto a Blender dicho sea de paso.
interesante... en septiembre es posible que aparezca versión para windows, según pone en la sección descargas.
jum, este krita tiene una pinta exclente... yo suelo usar el gimp o el photoshop, generalmente dependiendo de o perro que me encuentre a la hora de la instalación... tendré que enterarme si existe versión winblowera
Lo triste es que los linuxeros siempre estamos con las flame wars entre Gimp y Krita y al final proyectos cojonudos como Nathive (http://nathive.org) se van quedando cada vez mas parados por falta de colaboración.
#92: Lo lógico sería intentar tirar de una base común con GIMP, y que luego cada uno añada la interfaz gráfica a su estilo, y que la gente elija cual se ajusta más a sus necesidades.
No lo conocia , no uso kde desde hace mucho . Una virgueria el programita . A ver si los de kde se animan y hacen algo para biomecanica.
#3 biomecánica? Que buscas concretamente?
#11 algo similar a dartfish o similares. no hay nada en el mundo del software libre hasta donde yo conozco.
#40 Si el compilador es decente y haces las cosas bien no solo C++ puede ser igual de rapido que C sino que puede sobrepasarlo y todo
#50, no, por ahí sí que no paso. C++ va a tener un tiempo de ejecución siempre mayor igual que el mismo programa en C. Más que nada, porque C++ no es más que C con un montón de características redundantes que se pueden implementar también en C. C++ no ha aportado ninguna característica nueva. En todo caso, ha limitado algunas cosas.
#52 Yo he estado involucrado en el desarrollo de un programa bastante grande en C y la verdad es que hubiera matado por hacerlo en C++, creo que decir que no aporta nada y que puedes hacer lo mismo en C es sobrarse un poquito...
#55, las mejoras de C++ son meramente sintácticas. La orientación a objetos puede implementarse en C perfectamente.
#59, los objetos SON redundantes. Modelar una aplicación en forma de objetos no requiere un lenguaje orientado a objetos. Y si me hablas de que bajo el mismo programador poco hábil, un lenguaje produce un código más óptimo que otro lenguaje, eso realmente no es un argumento.
#68, a ver, es obvio que si utilizo el gcc y el g++ para compilar el mismo archivo las diferencias van a ser miserables (quizá g++ incluya algún extraño thunk con impacto nulo en un código bastante trabajoso). Y sobre lo que dices, a ver, está claro que depende del programador. Pero también está claro que cada lenguaje tiene sus tendencias y sus formas. Si usas C++ es porque vas a usar objetos. Y es aquí donde se debe establecer la comparativa con C.
#69, no son el mismo proyecto. C tiene un estándar, C++ tiene otro y objective-C tiene otro distinto. Y a ver, también he de dejar claro por qué defiendo C a ultranza. C++ es un lenguaje con el que no me meto si lo más duro que vas a hacer va a ser la mítica aplicación gráfica de usuario que manipula representaciones de elementos del mundo real. Te rompes menos la cabeza. Sin embargo, yo he tenido que programar mis rollos desde el más puro bajo nivel hasta la más abstracta interfaz gráfica (no es que haya programado tampoco demasiado, pero sí en muy diversos ámbitos). He usado GTK (aún cuando Qt seguramente tenga bindings para C) el cual, pese a ser tradicionalmente en C incorpora una orientación a objetos. Y el hecho de que C pueda usarlo a tantos niveles con la misma facilidad me parece realmente atractivo.
#78, explícame eso de los ámbitos. Yo he tenido que desensamblar binarios en C y C++, y estos últimos incorporan una cantidad ingente de basura que lo último en lo que te hacen pensar es en un compilador con mucha información.
Veréis, y así quizá os responda a todos, mi problema con C++ es doble. El primero es que la abstracción a objetos no requiere una nueva sintaxis en C. De hecho, quizá algo que me parece bastante desagradable de muchos de los proyectos en C++ que he visto por ahí es la sobreabstracción de algunos elementos sacrificando una eficiencia que puede llegar a ser importante. El segundo es todo el código de apoyo que tiene que generar para mantener todas esas abstracciones, que lo aleja más de su estructura una vez compilado. Quizá lo que más miedo me da es el operador "new". ¿Cómo funciona? ¿Necesita paginación para funcionar? ¿Dónde reserva? ¿Puedo tocar sus estructuras internas? ¿Y qué pasa con malloc? Tengo un operador que hace cosas muy complicadas con la memoria, cuando eso es algo que normalmente se deja a la merced una función. Los operadores deberían hacer operaciones atómicas, o casi atómicas. Si esto fuese como Java quizá no me escandalizaría tanto, pues la memoria es una caja negra que la VM sabe cómo manejar.
Quizá sea un anticuado y tenga la cabeza cuadriculada, pero a mí tantas abstracciones a tan diversos niveles en el mismo lenguaje me asustan.
#86 el presidente del club de adoradores de std::vector te saluda
#c-87" class="content-link" style="color: rgb(227, 86, 20)" data-toggle="popover" data-popover-type="comment" data-popover-url="/tooltip/comment/1348650/order/87">#87
#define DECLARE_VECTOR_TYPE(type, name) \
typedef struct \
\
name ## _vector;
Y así con las funciones que manejan cada tipo de vector.
¿Decías?
#90 ein? http://www.cplusplus.com/reference/stl/vector/
#86 las mejoras de C++ son meramente sintácticas. La orientación a objetos puede implementarse en C perfectamente.
Yo he vivido eso, un proyecto modelado con POO e implementado en C, y te aseguro que no es lo mismo, es un jodido dolor de cabeza, asi que por favor, sobre el papel esta todo muy bonito pero en la practica existe C++ y es por una razón.
#88, hombre, hablo con GTK en la cabeza. Quitando el horripilante tratamiento de las cadenas que tiene, ha sido un placer. Es para mí el ejemplo de cómo una POO en C debe hacerse (pero no implementarse).
#91 Pues has dicho C siempre, que no es lo mismo que un framework hecho con C para un fin muy concreto, ya que no es igual desarrollar una aplicacion que una herramienta.
#86 Entiendo perfectamente tus reservas. Yo he sido durante muchos años programador de ASM y al pasar a C tuve resistencias similares, las tuve también de C a C++, de hecho, las mismas o muy parecidas a las tuyas.
Mira, tienes razón en que todo lo que hace C++ se puede implementar en C (de hecho, en ASM también), pero cuando ves la gran diferencia es cuando trabajas en un proyecto con muchos programadores (sin llegar a cientos, que también).
A uno, programando solo, le puede parecer irrelevante declarar los miembros de una clase como public, private o protected, por poner un ejemplo sencillo, y eso solo se puede hacer en C++. Ciertamente el código generado no varía, pero cuando meten mano a un repositorio muchos programadores, un proyecto C es muy dificil de mantener (uno en ASM, aún peor). Sin embargo, esos detalles aparentemente irrelevantes como declarar correctamente los private de una clase ayudan a mantener un cierto orden dentro del caos que a la larga, ahorra muchísimos bugs. La abstracción (muchas veces con tendencia a la sobre-abstracción, como bien dices), también simplifican mucho la programación entre muchas personas, al hacer clases que son autonómas por si mismas y mucho más fáciles de mantener.
En mi experiencia, cuanta más gente mete mano en el código, más se aprecian las virtudes del C++, que no son efectivamente en pro de una mayor velocidad de ejecución si no de una mayor robusted y/o modularidad. Más sencilllo de mantener, en definitiva.
Las herencias son una herramienta muy potente de C++ que si bien pueden implementarse en C, son un poco follón de hacer. Abusando o mal implementando pueden ser horribles, pero bien usadas ahorran una barbaridad de trabajo y el código no tiene por qué perder eficicencia. Creo que la mayoría de los programadores de C abrazan definitivamente el C++ cuando aprenden a usar bien las herencias y descubren la potencia de utilizar las clases de una forma abstracta. Pensar "en C++" no es lo mismo que pensar "en C". Cuando un programador ASM empieza a programar en C, se nota, hace C al estilo ASM. Lo mismo cuando un programador de C pasa a C++, tarda un tiempo en apreciarlo y sacarle jugo (más si va con prejucios).
En cuanto a las redefiniciones caóticas de operadores como new, u otros operadores, el abuso es un vicio en C++ que debe evitarse o manejarse con precaución. En principio, el operador new estándar no tiene mucho misterio, es un malloc o bien un alojamiento en el stack de los datos de una clase y posterior llamada al constructor. Puedes ver el código en el runtime estándar o puedes desensamblarlo.
Yo que no tengo ningún prejucio a priori con ningún lenguaje (en el mismo proyecto puedo usar ASM, C, C++, PHP y Bash Script, por decirte algo), te animaría a que te acercases al C++ con la mente abierta, y descubras las grandes ventajas que tiene. Hay por ahí un libro, "Think in C++", que te recomiendo encarecidamente. Un saludo.
#86 menuda sarta de disparates estas diciendo.
Para empezar, C++ tiene genéricos, que no es lo mismo que un puntero void. Ya que los genéricos, el compilador se encarga de detectar posibles errores en tiempo de compilación. Y posiblemente este es uno de los puntos mas fuertes de C++ enfocada a la meta programación. http://codeando.blogspot.com/2006/11/metaprogramacin-por-medio-de-templates.html
Luego tenemos, las múltiples cosas que nos ofrece el paradigma orientado a objetos. Como la herencia, la ligadura dinámica, clases abstractas, etc... mírate la teoría de la orientación a objetos. Que es muchísimo mas que simples clases y objetos.
Pero vamos, por ti seguiríamos programando en ensamblador de 8086.
Por cierto, vete mirando una cosa llamada Scala. Buen lenguaje.
#86 Decir que la orientación a objetos es "redundante" es gritar al cielo que no has programado nada de más de 1000 lineas e C.
Como han dicho ya en un comentario anterior, a día de hoy C es un subconjunto de C++. Es decir, ciertamente puedes hacer igual los programas que haces con C++ con lo que hay en C, pero renuncias a las facilidades que te da C++.
Es como si me dices que al pueblo de al lado puedo ir en bicicleta o en coche. La diferencia de tiempo es despreciable y en cambio me ahorro el combustible, el seguro, el mantenimiento abusivamente más caro del coche... y te daría la razón. El problema vendría cuando en lugar de ir al pueblo de al lado, quiera hacer un trayecto Madrid-Barcelona. Y el problema es cuando has visto el pueblo de al lado, luego quieres ver otros pueblos. Cuanto más viajas, más te interesa el coche.
Cierto es que se pueden implementar las características de C++ con C (los primeros compiladores de C++ se escribían en C). Pero es como si me dijeses que si a tu bicicleta le pusieses 2 ruedas más, un motor, frenos de disco, un volante con dirección asistida... haría lo mismo que el coche. Aunque claro, entonces la pregunta que te haría yo ¿vas a hacer el coche desde 0 solo pq no te interesa que el coche lleve elevalunas eléctrico?
En fín, por no alargar más esta explicación, pregúntale a alguien que tenga que hacer un programa medianamente grande (y GIMP por ejemplo lo sería), si lo haría con C o C++. Solo por la gestión de las cadenas en C++, ya vale la pena...
#52 ¿Y todo esto lo estás diciendo con conocimiento de causa? Porque vamos, se me ocurre a bote pronto que C++ tiene la orientación a objetos que C no tiene. ¿Te parece redundante? Porque si es así, ciertamente no entiendo porque si el rendimiento importa tanto han usado C: que hubiesen usado ensamblador, los lenguajes procedurales son para los débiles.
Te dejo una comparativa entre C y C++, para que veas las diferencias. Efectivamente se puede hacer en C todo lo que puedes hacer en C++... si lo programas, claro. Pero volvemos a lo mismo: con ensamblador también puedes y el rendimiento es mucho mayor.
A día de hoy, si un programa funciona más rápido en C que en C++, habla más de la habilidad del programador y del conocimiento del lenguaje del mismo, que del propio lenguaje de programación.
#52 sé lo que quieres decir, pero no es cierto en términos absolutos. C es un subconjunto de C++ hoy en día, lo que quiere decir que el compilador es el mismo, con funciones deshabilitadas cuando compila en C. Si tu haces un for, un while, lo que sea, en C y C++, el código de máquina resultante va a ser idéntico porque de hecho, lo compila el mismo compilador sea C o C++.
Por tanto, un programa en C++ va a ser exactamente igual de rápido que un programa en C que haga lo mismo. Pero (y ahí es donde tienes tu parte de razón) la estructura orientada a objetos de C++ tiende a una programación redundante que acaba realizando más proceso del necesario, mientras que en C se tiende a economizar, el mismo fenómeno que ocurre en ASM. Pero esto es un problema del programador y de diseño y no del lenguaje en sí mismo. Nada te impide en un programa C++ hacer funciones críticas en ASM incluso si lo deseas. Y por supuesto, un buen programador puede hacer código más eficiente en C++ que un mal programador en ASM. Saludos.
#68 no me dio tiempo a leer tu comentario. totalmente de acuerdo
un saludo
#52 C puro es mas rapido que c++ pero eso no quiere decir que sea mejor. De echo son parte del mismo proyecto solo que c++ incorpora bastantes capas de abstraccion que hacen mas facil un buen diseño de software.
Hay algunas librerias de realtime sobre c++ que permiten un rendimiento instantaneo, pero los compiladores se siguen programando en C por tradicion y porque esta mas cerca del lenguaje ,maquina.
Para cada clavo su martillo...
#52 Esto no es cierto, C++ tiene ámbitos en los que el compilador tiene más información sobre qué hace el código, por lo que puede generar un código máquina más adecuado.
Por favor, si hay que desprestigiar algo, proporciona datos por lo menos.
#78 en video el rey sin discusión es Nuke (C++) y en renderizado (uso hiperintensivo) lo son MentalRay en produciones serias (C++) y Vray en temas más pequeños (C++)
#50: ¿Y si pones dos compiladores igual de buenos, uno compilando C++ y otro compilando C?
Es como si me comparas C con ensablador o Java con C++.
La verdad es que el programa tiene buena pinta. Eso sí, hay un par de cosas que el artículo dice que photoshop no puede hacer y sí que las hace. (filtros inteligentes, por ejemplo) Me ha gustado mucho lo de la doble vista. Muy interesante.
Y algo que pasa al final cuando te dedicas de forma profesional a esto es que acabas usando las herramientas básicas en un 95% de las veces con lo que más se agradece en este tipo de programas es que sean intuitivos, ágiles y 100% personalizables
#56 Eso es porque la entrada es de hace 2 años..
Antigua a más no poder.
#60 2 años no, pero es de diciembre de 2010... una eternidad si hablamos de software.
#64 A eso me refería. Veo que lo has sabido expresar mejor.
No puedo estar más de acuerdo. No basta con que sea libre, gimp es una basura inutilizable para principiantes, pero como es libre mola mazo, tengo el código y lo puedo modificar a mi gusto (se busca persona que lo haya hecho en alguna ocasión, viva o muerta),
Creo que es dupe. Búscalo en el buscador.
#1 Porque ya lo había leído, y pensaba que aquí. Tampoco hace falta fusilarme.
SENSACIONALISTA. Y si por mi fuera, votaría "KDEro buambuláncico".
El motivo es simple: En GIMP hay pocos desarrolladores, con lo que implementar GEGL no es un proceso rápido, ya que la tarea ni mucho menos sencilla. GEGL permitiría trabajar en muchos modos de imagen y aplicar un modo de trabajo basado en modificaciones no destructivas. A esto yo le diria bien claro: si no vas a aportar nada útil, cállate la boca y deja a los programadores ir programando todo.
Si alguno quiere saber a que ritmo se desarrolla GIMP, puede mirar aquí:
http://tasktaste.com/projects/Enselic/gimp-2-8
Como veréis, GIMP no es un programa que reciba un gran apoyo, pero aún así, se mantiene.
Además, el blog tiene un tufillo Buambulancia que tira para atrás. El cuarto punto lo deja bien claro. Si no sabe buscar el botón "T" del panel de herramientas, ni escribir un cacho texto, ni señalar un espacio para introducir ese texto, lo siento, pero la informática no es lo tuyo. Si hasta Paint usa un fluyo de trabajo parecido...
No se queda ahí la cosa el blog es estúpidamente "tecnofílico", y considera anticuado todo aquello que tiene una alternativa posterior. Por ejemplo, decir que el sistema de capas está anticuado, cuando para muchos tipos de trabajo es la forma más sencilla de trabajar. A mi el sistema de capas de GIMP me gusta.
Por cierto, YO JAMÁS ABRIRÍA UNA FOTO DE LA CÁMARA EN KRITA. ¿Sabéis porqué? Cuando lo hice la última vez que probé ese programa, me puse a juguetear con la foto, para ver las capacidades del programa, cuando de pronto el programa INTENTA SOBREESCRIBIRME LA FOTO CON EL GUARDADO AUTOMÁTICO. Menos mal que tenía la foto en un CD, que sino, me estropea la foto de la cámara con esa función que no debería estar presente. Si a caso, que haga copias temporales en una carpeta temporal. Yo no criticaré a los autores del programa por esto, pero desde luego, que a mi me dejó claro que ese proyecto no iba en serio. Cualquier persona con interés en retocar fotos sabe que las fotos originales de la cámara, JAMÁS SE SOBREESCRIBEN.
Por cierto, los pinceles que tenía el kriter cuando lo usé... ¡Eran los de GIMP! Vamos, que para lo malo, GIMP es una mierda, pero para lo bueno, bien que tiran de copiar y pegar y licencia GPL.
Por cierto, GIMP está programado en C, y "el kriter" en C++. Adivinad cuál es más óptimo para procesar imágenes.
Yo no cambio GIMP por "el kriter" por nada del mundo.
#31 Por cierto, GIMP está programado en C, y "el kriter" en C++. Adivinad cuál es más óptimo para procesar imágenes. ¿Qué coj...? C y C++ tienen un rendimiento realmente muy parecido, además por el uso de librerías y manejo del lenguaje todos (si, todos) los grandes monstruos del diseño están en C++ vease desde Photoshop, a Nuke, a cualquiera de Autodesk.
#36, C++ es más lento. No mucho más, pero es más lento.
#31 Adivinad cuál es más óptimo para procesar imágenes.
Yo símplemente aclarar que nada es "más óptimo", "óptimo" es lo mejor (superlativo), y por tanto habria que decir "cual de los dos es el óptimo" o "cual de los dos es mejor". Por ejemplo: "Un buen flame requiere de la escritura óptima".
De lo otro, solo hago cuatro retoques, así que me vale cualquier programilla.
#47, tienes razón, pero a la cárcel, como se suele decir. En ámbitos informáticos (e ingenieriles, seguramente), se usa "óptimo" de una manera bastante libre, que para algunos puede que viole su significado correcto, y a otros puede parecerles una figura retórica, como la metonimia o la hipérbole. Ciertamente si yo dijera "Bebí una copa", nadie podría corregirme diciendo "La copa no se bebe. Bebiste el contenido de la copa", ya que estoy usando la metonimia. Similarmente para decir "Tuve que hacer mil tareas aburridas".
En informática se aplica "óptimo" como sujeto del acto de optimizar (intentar convertir algo, normalmente un programa, en lo "mejor" posible), aunque en efecto tal sujeto no haya sido mejorado hasta el extremo, sino sólo en cierto grado (y por tanto no sea "óptimo"). Podría compararse con que si tengo un lienzo y le aplico un tinte para dejarlo completamente negro (lo "ennegrezco"), pero dejo el proceso cuando todavía está gris, quizá diga que el lienzo está "ennegrecido", cuando en realidad está "engrisecido".
Al igual que de dos lienzos diría que el "más ennegrecido" (o incluso "más negro") es aquel que, siendo gris (no negro), es más oscuro (aunque técnicamente la cualidad de "negro" no es gradable: o se es negro, o no se es), también se dice de dos programas que el "más óptimo" es aquel que, siendo bueno (no óptimo), es mejor (aunque técnicamente la cualidad de "optimo" no es gradable: o se es óptimo, o no se es).
#31 Traduzco webcomics por hobby y he de decir que la herramienta de texto del gimp es la mayor mierda que he visto en mi vida en ese campo, seguido muy de cerca o a la par del paint.net. La de paint de windows es mejor y más cómoda, que ya es decir. Y lo he comparado con una pila de programas de tratamiento de imágenes, por ahora, el más cómodo y funcional para mí es el de photoshop, sobre todo por las opciones que tiene y la facilidad de manejo del texto una vez escrito.
no entiendo, o prefiero no entender porque votan negativo a #58, solo dice que ha comparado varios programas y cual es el que mejor le va
#31 utilizar GIMP, es dañino y doloroso. No puedes cambiar eso, ni siquiera su comunidad quiere (o tal vez no puede) cambiarlo.
Hace poco comenté en otra noticia que GIMP era un cadáver que ya olía, y a los pocos segundos ya tenía el primer negativo. Supongo que a este tipo de fanboys es al que se refiere el autor del artículo, y es que los radicalismos no son buenos.
#72 Discrepo. Gimp hace lo que necesito hacer, y la "facilidad de uso" es un tema de costumbres. Krita tiene buena pinta, pero algo que usa libs de kde sencillamente no me sirve para mi sistema, es meter demasiada mierda por un par de programas a lo sumo, ya que el escritorio no me gusta.
#31 Joder, nunca vi a un tonto creerse tan listo y hacer tanto el ridículo.