ubuntuusers.de

Können wir gerne, bin nur nächste Woche nicht online... von daher: Fertigstellungsdatum eher Ende Juni 😉

OK. Sofern du auf dem TT bist können wir das gemeinsam dort erledigen. Ansonsten Anfang Juli.

Servus ☺

habe mal angefangen, finde aber keinen „roten Faden” 😬

march bitte bring mal Struktur rein, ich schaffe es nicht...

Gruß
kaputtnik

Sofern ich Zeit habe helfe ich dir - muss heute Arbeiten... Ein wenig hatte ich schon ergänzt.

Edit: Ich habe einiges umgestrickt und neue/fehlende Informationen ergänzt. Lediglich die Punkte unter Hilfsmittel habe ich noch nicht überprüft bzw. überarbeitet. Schaue einmal drüber.

Edit2: Erst einmal fertig. Bei KDE muss ich noch nach Alternativen schauen. Ist mein Weg bei Gimp soweit OK bzw. verständlich beschrieben? Alternativen?

Hallo,

bei PNGs fehlt noch, dass man diese indizieren kann (soll). Zumindest beim Standardthema von Gnome und Unity (und AFAIK auch Xfce) ist eine Indizierung auf 128 Farben (oder gar 64) in der Regel überhaupt kein Problem, spart aber massig Platz.

Aufgrund der Farbverläufe bei KDE kann Indizierung manchmal schwierig sein... Baue die Tag was dazu ein.

BTW: Was bringt denn Transparenz? Das Bild wird dadurch IMHO nicht kleiner, oder?

Gruß, noisefloor

BTW: Was bringt denn Transparenz? Das Bild wird dadurch IMHO nicht kleiner, oder?

Schaue dir die Beispiele an. Je nachdem wo ein Bild verwendet wird sieht es bescheiden aus, wenn die Ecken in bunten Farben zu sehen sind. Deshalb bearbeite ich dies immer - auch bestehende Screenshots.

bei PNGs fehlt noch, dass man diese indizieren kann (soll). Zumindest beim Standardthema von Gnome und Unity (und AFAIK auch Xfce) ist eine Indizierung auf 128 Farben (oder gar 64) in der Regel überhaupt kein Problem, spart aber massig Platz.

Speicherplatzprobleme haben wir doch keine mehr - aber man kann es natürlich hinterlegen. Zu KDE wollte kaputtnik noch evtl. etwas beitragen, da das ursprünglich erwähnte Programm bei der beschriebenen Prozedur wohl nicht wirklich etwas taugt. IMHO wollte er sich krita anschauen.

Ist die restliche Überarbeitung von mir ansonsten verständlich? Habe es komplett umgeändert.

Edit: Den alten Teil über die indizierung unter Gimp habe ich wieder eingepflegt. Die Screenshots ändere ich noch und formuliere ggf. den Text um.

march schrieb:

BTW: Was bringt denn Transparenz? Das Bild wird dadurch IMHO nicht kleiner, oder?

Schaue dir die Beispiele an. Je nachdem wo ein Bild verwendet wird sieht es bescheiden aus, wenn die Ecken in bunten Farben zu sehen sind. Deshalb bearbeite ich dies immer - auch bestehende Screenshots.

Hmmm... so bunte Ecken tauchen bei mir nicht auf.

bei PNGs fehlt noch, dass man diese indizieren kann (soll). Zumindest beim Standardthema von Gnome und Unity (und AFAIK auch Xfce) ist eine Indizierung auf 128 Farben (oder gar 64) in der Regel überhaupt kein Problem, spart aber massig Platz.

Speicherplatzprobleme haben wir doch keine mehr - aber man kann es natürlich hinterlegen.

Na ja, es geht ja nicht nur um den Platz sondern auch um den traffic 😉

Zu KDE wollte kaputtnik noch evtl. etwas beitragen, da das ursprünglich erwähnte Programm bei der beschriebenen Prozedur wohl nicht wirklich etwas taugt. IMHO wollte er sich krita anschauen.

Jo, Kolourpint macht bei einer Indizierung (256 Farben) bei KDE-Screenshots entweder fiese Farbverläufe oder es rauscht.

