Jump to content

Darktable Austausch


Empfohlene Beiträge

Werbung (verschwindet nach Registrierung)

11 hours ago, Helios said:

Der (ja von Adobe entwickelte) XMP-Standard sieht vor, dass lediglich die Dateinamenerweiterung verändert wird. Dem folgt logischerweise Lightroom, andere machen es eben anders. Argumente Pro/Kontra findet man für beide Varianten. Ich persönlich finde die Lightroom-Variante besser, weil es bei mir keinen Anwendungsfall gibt, bei dem zwei gleichnamige Dateien unterschiedliche Metadaten aufweisen sollten. Andere mögen eben die Unterscheidung je nach Dateityp.

Das Problem entsteht, wenn nicht nur Metadaten, sondern die raw-entwicklungs-Parameter ins XMP gespeichert werden. Denn es könnte ja sein, dass sowohl das JPG als auch das RAW editiert wurde, aber es gibt ja nur eine XMP-Datei für beide.

Daher benutzt Darktable eine XMP-Datei pro Quelldatei, was leider nicht dem Standard entspricht. Wie handhabt Lightroom das denn wenn beide Dateien editiert wurden? 

Im Grunde halte ich den XMP-Standard für Entwicklungsparameter für ungeeignet. Entwicklungsparameter sind ohnehin nicht zwischen Anwendungen kompatibel, also warum in eine standardisierte Datei schreiben? Die meisten Anwendungen machen das ja auch tatsächlich nicht, sondern nutzen XMP nur für die standardisierten, portablen Metadaten, speichern ihre Entwicklungsparameter aber anderswo.  

Link zum Beitrag
Auf anderen Seiten teilen

vor 1 Stunde schrieb DSLRUser:

Ich bin wenn ich ehrlich sein soll eher erstaunt, dass es wohl OS Projekte gibt die Standard für "Unsinnig" erklären und eigenen Weg einschlagen.

Als üblich würde ich das nicht bezeichnen, XMP ist dahingehend wohl tatsächlich einer der Sonderfälle (neben Darktable gibt es ja noch andere Open Source Projekte, die das so oder anders handhaben). Warum sie es anders machen ist ja durchaus auch sachlich begründet, ich kann dem halt nur nichts abgewinnen und würde mich über eine Wahlmöglichkeit freuen.

vor 43 Minuten schrieb bastibe:

Das Problem entsteht, wenn nicht nur Metadaten, sondern die raw-entwicklungs-Parameter ins XMP gespeichert werden. Denn es könnte ja sein, dass sowohl das JPG als auch das RAW editiert wurde, aber es gibt ja nur eine XMP-Datei für beide.

Für mich persönlich ist das gar kein Problem, ich sehe keinen Sinn darin JPEGs zu bearbeiten und deaktiviere die Anwendung von Bearbeitungsanweisungen für diese, ich lasse sie mir nicht einmal im Entwickler anzeigen (für mich ist das ein reines Austauschformat, und so wird es in meinem Arbeitsablauf auch behandelt). Und allgemein sollte das eigentlich auch kein Problem sein, selbst wenn es jemand anders macht bzw. machen will. Zum einen ist vorgesehen, dass XMP direkt in das JPEG eingebettet wird (und die eingebetteten Werte der Filialdatei vorgezogen werden), zum anderen kann man über das XMP-Schema bzw. die Properties auch verschiedene Bearbeitungen in eine Datei schreiben. Sofern ich mich recht erinnere hatte man sich bei Darktable sehr früh dagegen entschieden, weil man beim Verlagern von Daten die entsprechenden Abschnitte wieder hätte herauslösen müssen, damit die Dateien sauber bleiben. Deswegen wird ja nicht nur die Dateinamenerweiterung einfach angehängt statt ersetzt, sondern auch für jede Bearbeitung eine neue XMP-Datei erzeugt. 

 

vor 55 Minuten schrieb bastibe:

