Sprich die Bilder die in 16 Farben erstellt wurden sehen in der Regel sehr viel
besser aus, als welche die erst zwischendrin das volle Farbtiefenprogramm
erhalten haben und dann die Paletten zerstört sind.
Lukas hat das schon erkannt. Es muss das Originalmaterial sein und zwar
unbearbeitet.
Sorry, aber das verstehe ich nicht ganz. Die Palette ergibt sich doch durch die eindeutigen Farben in den Bildern, was soll da zerstört sein - außer der Paletten-Einträge die eh nicht genutzt werden?
Ist das nicht vielleicht eher ein Problem das aus 2 Gegebenheiten resultiert:
1.) das Farbwerte im VDI mit 1000 Werteeinheiten (2 Byte pro Farbkomponente) arbeiten, aber unter normalen PC's bis jetzt mit 256 Werteeinheiten (1 Byte pro Farbkomponente)?
2.) Das die Farbpallete eines ST's auf 512 eindeutige Farben "limitiert" ist. Natürlich dürfen in der 16 Farben Palette eines Bildes (also im GIF Format) nur Farben auftauchen die diese 512 Farben Palette "erlaubt". Wenn andere Palletteneinträge exisitieren, dann müssten die korrigiert werden: sprich zum nächstbesten Wert der ST Farbpallete umgewandelt werden.
Natürlich muß beim Anzeigen eines Bildes die korrekte Farbpalette eingestellt sein... aber wenn man von der Farbpallete des GEM ausgeht (nur ein Beispiel, ich weiß das bei den Bildern über die gesprochen wird eine ganz andere gesetzt sein kann), dann habe ich das folgendermaßen gemacht:
- Screenshot von der Farbpallete im Resource-Master gemacht (mit Aranym)
- Dieses Bild als Farbpalette in GIMP importiert
- Beim konvertieren eines True-Color Bildes (oder whatever, 256 Farben z.B), diese Palette angegeben...
- Das Bild wurde korrekt dargestellt, wenn ich es z.B. als Icon in einer RSC Datei verwendet habe.
Ein ähnliches Prozedere, sollte doch auch in allen anderen Situationen funktionieren. Benötigt allerdings die 512er Farbpallete des ST's in GIMP. Und wenn man dann das Bild auf 16 Farben reduziert, sollte GIMP imo die richtigen Paletten-Einträge für das GIF setzen...