Krita habe ich probiert: Da geht überhaupt keine Indizierung. Außerdem wird dabei das komplette KOffice installiert ☹

Ist die restliche Überarbeitung von mir ansonsten verständlich? Habe es komplett umgeändert.

Jo, ein paar Kleinigkeiten ändere ich noch.

Edit: Den alten Teil über die indizierung unter Gimp habe ich wieder eingepflegt. Die Screenshots ändere ich noch und formuliere ggf. den Text um.

👍

Auch der Teil per Kommandozeile sollte wieder rein.

Hmmm... so bunte Ecken tauchen bei mir nicht auf.

Ich weiß leider nicht mehr ob es bei Lucid oder Natty war. Sowie bei einigen Vorläufern. Beim Screenshot hatte ich unter Gnome da Probleme. Der hochgeladene Screenshot ist aber ein Fake, da ich seitdem nur Shutter verwende. Zur Demonstration ist dies aber unwichtig. Es geht ja nur um die (visuelle) Information dazu.

Na ja, es geht ja nicht nur um den Platz sondern auch um den traffic 😉

Jajaja. 😉

Jo, ein paar Kleinigkeiten ändere ich noch.

Danke. ☺

Auch der Teil per Kommandozeile sollte wieder rein.

Ja - diesmal auch mit einem Verweis auf den Wissensblock. 😉 Wollte nur getestete Programminformationen aufnehmen und nicht blind kopieren. Deshalb kam von mir bisher nur Gimp.

Hallo,

haben noch ein paar kleine Änderungen am Text gemacht.

Sonst IMHO ok.

Gruß, noisefloor

Gimp + Terminal mache ich bis morgen Abend fertig.

Edit: Ich habe die neuen Screenshots eingefügt und Gimp/Terminal überprüft. Terminal ist nun ebenfalls wieder drin und die Kompressionsbeispiele habe ich verschoben. Hoffe es paßt so. Fehlt nur noch KDE.

N'abend allerseits.

Ich habe ehrlich gesagt so meine Probleme mit dem Text unter Baustelle/Bildschirmfotos (Abschnitt „Berarbeitung“):

Transparenz bei png überprüfen...

Versteh ich nicht? Also mir persönlich ist schon klar, was gemeint ist, aber der Masse der Lesenden wohl eher nicht. Da helfen auch die beiden Grafiken kaum.

...und eine Indizierung auf 256 Farben bzw. 128 Farben anstreben.

Nur bei png oder auch für jpg?

Dies reduziert die Dateigröße, spart Speicherplatz und Netzwerkverkaeht.

Von dem Tippfehler mal abgesehen, gilt das nur für die Indizierung soweit ich weiß. Da der Satz vorher mit und verknüpft ist, wird hier aber impliziert auch die zu überprüfende Transparenz würde zu kleineren Dateigrößen führen. Das ist AFAIK nicht der Fall.

Es ist lediglich darauf zu achten, dass Original und Bearbeitung sich optisch nicht großartig unterscheiden.

Sehr schwammig. Wer legt das fest. Indizierungen auf 128 Farben lassen sich häufig mit bloßem Auge erkennen. Zumindest ein bis zwei Grenzfall-Beispiele wären hier schön. Also was geht und was geht nicht mehr als Beispielbild. Sonst ist das von jemanden ohne große Grafik-Erfahrung kaum zu beurteilen. Dem wird so gar der Hinweis "pixlig" nicht wirklich weiter helfen.

Bei jpg einen Kompressionsgrad von 75 nutzen.

Warum gilt das nicht auch für png?

Schatten wird nie verwendet.

Gehört das wirklich unter Bearbeitung? Oder nicht eher weiter nach oben?

Damit der Kritik auch ein konstruktiver Moment innewohnt, hab ich mal eine einfachere und übersichtlichere tabellenbasierte Lösung unter Baustelle/Bildschirmfotos (Abschnitt „Zusammenfassung“) eingestellt. Dazu vielleicht noch ein Link auf eine Anleitung zur Indizierung und Komprimierung, ein kleiner Text mit dem Hinweis auf Grenzfälle (Wie pixlig darf es sein? inkl. 2 Bilder (geht / geht nicht) und Wie stark soll ich indizieren? wieder inkl. 2 Bilder (geht / geht nicht)) und den Lesenden ist mehr geholfen als mit der Aufzählung.