Im Grunde halte ich den XMP-Standard für Entwicklungsparameter für ungeeignet. Entwicklungsparameter sind ohnehin nicht zwischen Anwendungen kompatibel, also warum in eine standardisierte Datei schreiben? Die meisten Anwendungen machen das ja auch tatsächlich nicht, sondern nutzen XMP nur für die standardisierten, portablen Metadaten, speichern ihre Entwicklungsparameter aber anderswo.  

Es gibt durchaus Kompatibilitäten der Entwicklungsparameter zwischen verschiedenen Anwendungen, allerdings eher zufällige bzw. mit teilweise willkürlichen Ergebnissen, von daher stimme ich dir in dem Punkt zu. Aber die Speicherung in einer Filialdatei (und weil die XMP-Datei eh vorhanden ist bietet sie sich halt an) ermöglicht die nicht-destruktive Bearbeitung ohne Katalogzwang, was zum einen flexiblere Abläufe ermöglicht, zum anderen auch den Austausch vereinfachen kann. Die Alternative dazu wäre eine zweite Filialdatei, die aufgrund der Kompatibilitätsbeschränkungen dann sogar proprietär sein könnte. 

Link zum Beitrag
Auf anderen Seiten teilen

vor einer Stunde schrieb Lümmel:

Ich denke, diese Diskussion brauchst du weder hier noch im dt-Forum bei pixls.us anzufangen.

Das hatte ich nicht vor. Es war mehr als eine Feststellung für mich, dass DT kein für mich geeignetes Tool ist.

vor einer Stunde schrieb Lümmel:

"Wir, die Entwickler, schreiben die Software für uns und nicht für jemand anderen, und wir wollen das so"

Jupp kenn ich. Diese Arroganz hat schon etliche wirklich gute Sachen kaputtgemacht.

vor 57 Minuten schrieb bastibe:

Denn es könnte ja sein, dass sowohl das JPG als auch das RAW editiert wurde,

Und dafür gibt es den Standard. RAW Datei hat Sidecar XMP Datei. JPG, TIF, PSD usw. haben diese nicht.

Gut - jetzt sind die DT Entwickler scheinbar den Weg gegangen und sagen "wir fassen keine Bilddatei an. Auch wenn es an sich erwünscht wäre". Das ist durchaus valider Ansatz, so lange man mit Rest der Welt nicht "Kommunizieren" will. 

 

Link zum Beitrag
Auf anderen Seiten teilen

vor einer Stunde schrieb bastibe:

Entwicklungsparameter sind ohnehin nicht zwischen Anwendungen kompatibel, also warum in eine standardisierte Datei schreiben? Die meisten Anwendungen machen das ja auch tatsächlich nicht, sondern nutzen XMP nur für die standardisierten, portablen Metadaten, speichern ihre Entwicklungsparameter aber anderswo.  

Und das wäre auch ein sehr guter Ansatz, dem DT folgen könnte. Nur die Entwickler haben sich dagegen entschieden.

 

Link zum Beitrag
Auf anderen Seiten teilen

Tja, man nimmt eben was man kriegt. Dem Einen sind die einen Dinge wichtig, dem Anderen die anderen. Die eine Anwendung macht es so, die andere anders. Das gute ist ja, dass wir so unglaublich viel Auswahl haben. Da gibt es eigentlich für jeden etwas. 

Darktable ist auch sicher eher exzentrisch im einigen Belangen. Das ist nicht für Jeden. 

Für meinen Teil bin ich aber absolut dankbar, dass es Darktable gibt. Ich bin halt Techniker, und Signalverarbeiter, und Nerd. Die technische Tiefe, mit der in Darktable an die Dinge herangegangen wird, spricht mich enorm an, das bietet kein anderes Programm. 

Mit Version 4 ist jetzt endlich der scene-referred Workflow derart gediegen, dass er auch bei schwierigen Bildern kaum noch Probleme macht. Mit ein wenig Skripting und einigen angepassten Shortcuts etc. habe ich mir einen wirklich effizienten, produktiven raw-Workflow erarbeitet, der sich nicht mehr hinter etwa Capture One verstecken muss. 

