El mundo del software libre como otros tantos se mueve a través de mitos, tradiciones y todo tipo de leyendas. Esto hace que haya programas intocables, y el ejemplo más claro de esto es GIMP un software desfasado desde hace años y que hace a medias todo, pero que cuenta con un apoyo ferviente de parte de los talibanes de la comunidad. Hay gente que piensa que algo por el simple hecho de llevar el sello de "Software Libre" debe ser mejor que lo demás, lo cual bloquea cualquier evolución...
|
etiquetas: gimp , diseño , software libre , retoque , krita , mypaint 
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.
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.
#6 -> #5
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.
www.freedesktop.org/software/colord/
y
www.meneame.net/story/comparacion-the-gimp-vs-krita
"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
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.
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.
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
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.
Parece más una especie de pique personal o algo así que una defensa técnica de un software frente a otro.
wiki.gimp.org/index.php/Roadmap
www.gimp.org/
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)
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.
Y me auto contesto: Y el pyhon-fu, y el batch y... bah, paso...
Sí, sí! El Krita le pega mil patadaaaas!
Además, se compromete a retirarla si estaba dupe y...
(¿Va a presentarse en las elecciones y está practicando o qué?)
Una cosa que me gusta mucho de GIMP es que le da mil vueltas a Photoshop para crear efectos de luces, estrellas, destellos,...
Salu2
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.
Como el tabaco.
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
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.
Antigua a más no poder.
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.
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
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.
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.
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...
un saludo
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.
Por favor, si hay que desprestigiar algo, proporciona datos por lo menos.
[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.
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.
"Buaaa! buaaa! no se usar el Gimp... snif snif"
#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.
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.
#define DECLARE_VECTOR_TYPE(type, name) \
typedef struct \
{ \
int card; \
type *coef; \
} \
name ## _vector;
Y así con las funciones que manejan cada tipo de vector.
¿Decías?
#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?
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...
en.wikipedia.org/wiki/Kross_(KDE)