Photoshop & D2x

[volkerm]

Was mich bei der CAD Geschichte verblüfft hat war, daß man die ursprünglichen Vektordaten als TIFF Bitmap archiviert. Das fand ich vom Konzept her etwas strange, ist offenbar aber üblich.

Verlustlose Kompression à la ZIP wäre ja wohl auch kein unwiederbringliches Geheimnis, wenn es denn komrimiert werden soll.

[e5000]

Moin,

ich verfolge jetzt hier und in anderen Foren gespannt diese Diskussion ...

Ich gebe zu, mein Verhältnis zu Adobe ist etwas gestört. Adobe hat sich sehr gut an M$ angeglichen. Firmen und damit Produkte werden aufgekauft, teure Supportverträge übernommen und nichts dafür getan! Dann wird die Weiterentwicklung offiziell eingestellt unter der Ankündigung es wird irgendwann mal ein Nachfolgeprodukt geben Ich rede hier nicht von solch Konsumerprodukten wie Photoshop Allein für die jährlichen "Supportgebühren" könnte man Photoshop fast 7 mal kaufen, zum Listenpreis

Wenn ich mir dann vorstelle, Adobe wird zum Herren aller Raw Formate

Das Dilemma mit den unterschiedlichen RAW Formaten hat IMHO Mario Westphal, der Programmier von IMatch, hier sehr gut beschrieben.

Nikon, es ist noch viel zu tun Dann kann das mit dem SDK auch noch was werden ....

[lemonstre]

Wenn ich mir dann vorstelle, Adobe wird zum Herren aller Raw Formate

der erfolg von adobe basiert doch allein auf dateiformaten! eps, tiff, pdf, postscript sind doch nur deshalb so erfolgreich weil adobe immer dafür gesorgt hat das diese eine weite verbreitung bekommen und zwar nicht nur in der eigenen software. das sie das nicht uneigennützig machen ist wohl jedem klar.

mich als user interessiert allerdings nicht der geschäftsbericht von adobe sondern lediglich das meine daten immer und überall gelesen werden können und ich aus einer breiten palette an werkzeugen wählen kann.

meinetwegen ergreift auch jemand anders die chance und entwickelt ein eigenes offenes datenformat... das man damit gutes geld verdienen kann hat adobe mehrfach eindrucksvoll bewiesen mir soll auch das recht sein...

[WilfriedF]

Das Problem der Datensicherung in die Zukunft ist ein interessantes. Weil wir zwar über einen beschränkten Zeitraum der Vergangenheit wissen wie das gelaufen ist, jedoch fehlt uns naturgemäß jede wirkliche Vorstellung wie die Sache denn in der fortlaufenden Geschichte aussehen könnte.
Sobald eine Darstellung einen gewissen Grad an Abstraktion überschreitet, wird es für sehr viel später Nachfolgende schwierig dieses Zeugs, so es die Jahrhunderte überdauert hat zu interpretieren. Ich vermute mal so ins Blaue, daß in 5000 Jahren die überlebenden Bilddateien nicht schwieriger zu entziffern sein werden als die Sprachen auf dem Stein v. Rosette oder in Ton geritzte Keilschrifttafeln. Natürlich stellt sich die Frage der Datensicherheit, jedoch ist bei heutigen Daten nicht die Frage wie lange das einzelne Medium überlebt, wie das begonnen von Höhlenmalereien über Tontafeln bis zu Pergament u. Papyrosrollen die Frage war, sondern es ist bei der unterschiedlich einfachen, sehr viel einfacheren Vervielfältigbarkeit heutiger, hoch abstrahierter Darstellungen mehr die Frage wie weit verbreitet, wie oft kopiert die wichtigsten Binärcodes sein müssen um auch nur in der geringen Dichte in der uns aus alter Zeit überkommenen Dokumente vorzuliegen, um für zukünftige Generationen auffindbar und verwertbar zu sein. Ich vermute jetzt einmal daß es kaum weniger sein werden als uns aus unserer Vorzeit vorliegen. Man muß sich bei der Debatte um Datenformate, Lesbarkeit, Archivierung schon vor Augen halten, daß auch die uns überlieferten Daten nur einen winzigen Bruchteil eines tausendstel Promilles der jemals festgehaltenen Aufzeichnungen handelt. Und vieles davon ist nur mühsam entzifferbar, womöglich gänzlich unbrauchbar wie Sprache, oder auch hoch abstrahierte Schriften die bis heute der Entzifferung harren. Davon sind bildliche Darstellungen beileibe nicht ausgenommen. Wir sehen zwar oftmals Konturen, Striche Farben, können aber über die Aussage, den Gehalt, den innewohnenden Sinn oder die Bedeutung dieser Bilder bloß Vermutungen anstellen, oder oftmals nicht einmal dieses. Insofern sehe ich die neuzeitlichen Formen der Archivierung keineswegs als im Nachteil gegenüber historischen Methoden an. Es ist keineswegst schlüssig darzustellen warum nicht silberbeschichtete Datenträger ebenso (dürftig) lesbar erhalten bleiben sollen wie ein paar Pergamentrollen in einer Höhle am Toten Meer( ebenso dürftig erhalten).Vor diesem Hintergrund finde ich den entbrannten Streit um *.NEF oder *.wasweißich einfach nur absurd, soweit man sich um spezifische Dateiformate dabei Sorgen macht. Die Frage ist vielmehr ob künftige Generationen den in irrsinniger Menge hergestellten Informationsmüll überhaupt jemals sehen/lesen/hören wollen.