Besonders spannend finde ich das immer noch schwierige Rendering von Highlights, denn Darktable macht die üblichen Farbdreher nicht, die wir aus praktisch allen anderen Tools kennen. Das ist bei hellen Himmeln toll, die nicht mehr ins Cyan driften. Oder bei heißen Hauttönen, die nicht mehr gelb werden. Aber Sonnenuntergänge oder Feuer sehen einfach langweilig aus, wenn die Highlights nicht gelb werden—obwohl jeder Mensch mit Augen natürlich in Realität genau sieht, dass sie auch im Wirklichkeit nicht gelb werden. Aber an diesen Look habe ich mich derart gewöhnt, dass es schwer für mich ist die realistischere Darstellung von Darktable zu akzeptieren. 

(Auch weil Wahrnehmung halt einfach ein Arsch ist: Gelb wird bei gleicher Luminanz und Sättigung als heller wahrgenommen als Orange, einfach weil isso. Sprich, der gelbe Farbdrift lässt stark gesättigte Highlights heller erscheinen als den Rest des Bildes, wegen Helmholtz-Kohlrausch-Effekt. Falsch ist das Gelb trotzdem. Erkenntnisse wie Diese sind auch Teil meiner Faszination mit Darktable. In Lightroom erklärt einem so etwas ja keiner.) 

Link zum Beitrag
Auf anderen Seiten teilen

vor 3 Stunden schrieb bastibe:

Ich bin halt Techniker, und Signalverarbeiter, und Nerd. Die technische Tiefe, mit der in Darktable an die Dinge herangegangen wird, spricht mich enorm an, das bietet kein anderes Programm. 

Und obwohl uns vieles hier verbindet, sehen wir es total unterschiedlich an :D
Die Zeiten wo ich bei Bedarf mir selbst Kernel und/ oder Samba-Patche geschrieben habe sind schon sehr lange her. Jetzt interessieren mich immer noch viele Hintergründe und auch Möglichkeiten wie ich eine Software so ansprechen kann wie ich es gerne hätte ( bei C1 lese/ schreibe ich z.B einige Sachen direkt in die Datenbank, weil es schneller und einfacher geht als über die GUI). Aber die Software muss sich eben in ein (mein) Workflow einbinden lassen. Es mag vielleicht auch sein, dass ich das mit DT auch hinbekommen hätte (Hard/ Softlinks kennt inzwischen auch Windows).. Von der Seite wäre es vielleicht auch Interessant und eine Herausforderung. Nur dann hätte ich zumindest Zeitlang eher das Problem, dass ich mich mit den technischen Herausforderungen auseinander setzen muss und gar nicht mit den Bildern und deren Bearbeitung.
 

--- Aber schlecht o.ä muss DT deswegen nicht sein. Es passt nicht zu mir oder ich zu DT :D ---

 

Link zum Beitrag
Auf anderen Seiten teilen

  • 5 months later...

Werbung (verschwindet nach Registrierung)

Es ist wieder soweit, Weihnachten naht, und eine neue Version von Darktable kam gerade heraus. 

Besonders spannend diesmal, eine Alternative zu filmic, die mit Highlights eher so umgeht wie von Lightroom gewohnt. Das löst meinen Haupt-Kritikpunkt an Darktable der letzten Jahre. Und eine dramatisch verbesserte Highlight-Rekonstruktion wenn ein oder zwei Kanäle verbrannt sind. Und für einige Kameras (neuere Fuji und manche Sony, IIRC), eingebettete Objektivkorrekturen. 

Link zum Beitrag
Auf anderen Seiten teilen

vor 49 Minuten schrieb bastibe:

Es ist wieder soweit, Weihnachten naht, und eine neue Version von Darktable kam gerade heraus.

