Ich arbeite auch mit größeren Charakterportraits, die ich mit einem Grafiktablett zeichne. Bei mir sind die allerdings im Endprodukt "nur" ungefähr popelige 200x170 Pixel groß. Ich weiß nicht genau, wie und ob Gimp das auch kann, aber wenn du das Bild auf die nötige Größe skallierst und dann noch mal mit einem leichten Schärfefilter drübergehst (bei Bedarf auch nochmal mit Kontrast- und Farbreglern spielen) sollte das Ergebnis eigentlich ganz ordentlich werden. Den Rand musst du dann wahrscheinllich nochmal nachpixeln, weil beim Verkleinern weiche eklige Übergänge entstehen. Aber ansonsten sind solche Charakterportraits keine große Zauberei.
Keine Ahnung ob dir das vielleicht weiterhilft, aber im allgemeinen Tutorialthread habe ich mal ein Video hochgeladen, wie ich meine Portrait- und Monstergrafiken mache. Ich arbeite da mit dem RPG Maker 2000, dürfte aber kein großer Unterschied zum 2003er sein.
Edit: Welp, führ dir einfach mal das hier zu Gemüte, das ist vielleicht sogar noch anschaulicher
Geändert von Sabaku (16.05.2013 um 16:49 Uhr)
Was genau hat es denn bitte mit der Qualität von Gimp zu tun, wenn der Maker beim Öffnen von Pictures mit weniger als 256 Farben rumspackt?Das ist ein Problem des Makers, nicht vom Gimp. Denn Corti hat hier vollkommen recht. Wenn ich eine Datei indizieren will, in der nur 4 Farben vorkommen, dann brauche ich auch nur einen Index mit der größe von 4. Den würde der Maker aber nicht akzeptieren.
Wenn ich ein Schwarz-Weiß-Bild mit einer Farbtabelle mit 2 farben indiziere, dann kann jedes beschissene Programm diese Grafikdatei öffnen. Nur der Maker kann es manchmal nicht, weil der unbedingt 256 Farben im Index will. Und das bedeutet, dass Gimp den Index der Datei beim Abspeichern mit irgendwelchem Müll füllen muss, der zwar überflüssig ist und nur die Dateigröße erhöht, den der Maker aber braucht, um das Dateiformat korrekt zu erkennen.
Und ... nein. Ich habe bestimmt 5 Jahre lang mit dem 2k3 gearbeitet, und mir ist es nie passiert, dass eine korrekt indizierte datei vom maker nicht erkannt worden wäre.
Das eine Erkennung unmöglich war, trat immer nur dann ein, wenn ich versehentlich mit 255 Farben indiziert hatte.
Klar ist das ein Problem von GIMP. Ich stell ein, dass ich eine Farbreduzierung auf "256 Farben" haben will und wenn GIMP dann willkürlich entscheidet, dass auch weniger ganz okay sind, dann ist das halt beschissen. Im Gegensatz dazu: Irfan View reduziert die Farben auf schäbigste Art und Weise, aber zumindest immer auf exakt 256 Farben, wenn ich das so einstelle. Wenn ich bei Photoshop einstelle, dass ich 256 Farben will, dann reduziert das Programm die Farbtiefe auch, wie von mir gewünscht, auf die dämlichen 256 Farben. Alles cool, alles bestens. Nur GIMP macht das nicht.
War bei mir früher auch so, dass ich da ab und zu nicht drauf geachtet hab. Wie gesagt, mittlerweile tritt das Problem allerdings auch ein, wenn ich auf 256 Farben reduziere, da sich GIMP mit der Beschreibung "Maximale Anzahl der Farben" wahrscheinlich vorbehält, das Ding irgendwie random zu skalieren, solange es die 256 Farben nicht überschreitet.Zitat
Die einzige Situation, in der Gimp trotz einstellung die 256 nicht voll macht, ist wenn das Bild extrem wenig Farben hat. Z.B. wenn du eine zweifarb-Datei auf 256 Farben aufblasen willst. Abhilfe schafft es hier, wenn du eine unsichtbare Ebene anlegst, und da einen Plama-Filter drauf anwendest, um die Anzahl der Farben in der Datei zu erhöhen. Das ist auch kein magel, sondern einfach ein Zeichen dafür, das die Programmierer mitgedacht habenDenn das absolute erzwingen von 256 Farben ist unsinnig.
Es ist vielmerh grundsätzlich sinnvoll, einen Farbindex nur mit so vielen Farben anzulegen, wie auch tatsächlich notwendig sind. Denn ein 256-Farben-Index in einem 2 Farb-Bild ist absolutuer Blödsinn, weil die Datei nur durch unnötige Dateneinlagerung vergrößert wird. Angesichts der Tatsache, das jedes einzelne Programm auf diesem Planeten dazu in der Lage ist, ein indiziertes PNG zu öffnen, egal ob der Farbindex 2 Farben hat, oder 256 Farben, ist es eindeutig ein Mangel des makers, wen dieser nicht dazu in der Lage ist, mit einem Farbindex mit weniger als 256 Farben umzugehen.
Wenn Shell plötzlich auf die Idee kommt, an ihren Tankstellen neue Tankstutzen einzusetzen, die in eine Handelsübliche Tankklappe nicht mehr reinpassen, dann ist das auch nicht die Schuld von VW, das die VW-Fahrer nicht mehr bei Shell tanken können![]()
Dennoch möchte ich als Nutzer die Möglichkeit haben es anders machen zu können. Eben so wie ich will. Oder in dem Fall wie ich muss. Wie schon gesagt: Photoshop kann das, Irfan View kann das. GIMP nicht. Ich brauch kein Programm, das mir in diesem Ausmaß das eigene Denken abzunehmen versucht und mir aufgrund dessen ein Ergebnis liefert, mit dem ich nix anfangen kann. Sinnvoll hin, sinnvoll her.Zitat
Hier absolute Zustimmung.Zitat
Anhang 17807Zitat
Anhang 17808
Anhang 17809
:enton:
Oder habe ich jetzt was falsch verstanden?
--"Banjo, you're a BEAR... and I will teach you... THESE MOVES!"
Es wär voll geil, würde Two Face einen Gimpproblemthread aufmachen und man sich stattdessen dem eigentlichen Problem widmen.
Also nicht dass ichs nicht interessant finde, wenn er sich wiederholt, aber bevor er nochmal fragt, wie er die Performance in seinen Common Events verbessern kann,(nichts für ungut)würde ich lieber mal ganz neugierig den Threadersteller fragen, ob er nicht eines seiner Artworks zeigen möchte.
Na herzlichen Dank, jetzt bin ich völlig raus. O.o
Ich hab die Diskussion nicht angefangen. Und keine Sorge, ich hab meine Problemchen mit GIMP schon vor langer, langer Zeit souverän gelöst, dadurch, dass ich einfach kein GIMP mehr benutze. Easy.
Aber ja, zurück zum eigentlichen Thema.![]()
Geändert von TwoFace (16.05.2013 um 18:52 Uhr)
Ich habe jetzt eine ganz gute Möglichkeit gefunden:
Das Herunterskalieren mit PAINT.NET funktioniert großartig, weil man die die Auflösung hochstellen kann
Ich hatte noch nie diese Probleme mit Gimp, wenn ich die Indizierung auf 256 stelle, macht er das auch brav. Auch sonst bin ich mit Gimp ziemlich zufrieden; vielleicht ist Photoshop besser, aber wahrscheinlich nicht so viel besser, als das es sich lohnte, den Preis zu bezahlen.
Hier mal das Ergebnis (bitte nicht das Mapping beachten, ist sehr hässlich, da nur zu Testzwecken).
Vorher, mit Gimp skaliert:
Nachher, mit Paint-Net:
Ich hoffe, ich habe das mit dem Hochladen richtig gemacht...
------- unkreativen Kommentar hier einfügen ------
Na bitte, das schaut doch sehr hübsch aus.
--CortiWins GitHub DynRPG < Charguide < [2k3] Zahlen und Werte < [2k3] Kurven als Wertetemplates < [2k3] DynRPG Werkstatt
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Hello from the otter side
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ஜ۩۞۩ஜ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
Seh ich auch so. Schaut wunderbar aus.
zu dem bild "vorher mit gimp skaliert":
es sieht so aus, als hättest du die ebenen vor dem indizieren nicht zusammengefügt, dadurch wird aus der ganzen transparenz, die da drin war so eine pixelscheiße. ich würde das vielleicht nochmal versuchen, weil, ich mache mit gimp auch keine schlechten erfahrungen. außer, dass es eben wie angesprochen bei wenig-farbigen bildern die bilder dann wirklich nicht mehr makerkompatibel konvertiert.
ansonsten kann es auch helfen, nach dem skalieren nochmal mit kleinen pinseln nachzuarbeiten, zB an so kritischen stellen wie den augen oder so, die einem besonders wichtig sind.
und btw: schöne grafik ^^
Ich habe mir noch einmal das Original geschnappt, und mal speziell drauf geachtet, ob ich die Ebenen zusammengefügt habe, und es dann noch einmal probiert.
In der Tat ist das Ergebnis etwas besser, aber noch immer schlechter als das von Paint.NET, also wird das wohl das Skalierprogramm meines Herzens bleiben..
Wirklich merkwürdig, ich war sicher, ich hätte die Ebenen schon vorher zusammengefügt...
Btw: Danke.![]()
------- unkreativen Kommentar hier einfügen ------