Sicher ist allerdings auch, daß es bei dem Streit Adobe vs. Nikon einzig und alleine um Kohle geht, um sehr viel Kohle. Wenn mir auch nur einer der Kontrahenten weißmachen will daß er nur und ausschliesslich im Sinne des p.t. Konsumenten handelt ist er damit der Lüge überführt. Um uns Verbraucher gehts' dabei schon lange nicht mehr. Wer sich vom Fußvolk da so oder so vor einen Karren spannen lässt hat schon verloren. Definitiv.

[vkyr]

...
der erfolg von adobe basiert doch allein auf dateiformaten! eps, tiff, pdf, postscript sind doch nur deshalb so erfolgreich weil adobe immer dafür gesorgt hat das diese eine weite verbreitung bekommen und zwar nicht nur in der eigenen software. das sie das nicht uneigennützig machen ist wohl jedem klar.
...

Also PostScript und Encapsulated PostScript aka Display PostScript sind schon mal per se keine Dateiformate im ursprünglichen Sinne, sondern vielmehr interpretierte geräteunabhängige Computersprachen und auch PDF als weitere PostScript Untermenge ist kein herkömmliches Dateiformat, denn dieses wird auch interpretiert. - Die Entwicklung von Display PostScript z.B. wurde 1985 (zu der Zeit kamen nebenbei bemerkt auch die ersten Drucker mit integriertem PostScript Interpreter auf den Markt) zusammen von Adobe und NeXT begonnen und 1988 das erste mal in einem Computer System, nämlich dem NeXTstep Betriebssystem des NeXTcube integriert. Ich habe früher einige Jahre für NeXT-Systeme u.a. auch in Display PostScript mit entsprechenden Interpretern programmiert.

Wenn Du heutzutage sagen wir mal in Python, Perl, Ruby oder weiß der Geier was programmierst dann redest Du auch nicht von einem Dateiformat in dem Sinne wie Du es wahrscheinlich gemeint hast. Dateiformate im ursprünglichen Sinne sind demnach mehr TIFF- (tagged image file format), PNG, JPG etc.

Das obige mag nun etwas kleinlich oder pedantisch klingen, aber PS, EPS und auch PDF sind nun mal in dem Sinne kein banalen Dateiformate. Wer sich das klar macht, dem leuchtet auch der Umstand besser ein, warum Adobe da so führend und erfolgreich mit ist. Denn es ist gerade nicht so trivial diese Interpreter-Sprachen genau in dem Umfang zu unterstützen wie deren Erfinder es dank seiner jahrelangen Erfahrung kann.

Darüber hinaus basiert der Erfolg von Photoshop weiß gott nicht nur allein auf irgendeinem Dateiformat, sondern viel mehr um sehr viel KnowHow in Punkto Bitmap-Grafiken, Farbmanagement, Grafikworkflow usw. usf. Zumindest in diesem Punkte muß ich Adobe direkt mal in Schutz nehmen, denn von der Bearbeitung von Vektor- und Bitmapgrafiken verstehen die mehr als so manche andere Software-Schmiede.

[lemonstre]

Also PostScript und Encapsulated PostScript aka Display PostScript sind schon mal per se keine Dateiformate im ursprünglichen Sinne, sondern vielmehr interpretierte geräteunabhängige Computersprachen und auch PDF als weitere PostScript Untermenge ist kein herkömmliches Dateiformat, denn dieses wird auch interpretiert.

die vermischung von daten und strukturierenden elementen liegt aber eher in der natur von vektorbasierten daten. und auch ein word dokument enthält mehr informationen als nur den reinen text. dadurch wird das word format aber noch lange nicht zu einer seitenbeschreibungs oder gar programmiersprache

zur definition des begriffs dateiformat empfehle ich, wie immer wikipedia:
http://de.wikipedia.org/wiki/Dateiformat

Ein Dateiformat oder Dateityp bestimmt die Form der Abspeicherung von Computerdaten. Die Notwendigkeit hierfür entspringt aus der Tatsache, das für ein Betriebssystem Dateien gewöhnlich nur eindimensionale Aneinanderreihungen von Bytes sind. Solche beschränkten, linearen Strukturen können aber viele Arten von real anfallenden Daten nicht in einer offensichtlichen Weise beschreiben, sodass Konventionen ihre Interpretation als Repräsentanten von komplexeren Daten bestimmen. Eine Gesamtheit solcher Konventionen für eine "Art" von Dateien wird als Dateiformat bezeichnet.