Ja, die offizielle Freigabe war gestern, nicht am Hl. Abend, sondern zur Wintersonnenwende - das wurde vor einiger Zeit so beschlossen seitens der Entwickler, weil im Sommer ja nach dem Release-Plan auch 'ne Version kommt, diese dann wohl zukünftig auch zur Sonnenwende.

Einen ausführlichen Artikel gibt es diesmal nicht ... nur die Release-Notes (nur englisch, https://www.darktable.org/2022/12/darktable-4.2.0-released/) mit den Neuerungen im Detail.

Link zum Beitrag
Auf anderen Seiten teilen

Danke für den Hinweis. Ich hatte irgendwo mitbekommen, dass auch die OMDS (Olympus) OM-1 jetzt direkt unterstützt werden soll, aber leider scheint das nicht der Fall zu sein, die OM-1 steht nicht in der Liste. Ich habe bisher nur auf meinem Windows-Rechner upgedated, aber das wird auf Linux genau so sein.

Sehr schade, dass die OM-1 immer noch nicht direkt unterstützt wird. Bildbeispiele scheinen für das Modell ja vorhanden zu sein. Auf custom-builds möchte ich ungern zurückgreifen.

Link zum Beitrag
Auf anderen Seiten teilen

  • 1 month later...

In der offiziellen Version leider nicht. Ab Version 4.0 konnte ich per Adope DNG Converter gewandelte RAW-Bilder zwar einlesen und es waren Objektiv-Korrekturen anwendbar, aber selbst mit der offiziellen 4.2 Version können die ORF-Dateien der OM-1 nicht direkt geöffnet werden. Objektiv-Korrekturen können, sofern für die Kamera/Objektiv Kombi verfügbar, bei den konvertierten DNG angewendet werden. Die OM-1 steht auch noch nicht in der Liste der unterstützten Kameras https://www.darktable.org/resources/camera-support/

Ich habe mich nun getraut einen inoffiziellen Windows-Build der 4.2.0 auf einem meiner Rechner zu installieren. Sieht ganz gut aus, die OM-1 ORF werden direkt geladen und Entrauschen-Profile sind auch verfügbar. Objektiv-Korrekturen funktionieren damit natürlich auch. Damit kann ich nun gut arbeiten, letztes Jahr hatte ich mit konvertierten DNG und normalem Entrauschen gearbeitet, was aber immer etwas aufwändiger war.

Ich habe den Download von hier genommen (natürlich ohne Gewähr!): https://discuss.pixls.us/t/om-1-support-in-darktable/30980/54

Für Linux-User gibt es dort auch Hinweise. Hoffentlich wird das bald in die offizielle Version übernommen.

Link zum Beitrag
Auf anderen Seiten teilen

  • 1 month later...

Hab gerade mal im darktable-Repo 'n bißchen rumgestochert.

Im Sommer kommt Version 4.4 heraus, dabei soll der Support für folgende Kameras entfernt werden:


    Creo/Leaf Aptus 22(LF3779)/Hasselblad H1
    Fujifilm FinePix S9600fd
    Fujifilm IS-1
    GoPro FUSION
    Kodak EasyShare Z980
    Leaf Aptus-II 5(LI300059)/Mamiya 645 AFD
    Leaf Credo 60
    Leaf Credo 80
    Minolta DiMAGE 5
    Olympus SP320
    Panasonic DMC-FX150
    Pentax Q10
    Phase One IQ250
    Samsung GX10
    Samsung GX20
    Samsung EK-GN120
    Samsung SM-G920F
    Samsung SM-G935F
    Sinar Hy6/ Sinarback eXact
    ST Micro STV680

Falls jemand so 'ne Kamera hat und RAW-Samples nach https://raw.pixls.us/ hochlädt - dann kann der Support weiterhin erfolgen (im Kern geht es darum, daß die Entwickler diese Samples brauchen, um darktable testen zu können).

Generell ist es eine gute Idee für jeden, der eine neue Kamera (insbesondere ein neues Modell) kauft, da gleich mal nachzugucken und ggf. "aufzufüllen".

Link zum Beitrag
Auf anderen Seiten teilen

Ich weiß nicht, ob schon mal beschrieben worden ist, wie man ein kameraspezifisches Farbprofil für darktable (oder auch RT) erstellt. Leider kommen wohl fast alle open source Programme ohne die große Anzahl von Farbprofilen daher, wie sie Adobe anbieten kann. Die haben wohl ein guten Draht zu den Kamera-Herstellern. Daher hier mal meine Vorgehensweise.

Von Adobe muss man sich zunächst den DNG-Converter herunterladen. Anschließend, sofern die Kamera im Raw-Format nicht ohnehin schon DNG-Dateien erstellt, eine Raw-Datei nach DNG konvertieren. Danach lädt man sich den DNGProfileEditor herunter. In dem Programm öffnet man die DNG-Datei und exportiert das Profil als *.dcp - Datei.
Unter Linux kann man mit dem Programm ./dcp2icc die Datei in das für darktable richtige Format *.icc konvertieren. Die *.icc Datei kopiert man einfach in $HOME/.config/darktable/color/in

Nach dem Neustart von darktable hat man nun das neue kameraspezifische Farbprofil im Modul Colors / Input color profile. Die Adobe Programme sind kostenlos. dcp2icc ist open source.

Link zum Beitrag
Auf anderen Seiten teilen

@clooney Danke für die Erläuterung, eine *.dcp-Datei habe ich erstellt, leider komme ich mit der Umwandlung ins ICC nicht weiter. Ich hab zwar einen Raspberry Pi, aber mit Add Software wird dcp2icc nicht gefunden. 
Und wenn man dann mal das ICC hat, in welches Verzeichnis kopiert man es dann, wenn Darktable auf einem Windows-PC läuft?!

Link zum Beitrag
Auf anderen Seiten teilen

12 hours ago, clooney said:

Ich weiß nicht, ob schon mal beschrieben worden ist, wie man ein kameraspezifisches Farbprofil für darktable (oder auch RT) erstellt.

Vielen Dank für die Erklärung! Was bewirkt dieses Profil dann?

Edit: Wer lesen kann... es geht um den Support alter Kameras, verstehe.

bearbeitet von bastibe
Link zum Beitrag
Auf anderen Seiten teilen

Interpretiere ich das richtig, daß ich ohne Adobe (DNG Converter, den es nur für Fenster und Apfel gibt) keinen Beitrag zu einem Programm liefern kann,
welches originär unter Linux entwickelt wurde und als Alternativprodukt für Adobe an den Start ging? Irgendwie schräg, oder?

Erinnert mich an ganz alte Zeiten, als im Linux Magazin noch 3.5 Zoll Disketten beilagen. DOS formatiert. 

Link zum Beitrag
Auf anderen Seiten teilen

vor 21 Minuten schrieb pero:

Interpretiere ich das richtig, daß ich ohne Adobe (DNG Converter, den es nur für Fenster und Apfel gibt) keinen Beitrag zu einem Programm liefern kann,
welches originär unter Linux entwickelt wurde und als Alternativprodukt für Adobe an den Start ging? Irgendwie schräg, oder?

Erinnert mich an ganz alte Zeiten, als im Linux Magazin noch 3.5 Zoll Disketten beilagen. DOS formatiert. 

Jein. Erstens läuft der Converter notfalls unter Wine und zweitens kann digikam auch nach DNG konvertieren. Damit sollte es auch gehen.

Link zum Beitrag
Auf anderen Seiten teilen

vor 39 Minuten schrieb Lümmel:

... kann digikam auch nach DNG konvertieren. Damit sollte es auch gehen.

Wie geht das? Eben grad nachgeschaut. 
Ich kann sogar nach heif konvertieren von Standards wie jpeg, png etc. mal ganz abgesehen. 
Aber DNG habe ich nicht gefunden. Versionsproblem (7.1)? 
Korrektur. Im Batch-Queue-Manager habe ich es gefunden. Es fliegt mir aber um die Ohren. Ich schaue mir das mal genauer an.

bearbeitet von pero
Link zum Beitrag
Auf anderen Seiten teilen

vor 22 Minuten schrieb pero:

Wie geht das? Eben grad nachgeschaut. 
Ich kann sogar nach heif konvertieren von Standards wie jpeg, png etc. mal ganz abgesehen. 
Aber DNG habe ich nicht gefunden. Versionsproblem (7.1)? 
Korrektur. Im Batch-Queue-Manager habe ich es gefunden. Es fliegt mir aber um die Ohren. Ich schaue mir das mal genauer an.

Wenn ich mich recht erinnere, war das eines der Module in digikam.

Convert RAW Files to DNG with DNGConverter | Scribbles and Snaps (wordpress.com)

bearbeitet von Lümmel
Link zum Beitrag
Auf anderen Seiten teilen

vor 7 Stunden schrieb pero:

Interpretiere ich das richtig, daß ich ohne Adobe (DNG Converter, den es nur für Fenster und Apfel gibt) keinen Beitrag zu einem Programm liefern kann,
welches originär unter Linux entwickelt wurde und als Alternativprodukt für Adobe an den Start ging? Irgendwie schräg, oder?

Das Eine (RAW-Samples bei pixls.us) hat genau gar nix mit dem Anderen (Farbprofile) zu tun. Denn: die Farbprofile nutzen Dir gar nix, wenn die Software das RAW-Format selbst ("Länge, Breite, Höhe" - also Seitenverhältnisse, Bittiefe etc., also alles, was da so kameraspezifisch an so einem RAW-Format sein kann) nicht lesen kann.
Und hierfür sind die Samples nötig - eben damit die Entwickler das alles testen können.

Link zum Beitrag
Auf anderen Seiten teilen

Diese "Farbprofile" sind im Grunde die Farbraum-Definitionen der Kameras, also die Spezifikation der Farbfilter vor dem Sensor. Die muss man natürlich wissen wenn man die RAW-Dateien korrekt lesen möchte. Angeblich schreibt die auch jeder Hersteller in seine RAW-Dateien hinein, aber es ist wohl nicht unbedingt einfach, herauszuknobeln wo und wie die gespeichert sind.

Der Weg über die Adobe-DNGs ist da glaube ich nur eine Abkürzung, da man in den DNGs die Spezifikation genau kennt, und sie sich ja pro Kamera nie ändert. Adobe ist also streng genommen nicht nötig, nur halt einfach. Weil Adobe ja vermutlich von den Herstellern eine genaue Spezifikation der RAW-Formate bekommt, diese Informationen aber Anderen vorenthalten wird. Warum. Auch. Immer.

(Das alles ist gefährliches Halbwissen aus Hörensagen und Forumstratsch. Bitte mit Vorsicht genießen und gerne berichtigen.)

Link zum Beitrag
Auf anderen Seiten teilen

  • 4 weeks later...

Ich habe eine Frage (keine Angst ich werde mir DT immer noch nicht installieren) :D

Letztens habe ich ein Video von Sven Tetzlaff  gesehen wo es darum ging ob DT ein Ersatz für C1 sein könnte. Auch wenn Sven begeistert scheint (er war aber auch immer von C1 begeistert, daher halte ich von solch einer Begeisterung nicht viel), hatte ich schon aus ganz anderen Gründen DT für mich ausgeschlossen.
Was mich aber interessiert, weil ich es nicht verstanden habe - was ist für reine Fotografen, also Leute die nicht mal 1Sec Video drehen, das s.g  "Scene Refered Workflow" so besonders? So wie er da erzählt, hätte ich gesagt - für Leute die auch Filmen mag es wegen gleichen Werkzeugen/ Vorgehensweisen vor Vorteil sein aber für Leute die nur Fotos machen? 

 

Link zum Beitrag
Auf anderen Seiten teilen

Der Vorteil besteht in der Verarbeitung. RAW-Dateien verwenden den linearen RGB-Farbraum. Dieser wird während der Verarbeitungskette (Pixelpipe) in den nicht linearen Farbraum umgewandelt. Das geschieht durch das Modul Basiskurve oder Filmic RGB oder neuerdings Sigmoid.

Im Display-Refered-Workflow geschieht das relativ früh in der Verarbeitungskette, so dass im wesentlichen Weißabgleich und Belichtung vorher dran sind um im linearen Farbraum arbeiten. Alles was danach im nicht linearen Farbraum kommt ist für RAW und JPG gleich. Hier werden die Vorteile von RAW nicht ausgenutzt.

Im Scene-Refered-Workflow wird der Punkt, an dem die Umwandlung von linear nach nicht-linear erfolgt weiter nach hinten verschoben, so dass mehr Module im linearen Farbraum arbeiten (zB Farbkalibrierung, Farbbalance RGB, Tonwert-Equalizer). Das hat zum einen den Vorteil der einfacheren und genaueren Berechnung und zum anderen ist dieser Farbraum in Darktable unendlich. Dadurch können keine Tonwertabrisse entstehen.

Soweit die Theorie. In der Praxis sind die neuen Module zwar (für Anfänger) schwerer zu verstehen und zu beherrschen, aber sie bieten wesentlich mehr Möglichkeiten und liefern bessere Ergebnisse. Meiner Meinung nach liegt das nur zum Teil an dem szenenbezogenen Workflow. Der andere Teil liegt daran, dass die neuen Module einfach komplexer sind, was sie alleine aufgrund des linearen Farbraums nicht sein müssten.

Wer mal versucht die Belichtung einer JPG-Datei zu ändern und dann die des dazugehörigen  RAWs, der wird feststellen, dass es mit dem RAW viel besser geht.
Mit dem szenenbezogenen Workflow steht dieser Vorteil auch in anderen Modulen zur Verfügung.

Die kurze Version: Im szenenbezogenen Workflow lassen sich bessere Ergebnisse erzielen.

Link zum Beitrag
Auf anderen Seiten teilen

Am 16.3.2023 um 07:41 schrieb pero:

Interpretiere ich das richtig, daß ich ohne Adobe (DNG Converter, den es nur für Fenster und Apfel gibt) keinen Beitrag zu einem Programm liefern kann,
welches originär unter Linux entwickelt wurde und als Alternativprodukt für Adobe an den Start ging? Irgendwie schräg, oder?

Erinnert mich an ganz alte Zeiten, als im Linux Magazin noch 3.5 Zoll Disketten beilagen. DOS formatiert. 

1. Darktable wurde nie als Alternativprodukt für Adobe angepriesen. Es hat gar nichts mit Adobe zu tun.

2. Darktable bietet lediglich die Möglichkeit, ICC Profile als Eingabeprofile (und auch als Ausgabeprofile) zu verwenden. ICC Profile sind ein allgemeiner Standard. Sie können durch viele verschiedene Programme (auch unter Linux) erzeugt werden.

3. DOS formatierte Disketten haben die Vorteil, dass sie auf allen System lesbar sind. USB-Sticks werden heute auch üblicherweise mit FAT formatiert.

Link zum Beitrag
Auf anderen Seiten teilen

Erstelle ein Benutzerkonto oder melde dich an, um zu kommentieren

Du musst ein Benutzerkonto haben, um einen Kommentar verfassen zu können

Benutzerkonto erstellen

Neues Benutzerkonto für unsere Community erstellen. Es ist einfach!

Neues Benutzerkonto erstellen

Anmelden

Du hast bereits ein Benutzerkonto? Melde dich hier an.

Jetzt anmelden
×
×
  • Neu erstellen...