die fehlende vorschau bei vielen aktionen war wohl einer der hauptkritikpunkte bisher. toll, dass sie das in angriff genommen haben. Kudos to the developers.
>Tiny-Fu, der später eventuell das bisher eingesetzte Script-Fu ersetzen soll. vgl. mit dem Originaltext: Tiny-fu, which will eventually replace Script-fu.
Eventually heisst nicht eventuell, sondern _letztendlich_ (dict.leo.org)
Von Chlothar III. am Mo, 20. Dezember 2004 um 12:23 #
"da die Vorteile von Tiny-Fu einfach zu groß sind."
da hat sich jemand ja mächtig ins Zeug gelegt, bei dieser deutschen Poesie: zu grosse Vorteile - einfach unerhört, was sich die Entwickler da erlauben!
Das ist ja mal eine tolle Nachricht. Vor allem die Zusammenarbeit zwischen OpenOffice und Gimp mit Drag & Drop bzw. Copy & Paste habe ich vor einigen Tagen sehr schmerzlich vermisst. Die Unterstützung von Schriften und deren Formatierung könnte noch besser werden. In Photoshop konnte man da richtig viele Dinge mit anstellen und unter Gimp (zumindest bei der Linux Version) kann ich nicht mal die Größe dynamisch verändern.
Mach mal einen Doppelklick auf das Textwerkzeug, da kannst du in den Einstellungen auch die Textgröße und Schriftart ändern. http://docs.gimp.org/de/ch03s06s07.html
Ahja, das bewirkt es. Sehr cool, war schon ein wenig am Verzeifeln, da alle möglichen Klicks auf die Schrift nichts halfen. Wäre vielleicht noch besser, wenn man die beiden Dialoge zusammen- führt, also einmal das Texteingabefenster und das Ändern der Schrift, statt zwei verschiedene Optionsfenster über unterschiedliche Mechanismen erreichen zu können.
mag sein, dass die Aussicht über Weihnachten arbeiten zu müssen, meine Sinne etwas vernebelt hat, aber ich bekomme die 2.2 einfach nicht compiliert, der libgsf scheinen einige Symbole zu fehlen. Mit der 2.2pre2 gab bzw. gibt es kein Thema und configure meckert auch nichts an. Baufehler gehören aber sicher nicht in den Bugzilla, daher frage ich erstmal hier. Lohnt es sich, den ganzen Fehler hier zu posten, oder weiß jemand, woran es liegen könnte?
Von Steinbeißer am Mo, 20. Dezember 2004 um 15:06 #
> die Aussicht über Weihnachten arbeiten zu müssen
Bei dir ist ja wohl ein Rad ab. Es gibt Leute, die würden sich darum schlagen, an Weihnachten arbeiten zu dürfen und du beschwerst dich? Mann, lass dich behandeln!
Ja, es war das letzte KDE-Update von Suse. Wieder die Original drauf und alles geht, Konflikte gibt es keine. Offenbar ist das aber nur fürs Compilieren nötig, ich habe jetzt wieder auf die neue gewechselt und trotzdem läuft alles einwandfrei, auch Gimp.
Von Thorsten Schnebeck am Mo, 20. Dezember 2004 um 18:12 #
... bleibt weiterhin die fehlende 16Bit/Channel-Unterstützung, was dazu führt, dass Rohbilddaten moderner Kameras nur mit reduzierter Qualität bearbeitet werden können und Farbmanagement. Beide ist sehr notwendig und kommt hoffentlich absehbar. Letzteres hat es anscheinend nur knapp nicht in die 2.4 geschafft. Alternative für den Fokus Digitalbildbearbeitung ist digiKam, das kurz vor dem 0.7.1-Release steht und einen guten Satz an Filtern mit ansprechneder GUI mitbringt.
Von Markus Merz am Di, 21. Dezember 2004 um 11:27 #
IPTC (konkret IIM), auch bekannt als Photoshop Datei-Informationen (in TIFFs und JPEGs), muss dringend mal rein. Ansonsten hat Gimp nie eine Chance bei Fotografen, Fotoagenturen und Verlagen.
Von Markus Merz am Di, 21. Dezember 2004 um 16:20 #
Erstmal danke für den Link!
> "It is based on the XMP model, which supersedes IPTC ..."
Das ist das Problem. XMP ist schick, aber im etablierten Workflow noch nicht etabliert
Ansonsten ist die Behauptung, dass XMP in naher Zukunft IPTC (IIM) ablösen oder überflüssig machen wird, einfach nicht wahr. Die verbreiteten IPTC-Texteditoren für die Massenbeschriftung im Agenturgeschäft unterstützen noch kein XMP. Und dann müssen die Datenbanken angepasst werden - und das sind alles keine XML Datenbanken.
Dasselbe Problem trifft auch auf das Dateiformat JPEG 2000 zu.
Die ganze digitale Verarbeitungskette vom Fotografen bis in die Bildredaktion basiert derzeit auf JPEG (RGB) + IPTC (IIM).
Von Markus Merz am Di, 21. Dezember 2004 um 17:01 #
Und wo wir gerade dabei sind - hier noch ein Link zu einem Blog-Beitrag, der das Thema DNG by Adobe (digitales Negativ) anspricht und passend verlinkt.
Also ähnlich XMP-by-Adobe und IPTC-a-la-Photoshop ein weiterer Beitrag Adobes zur weiteren Verwirrung der Formate und der Pseudo-Standardisierung aufgrund von "Photoshop ist Standard". Standardisierung per Presse- und Absichtserklärung - klingt bekannt (XML-a-la-M$), oder? Passendes (teures) Produkt dazu und fertig.
Adobe hat aus dem Urgedanken IPTC (Envelope mit tagged Content) bzw. XML (Dokument mit tagged Content) ein eigenes nicht Standard konformes Produkt kreiert, das Content binär in den Header einer Datei packt. Besser wäre es natürlich den Content XML konform in ein Dokument als Markup reinzupacken und es jedem freien Parser zu überlassen, welche Content-Bestandteile er denn auslesen, benutzen, hinzufügen oder verändern möchte.
So kann man den XML Gedanken natürlich auch pervertieren ... oder das Produkt per Marketing zum "Standard" erklären.
Von Michael Schumacher am Di, 21. Dezember 2004 um 18:30 #
Was mich an XMP auch stört - Adobe will das als "offenen" Standard etablieren, aber dann darf man das Dokument mit der Spezifikation nicht einfach weiterverbreiten (auf den ersten Seiten steht das irgendwo).
vgl. mit dem Originaltext: Tiny-fu, which will eventually replace Script-fu.
SCNR
"irgendwann einmal" Ist auch eine mögliche Übersetzung. Das ist schon weit weniger bestimmt
da hat sich jemand ja mächtig ins Zeug gelegt, bei dieser deutschen Poesie: zu grosse Vorteile - einfach unerhört, was sich die Entwickler da erlauben!
OpenOffice und Gimp mit Drag & Drop bzw. Copy & Paste habe ich vor einigen
Tagen sehr schmerzlich vermisst.
Die Unterstützung von Schriften und deren Formatierung könnte noch besser
werden. In Photoshop konnte man da richtig viele Dinge mit anstellen und
unter Gimp (zumindest bei der Linux Version) kann ich nicht mal die Größe
dynamisch verändern.
Martin
http://docs.gimp.org/de/ch03s06s07.html
Ahja, das bewirkt es. Sehr cool, war schon ein wenig am Verzeifeln,
da alle möglichen Klicks auf die Schrift nichts halfen.
Wäre vielleicht noch besser, wenn man die beiden Dialoge zusammen-
führt, also einmal das Texteingabefenster und das Ändern der Schrift,
statt zwei verschiedene Optionsfenster über unterschiedliche
Mechanismen erreichen zu können.
Martin
in der 1.x war das auch möglich (als textfield oder so)
Bei dir ist ja wohl ein Rad ab. Es gibt Leute, die würden sich darum schlagen, an Weihnachten arbeiten zu dürfen und du beschwerst dich? Mann, lass dich behandeln!
Dein Kommentar war überflüssig!
Warum fragst Du, gibt es Nebenwirkungen?
Alternative für den Fokus Digitalbildbearbeitung ist digiKam, das kurz vor dem 0.7.1-Release steht und einen guten Satz an Filtern mit ansprechneder GUI mitbringt.
Beiden Projekten: Weiter so!
Thorsten
Diese Metadaten sind einfach zu wichtig für den Import in Fotodatenbanken ... z.B. bei der Bildagentur Fotex.
Markus
PS: Wäre auch schick, wenn das mal jemand in die Metadaten-Dateisuche (DBFS) von z.B. KDE einbauen könnte.
Weitere Infos:... I would wish to have such a product for Linux. Editor application, filesystem database, and so on ... (just dreaming).
Some people are on the right way:
http://ozy.student.utwente.nl/projects/dbfs/
http://www.gnome.org/~seth/storage/
[..].kde.org/cfp-devconf/scott.wheeler-search.metadata.interface.elements.php
> "It is based on the XMP model, which supersedes IPTC ..."
Das ist das Problem. XMP ist schick, aber im etablierten Workflow noch nicht etabliert
Ansonsten ist die Behauptung, dass XMP in naher Zukunft IPTC (IIM) ablösen oder überflüssig machen wird, einfach nicht wahr. Die verbreiteten IPTC-Texteditoren für die Massenbeschriftung im Agenturgeschäft unterstützen noch kein XMP. Und dann müssen die Datenbanken angepasst werden - und das sind alles keine XML Datenbanken.
Dasselbe Problem trifft auch auf das Dateiformat JPEG 2000 zu.
Die ganze digitale Verarbeitungskette vom Fotografen bis in die Bildredaktion basiert derzeit auf JPEG (RGB) + IPTC (IIM).
Markus
http://talks.blogs.com/phototalk/2004/09/getty_images_an.html
Also ähnlich XMP-by-Adobe und IPTC-a-la-Photoshop ein weiterer Beitrag Adobes zur weiteren Verwirrung der Formate und der Pseudo-Standardisierung aufgrund von "Photoshop ist Standard". Standardisierung per Presse- und Absichtserklärung - klingt bekannt (XML-a-la-M$), oder? Passendes (teures) Produkt dazu und fertig.
Adobe hat aus dem Urgedanken IPTC (Envelope mit tagged Content) bzw. XML (Dokument mit tagged Content) ein eigenes nicht Standard konformes Produkt kreiert, das Content binär in den Header einer Datei packt. Besser wäre es natürlich den Content XML konform in ein Dokument als Markup reinzupacken und es jedem freien Parser zu überlassen, welche Content-Bestandteile er denn auslesen, benutzen, hinzufügen oder verändern möchte.
So kann man den XML Gedanken natürlich auch pervertieren ... oder das Produkt per Marketing zum "Standard" erklären.
Markus