Liebe Grüße

martin

Versteh ich nicht? Also mir persönlich ist schon klar, was gemeint ist, aber der Masse der Lesenden wohl eher nicht. Da helfen auch die beiden Grafiken kaum.

Kannst du uns helfen das klarer zu formulieren?

Damit der Kritik auch ein konstruktiver Moment innewohnt, hab ich mal eine einfachere und übersichtlichere tabellenbasierte Lösung unter Baustelle/Bildschirmfotos (Abschnitt „Zusammenfassung“) eingestellt. Dazu vielleicht noch ein Link auf eine Anleitung zur Indizierung und Komprimierung, ein kleiner Text mit dem Hinweis auf Grenzfälle (Wie pixlig darf es sein? inkl. 2 Bilder (geht / geht nicht) und Wie stark soll ich indizieren? wieder inkl. 2 Bilder (geht / geht nicht)) und den Lesenden ist mehr geholfen als mit der Aufzählung.

Das ist eine gute Idee. ☺

Hallo,

Bei jpg einen Kompressionsgrad von 75 nutzen.

Warum gilt das nicht auch für png?

Weil PNG Kompressionsstufen von 1-9 hat 😀 Das wird später auch erklärt.

BTW: die Tabelle unter Zusammenfassung stimmt deshalb auch nicht.

Gruß, noisefloor

march schrieb:

Kannst du uns helfen das klarer zu formulieren?

Vorschlag ist im Artikel.

Das ist eine gute Idee. ☺

ebenfalls im Artikel..

noisefloor schrieb:

BTW: die Tabelle unter Zusammenfassung stimmt deshalb auch nicht.

Hab ich verbessert. 😉

Servus ☺

schöne Tabellen ☺

Wir sollten allerdings die Beschränkung auf 800x600 aus dem Artikel nehmen. So ist dieser Screenshot schon 1031x799 Pixel groß... In der Regel werden die Bilder ja eh automatisch verkleinert per Thumbnail eingebunden.

Zu KDE: Es gibt AFAIK kein Programm für KDE mit welchem man „gut” indizieren kann. Allerdings sind die Screenshots die ich so mache in der Regel schon relativ klein. Ich bearbeite diese nicht weiter und lade sie so wie sie sind einfach hoch. Durch die Verkleinerung von Inyoka gibt es dann nochmal eine Verringerung der Dateigröße.

Ich wollte jetzt die Beispielbilder zu Bildgröße machen, aber selbst bei Indiziereung mit 64 Farben sieht man keine markanten Unterschiede. Es erscheinen zwar ein paar Streifen aber keine Fehlpixel oder krasse Farbfehler.

Die Beispielbilder zum KDM-Theme sind total veraltet. Evtll sollte man diese mit Bildern vom aktuellen GNOME ersetzen, nicht das der Artikel zu KDE-lastig wirkt 😀

Gruß
kaputtnik

schöne Tabellen ☺

+1

Wir sollten allerdings die Beschränkung auf 800x600 aus dem Artikel nehmen. So ist dieser Screenshot schon 1031x799 Pixel groß... In der Regel werden die Bilder ja eh automatisch verkleinert per Thumbnail eingebunden.

Einen Hinweis, dass Screenshots von Spielen mind. diese Größe haben sollten wäre IMHO angebracht. Man bedenke die Fehler aus der Vergangenheit. Einige Screenshots sind deshalb zu klein (s. Ubuntu-Spiele).

Die Beispielbilder zum KDM-Theme sind total veraltet. Evtll sollte man diese mit Bildern vom aktuellen GNOME ersetzen, nicht das der Artikel zu KDE-lastig wirkt 😀

Lade ruhig ein paar vom neuen KDM-Theme hoch. ☺ Wobei Gnome fast gar nicht mehr vorhanden ist. Xfce dominiert. 😉