demnach ist postscript und co sehr wohl ein dateiformat, da struktur und daten fest miteinander verknüpft sind und, anders als bei programmiersprachen wie z.b. perl etc., sie allein keinen sinn ergeben.

soweit der off topic exkurs...

[vkyr]

die vermischung von daten und strukturierenden elementen liegt aber eher in der natur von vektorbasierten daten. und auch ein word dokument enthält mehr informationen als nur den reinen text. dadurch wird das word format aber noch lange nicht zu einer seitenbeschreibungs oder gar programmiersprache

Mit Word kannst Du in dem Sinne ja auch nicht programmieren, mit Postscript und Display Postscript schon. Nur mal ein kleiner Einblick in DPS...

http://www.id.unizh.ch/publications/ps/dps.html

..oder wenn Du lieber Adobe's eigene Beschreibung hättest (kleiner Auszug aus einem der x Adobe 500 Seiten Wälzer in meinem Regal aus alten Tagen...

The Display PostScript system provides a device-independent imaging model for displaying information on a screen. This imaging model uses the PostScript language to bring powerful graphics capabilities to the display and is fully compatible with the model found in PostScript printers.
...
...
The Display PostScript system uses a client-server architecture. Applications are the clients that make use of the PostScript Interpreters in the server. Applications communicate with the server through the data structures and procedures in the Client library. The Client Library is consitent across all Display PostScript systems, so you can send PostScript language calls in the same way across a variety of platforms. With the pswrap translator, you can create custom PostScript language programs with C-callable interfaces.
...
...
The application sends and receives PostScript language operations to and from the server. Typically, these operations perform some form of imaging, but PostScript language is a is a full programming language, so they are not restricted to imaging operations. The operations are sent and received through single-operator calls in the Client Library or through custom wraps created with the pswrap translator.
...
..and so on...
...

...
demnach ist postscript und co sehr wohl ein dateiformat, da struktur und daten fest miteinander verknüpft sind und, anders als bei programmiersprachen wie z.b. perl etc., sie allein keinen sinn ergeben.

Das obige klingt für mich etwas sehr verwirrend, wo bitte soll der konkrete Unterschied im Hinblick auf Perl sein...?

Naja, fragen wir mal anders, was ist denn Deiner Meinung nach dann das hier, also keine Interpreter-Programmiersprache a la Perl und Co. ...

defineps PSWGrayCircle(float x, y, radius)
newpath
x y radius 0.0 360.0 arc
closepath
0.5 setgray
fill
endps



defineps PSWCountExecStack(| long int *n)
countexecstack n
endps

...

[lemonstre]

defineps PSWGrayCircle(float x, y, radius)
newpath
x y radius 0.0 360.0 arc
closepath
0.5 setgray
fill
endps

struktur und daten sind fest miteinander verwoben... das ganze würde ohne den daten teil keinen sinn machen und wäre nutzlos:

defineps PSWGrayCircle(float x, y, radius)
newpath
x y radius 0.0 360.0 arc
closepath
0.5 setgray
fill
endps

postscript ist also aller höchstens eine seitenbeschreibungssprache und ähnelt eher html&co als einer programmiersprache...

edit: jetzt wird es akademisch... also genug off topic

[vkyr]

Sorry, aber das ist absoluter Quatsch, denn folgendes Java Fragment würde ohne den deklarierenden Datenteil auch null Sinn machen...

public class ShapeExample extends JPanel {
private Ellipse2D.Double circle =
new Ellipse2D.Double(10, 10, 350, 350);
private Rectangle2D.Double square =
new Rectangle2D.Double(10, 10, 350, 350);

public void paintComponent(Graphics g) {
clear(g);
Graphics2D g2d = (Graphics2D)g;
g2d.fill(circle);
g2d.draw(square);
}
...

Und um mal auf den initialen Kritikpunkt der Begrifflichkeit zurückzukommen, Adobe hat mit Postscript und Display Postscript keine Dateiformate per se geschaffen sondern viel mehr Sprachen.

Dem Postscript Interpreter ist es egal ob er seine Anweisungen aus einer Datei oder einem Bytestream bekommt, darüberhinaus kannst Du diesen z.B. bei DPS auch vollkommen Interaktiv bedienen, sprich Anweisung für Anweisung eintippen und abarbeiten lassen, genauso wie mit anderen Sprachinterpretern z.B. Basicinterpretern usw. auch. Der Interpreter erhält somit auch keine fest vorgegebenen statischen Offsetpunkt-Dateiformatangaben wie z.B. "Tagged Image File Format", PNG etc., sondern viel mehr eine Folge von Anweisungen welche er abarbeitet. Genauso wenig wurden für Perl, Python, Ruby etc. irgendwelche spezifischen Dateiformate geschaffen.

Kurzum, da besteht schon ein gewisser feiner Unterschied!

[Arjay]

Hm .... soviel für unsere Freunde der akademischen Fachdiskussion. Offensichtlich gibts da Spielraum für Interpretationen.

Könntet Ihr mal wieder zum Thema zurückkommen?