Forum Übersicht - Elektronische Bildverarbeitung (EBV) » dcraw

dcraw ist ein in mühevoller und jahrelanger Kleinarbeit entstandener Raw-Konverter, den Dave Coffin durch 'reverse engineering' von verschiedenen Raw-Dateien programmiert hat. Hier ist die Seite des Autors mit der aktuellen Kameraliste. Das Programm selbst ist in C geschrieben, der Quellcode ist ebenfalls auf dieser Seite erhältlich. Ausführbare Programme für Mac und Win gibt es hier, und hier gibt es sogar prozessoroptimierte Versionen.

Soweit nichts neues, nur leider gibt es keine anständige Dokumentation. Das beste, was ich gefunden habe war das hier und das hier. Ich möchte hier mal eine kleine Zusammenfassung und Anleitung auf deutsch verfassen (für Win XP).

Zuerst muss man sich natürlich das Programm (für Win dcraw.exe) runterladen, und in irgendein Verzeichnis schmeißen, zB C:\dcraw. Dann im Start-Menu auf "Ausführen" clicken und in das Feld "cmd +" eintippen und bestätigen. Dann geht ein Fensterchen auf, und man kommt sich vor, wie zu DOS-Zeiten... /ninja.gif" style="vertical-align:middle" emoid="" border="0" alt="ninja.gif" />

http://minolta.eazypix.de/forum/dcraw1.gif' target='_blank

Man startet im User-Verzeichnis, und muss sich dann erstmal mit entsprechenden "cd"-Eingaben (change directory) zum richtigen Verzeichnis durchkämpfen (Ich schreibe das deshalb so ausführlich, weil das wohl heute nicht mehr unbedingt zum Standardrepertoire der WinXP-Userschaft zählt). Mit "cd.." geht man eine Verzeichnisebene "hoch", also in Richtung C:, mit "cd blabla" geht's im Verzeichnis "runter" in das Unterverzeichnis blabla. Bei mir waren das also folgende Eingaben:

cd..
cd..
cd dcraw

Dann kommt folgender prompt.

C:\dcraw>_
 

Jetzt ist man im richtigen Verzeichnis und es kann losgehen: Zuerst kann man mal "dcraw" eintippen, dann kommt eine Schnellanleitung:

http://minolta.eazypix.de/forum/dcraw2.gif' target='_blank

Mehr gibt's nicht an offizieller Dokumentation /smile.gif" style="vertical-align:middle" emoid="" border="0" alt="smile.gif" />

Wenn man nun ein Bild konvertieren will, dann tippt man also folgendes ein:

dcraw.exe [Parameter] [Datei(liste)]
 

Der Knackpunkt und das Besondere sind die Parameter, und die will ich mal genauer erklären.

-[n]Bestimmt das Ausgabeformat. Erlaubte Werte sind:

2 ... erzeugt eine gamma-korrigierte 8bit PPM- oder PBM-Datei (default)
3 ... erzeugt eine lineare 16bit PSD-Datei
4 ... erzeugt eine lineare 16bit PPM-Datei

Besonders interessant ist der Parameter -3, da hierbei die Daten am wenigsten "verbogen" werden, und somit ein Optimum an Qualität möglich wird. Da keine Gamma-Korrektur der Daten stattfindet, ist das Bild dunkler als "normal". -2 setzt den Weißpunkt auf 99% und wendet ein Gamma von 0.45 an.
-aErzeugt einen automatischen Weißabgleich. Dazu werden die einzelnen Sensoren gemäß ihrer "Farbe" im Mosaikfilter mit unterschiedlichen Multiplikatoren bearbeitet. Dieser Multiplikator-Satz besteht aus vier einzelenen Multiplikatoren für die Farben Rot Grün Blau Grün, und kann manuell über den Parameter -r [n1] [n2] [n3] [n4] eingegeben werden. Sinn dieser Funktion ist, eine Aufnahme einer weißen Fläche von dcraw analysieren zu lassen, sich die Daten durch den Parameter -v anzeigen zu lassen, und dann für weitere Bilder manuell vorzugeben.
Achtung: Der Parameter -a wird von einem gesetzten Parameter -r überschrieben und somit wirkungslos.
-b 1.0 Führt eine Gamma-Korrektur an den Raw-Daten durch. Der Wert 1.0 ist der default-Wert, ein kleinerer Wert erzeugt ein dunkleres Bild (0 = schwarz), ein größerer ein helleres Bild. Die Software UFRaw erlaubt eine Betrachtung der Wirkung von -b auf das Histogramm. Diese Angabe ist mit gesetztem Parameter -3 oder -4 sinnlos, da dann eine lineare Konvertierung erfolgt.
-B [n1] [n2]Wendet ein "kantenschonendes" Rauschfilter an. [n1] beschreibt einen Pixelwert, [n2] ist eine Farbangabe in CIE Lab (Farbabstand). Ein Startwert von -B 2 4 wird empfohlen. Ich habe damit noch nicht experimentiert.
-cSchreibt die Daten in die Standardausgabe. Keine Ahnung, was man damit anfangen kann.
-dSteht für document mode, und ist für Bilder von Drucksachen vorgesehen. Dabei wird keine Farbinterpolation (Demosaicking) vorgenommen. Es erscheinen also im Bild die einzelnen Pixel in der Grauschattierung (Helligkeit), die die Sensorpixel registriert haben. Das Ergebnis lässt sich mit -b oder -r beeinflussen, der Multiplikator-Satz zur Einzelsensor-Anpassung wird also angewendet. Weiterhin werden auch die Bit-Werte auf den Zielraum skaliert, also zB 12bittige Sensor-Werte mit 16 multipliziert, um den vollen Wertebereich in 16bit auszunutzen. Ohne Parameter wird ein 8bit PGM erzeugt, mit -3 oder -4 ein lineares 16bit PSD resp. PGM.
Achtung: Der Parameter -d wird bei gesetztem -h ignoriert.
-DWirkt wie -d, aber noch extremer: Es finden keinerlei Anpassungen statt, noch nicht mal die Bit-tiefe wird auf das Endformat skaliert. Liegen die Raw-Daten 12bittig vor, werden sie 1:1 in den 16bit Raum überführt. Von den möglichen Werten 0-65.535 in 16bit werden nur die ersten 12 Bit genutzt, also nur die Werte 0-4.095. Daher erscheint das Bild extrem dunkel. Das ist wohl die rohest mögliche Konvertierung. Das Ergebnis ist ein lineares 16bit PSD.
-eExtrahiert das Vorschaubild (Thumbnail), und speichert es als [Dateiname].thumb.jpg (oder. Ppm, abhängig von der Kamera).
Achtung: Dieser Parameter überschreibt alle anderen. Bei gesetztem -e wird immer nur das Vorschaubild extrahiert, es findet keine sonstige Konvertierung statt.
-fSteht für four color und dient dazu, bei der Farbinterpolationdas Bild mit 4 Farben zu berechnen. Zum einen wichtig bei Kameras, die 4-Farb-Filter verwenden (Kodak DCS20x/720x: YMYC; Nikon Coolpix 700/775/800/880/885/900/900S/950/990/995/2100/2500/3100/3500/4300/4500/5000/5700: CYGM; Sony DSC-F828: RGBE), zum anderen empfohlen, wenn bei den Interpolationsarten VNG (-q 2) oder AHD (default, -q 3) Probleme mit Artefakten in glatten Flächen auftauchen. Bei 4-Farb-Kameras wird eine PAM-Datei erzeugt.
-hErzeugt ein half-size image, bei dem aus jeweils 4 Sensorpixeln ein Bildpixel interpoliert wird. Das ist die mit Abstand schnellste Konvertierung, und ist unerlässlich beim Experimentieren.
Achtung: Eventuell gesetzte Parameter -d oder -D werden ignoriert
-H [n]Spitzlicht-Restaurierung (Highlight recovery). Befinden sich in mindestens einem Farbkanal an einer Stelle noch Werte unterhalb der Überlaufschwelle, dann können die anderen Kanäle damit restauriert werden - natürlich nicht farbverbindlich. Was bei Adobe Camera Raw ganz hervorragend klappt, gelingt dcraw nur symbolisch: Übergelaufene Werte werden durch Rosa-Schattierungen ersetzt... /ninja.gif" style="vertical-align:middle" emoid="" border="0" alt="ninja.gif" />
Folgende Werte sind erlaubt:

0 ... Ausgeschaltet, die Spitzlichter werden gekappt (clipping), und die Kanäle mit weiß "gefüllt" (default)
1 ... Die Spitzlichter werden nicht abgeschnitten, sondern "irgendwie" mit Rosa gefüllt. (= -n)
2..9 ... Hier sollten die Spitzlichter "intelligent" wiederhergestellt werden. Allerdings ohne vorzeigbares Resultat.

Hierbei werden die Werte, die per -i unter daylight multipliers ausgelesen werden (als R G /cool.gif" style="vertical-align:middle" emoid="" border="0" alt="cool.gif" /> so umgerechnet, dass der Rot-Wert auf 1.000000 landet, und die anderen entsprechend skaliert werden. Werden also die Werte [n1] [n2] [n3] ausgelesen, dann berechnet sich der Multiplikator-Satz so:

1.000000 [n2/n1] 1.000000 [n3/n1]

Achtung: Der Parameter -H wird von einem gesetzten Parameter -r überschrieben und somit wirkungslos.
-iIdentifiziert die Kamera, und liest einige EXIF-Daten aus. Besonders interessant sind die letzten beiden Zeilen (Beispiel Dimage A2):

Daylight multipliers: 2.094750 0.922500 1.174418
Camera multipliers: 271.000000 256.000000 751.000000 256.000000

Die erste Zeile gibt die Multiplikatoren an, mit denen jeder einzelene Farbwert multipliziert werden muss, um bei Tageslicht eine ausgewogene Farbgebung zu erzeugen. In diesem Falle werden R-Werte mit 2.094750, G-Werte mit 0.922500 und B-Werte mit 1.174418 multipliziert. Wird eine neutrale Fläche bei Tageslicht aufgenommen, so wird diese Fläche auch im konvertierten Bild als neutraler Grauton wiedergegeben. Das rührt daher, dass zum einen die Sensoren unterschiedlich auf bestimmte "Lichtfarben" reagieren, und zum anderen die Farben der Filter unterschiedlich "dicht" sind. Weicht das Licht in seiner Farbtemperatur von Tageslicht ab, dann müssen andere Multiplikatoren verwendet werden. Diese lassen sich zB mit -a ermitteln. Bei der Konvertierung ohne Parameter werden genau diese Multiplikatoren als Multiplikator-Satz verwendet. Dabei wird der kleinste Wert (G) auf 1.000000 normiert, und die beiden anderen entsprechend skaliert:

0.922500 normiert auf 1.000000 (G)
2.094750 : 0.922500 = 2.270731 für R und
1.174418 : 0.922500 = 1.273082 für B ergibt:

2.270731 1.000000 1.273082 1.000000

Die zweite Zeile gibt die Multiplikatoren gemäß der Kamereinstellung bezgl. Weißabgleich an, und zwar in der Reihenfolge des Multiplikator-Satzes R G B G. Diese Werte werden ebenfalls normiert:

256.000000 normiert auf 1.000000 (G)
271 : 256 = 1.058594 ( r)
751 : 256 = 2.933594 ( b) ergibt:

1.058594 1.000000 2.933594 1.000000

Achtung: Dieser Parameter überschreibt alle anderen außer -e. Es finden außer der Anzeige der Daten keine weiteren Konvertierungen statt.
-jFür Fujifilm Kameras mit SuperCCD. Dabei wird das Bild um 45° gedreht, so dass ein Bildpixel einem Sensorpixel entspricht. Klingt nach cooler Spielerei...
Dieser Parameter wird bei Raw-Bildern von anderen Kameras ignoriert.
-k [n]Setzt den Schwarzpunkt. Defaultmäßig von der Kamera bestimmt, kann er hier manuell entsprechend gesetzt werden. Die Skalierung findet im Bit-Raum des Raw-Bildes statt, und bringt Farbverschiebungen mit sich. Wird mit gesetztem Parameter -v sichtbar:

Scaling with black=0, pre_mul[] = 2.270731 1.000000 1.273082 1.000000
-mEntspricht dem Parameter -o 0 (Keine Farbraum-Konvertierung).
-nEntspricht dem Parameter -H 1 (kein channel clipping).
Achtung: Der Parameter -n wird von einem gesetzten Parameter -r überschrieben und somit wirkungslos.
-o [n]Gibt den Ziel-Farbraum an. Mögliche Werte sind:

0 .. .RAW: Farbraum der Kamera, die Werte werden nicht konvertiert. (= -m)
1 ... sRGB (D65) (default)
2 ... AdobeRGB (D65)
3 ... Wide Gamut D65
4 ... Kodak ProPhotoRGB (D65)
5 ... CIE XYZ
-qGibt den Algortihmus der Farbinterpolation vor. Erlaubte Werte sind:

0 ... Bilineare Interpolation: Schnell und einfach.
1 ... Reverse. konnte bei einem schnellen Test keinen Unterschied zu 1 feststellen.
2 ... VNG (Variable Number of Gradients): Hochwertiges Ergebnis, neigt aber zu schachbrettartigen Kanten. Einfach zu entfernendes Rauschen.
3 ... AHD (Adaptive Homogeneity-Directed): Generell bestes Ergebnis, bessere Kanten als VNG, dafür nicht so gut zu entrauschen.

Hier findet sich ein guter Vergleich zwischen VNG und AHD.
-r [n1] [n2] [n3] [n4] Bestimmt den Multiplikator-Satz, der bei gesetztem Parameter -v in folgender Zeile angezeigt wird:

Scaling with black=0, pre_mul[] = 2.270731 1.000000 1.273082 1.000000

Wird -r nicht gesetzt, dann werden die daylight multipliers-Werte übernommen (siehe Parameter -i). Eine unverfälschte Darstellung erhält man, wenn man -r 1 1 1 1 setzt. Dann werden die unterschiedlichen Helligkeiten der Primärfarben ins konvertierte Bild übernommen. Somit kann man beispielsweise eine notwendige Korrekturfilterung für eine bestimmte Lichttemperatur ermitteln. Hier kann man die mit den Parametern -a und -v ermittelten Werte einsetzen.
Achtung: Der Parameter -r überschreibt gesetzte Parameter -a, -w, und -H (-n).
-sFür Fujifilm-Kameras mit SR-Pixeln. Die Werte der sekundären Pixel werden dabei um 4 Stufen unterbelichtet eingerechent, um Details in den Lichtern darzustellen. Dieser Parameter wird bei Raw-Bildern von anderen Kameras ignoriert.
-tDreht oder spiegelt das Bild. Erlaubte Werte:

0 ... Unterdrückt jede Drehung, auch wenn von Kamera in EXIF hinterlegt (0:0:0).
1 ... Spiegelung an der vertikalen Bildachse (H:0:0).
2 ... Spiegelung an der horizontalen Bildachse (0:V:0).
3 ... Spiegelung an horizontaler und vertikaler Bildachse = Drehung um 180° (H:V:0).
4 ... Spiegelung an vertikaler Bildachse und Drehung um 90° CCW (0:0:T).
5 ... Drehung um 90° CCW (H:0:T).
6 ... Drehung um 90° CW (0:V:T).
7 ... Spiegelung an vertikaler Bildachse und Drehung um 90° CW (H:V:T)
8 ... wie 0 (0:0:0).
9 ... wie 1 (H:0:0), usw.
90 ... 90° CW, entspricht 6 (0:V:T).
180 ... 180°, entspricht 3 (H:V:0).
270 ... 270° CW, entspricht 5 (H:0:T).

Wird kein Wert vorgegeben, wird die Kameraeinstellung übernommen.
-vGibt bei der Konvertierung entsprechende Meldungen aus:

http://minolta.eazypix.de/forum/dcraw3.gif' target='_blank

Unerlässlich beim Testen und Experimentieren.
-wNimmt einen Weißabgleich entsprechend den Kameraeinstellungen vor. Dabei werden die unter camera multipliers genannten Werte für den Multiplikator-Satz verwendet (siehe Parameter -i).
Achtung: Der Parameter -w wird von einem gesetzten Parameter -r überschrieben und somit wirkungslos.
-zSetzt den Zeitstempel der ausgegebenene Datei auf den Aufnahmezeitpunkt aus den EXIF's.

Werden keine Parameter explizit gesetzt, dann werden folgende Parameter implizit gesetzt:

-2 ... 8bit gammakorrigiertes PPM/PBM
-b 1.0 ... Standard-Helligkeit
-H 0 ... Kanal-Clipping
-k 0 (oder kamerabhängiger Wert) ... Setzung des Schwarzpunktes
-o 1 ... Konvertierung nach sRGB
-r [Werte entsprechend daylight multipliers] ... Weißabgleich
-t [Wert entsprechend Kameravorgabe] ... Drehung

Eine möglichst unverfälschte farbige Darstellung ergibt folgender Parameter-Satz:

-3 -m -r 1 1 1 1

So, habe fertig, und nun viel Spaß!

ich glaube 99,99 Prozent der Nutzer des Raw Formates wollen, um das Bildergebniss am PC auszuwerten, keine umständliche Programierung mit undefinierbaren komplizierten Zahlenkombinationen machen, sondern die einfachen, unkomplizierten, anwenderfreundlichen und kostenlosen Programme nutzen!

Gruß Micha

Genau die 0.01%, die vielleicht auch nur gelegentlich mal Bilder auf der Kommandozeile konvertieren wollen, sind um eine solche Anleitung froh. /clapping.gif" style="vertical-align:middle" emoid="" border="0" alt="clapping.gif" />

Könnte man hier einfüllen. Wobei ich nicht weiss, wie offiziell das ganze ist.

ZITAt (Fischvati @ 27.05.2006 - 10:33) ich glaube 99,99 Prozent der Nutzer des Raw Formates wollen, um das Bildergebniss am PC auszuwerten, keine umständliche Programierung mit undefinierbaren komplizierten Zahlenkombinationen machen, sondern die einfachen, unkomplizierten, anwenderfreundlichen und kostenlosen Programme nutzen!

Gruß Micha[/quote]

Ich denke das 99,99% viel viel zu hoch gegriffen ist. Ich würde diese Zahl auf alle Amateur- und Gelegenheitsfotografen beschränken (nicht abwertend gemeint). Ich persönlich benutze dcraw schon eine Weile und bin extrem dankbar dafür das es so ein Tool gibt. Egal welcher andere Raw-Konverter, er ist immer in eine Umgebung eingebettet die mehr oder weniger komfortabel (oder voluminös) ist. Außerdem habe ich mit dcraw die Möglichkeit sehr schnell, sehr viele Dateien zu verarbeiten. So ist es möglich nach einer Aufnahme auf ein weißes Blatt am Beginn einer Studiosession zu kalibrieren und dann den Rest unbeaufsichtigt zu konvertieren, mit allen Parametern die ich sonst auch definieren kann.

Ein an Windowsusern typisches Übel ist, das sie meinen alle IT-Probleme dieser Welt müssten mit einer (möglichst aufwendigen) grafischen Oberfläche gelöst werden. Mir persönlich ist genau diese nicht so wichtig, ich brauche eine schnelle, effiziente Lösung und da kommt mir ein Kommandozeilentool oder Sourcecode den ich selbst einbetten kann gerade recht.

Ich für meinen Teil spreche Dennis meinen Dank aus für die sehr gute Anleitung und bin mir sicher das sich mehr als 0.01% der Raw User Gemeinde meiner Meinung anschliessen werden.

@Dennis
Danke für die Mühe, ich denke dem einen oder anderen wird das sicher weiter helfen. Damit der Beitrag nicht verloren geht, habe ich ihn gepinnt.

Mark

ZITAt (Dennis @ 27.05.2006 - 2:36) Ausführbare Programme für Mac und Win gibt es hier [...][/quote]
Danke, Dennis, für diesen interessanten Beitrag. Zwar habe ich mangels Digitalkamera persönlich noch keinen Bedarf an diesem Tool, aber sauber geschriebene Utilities wie dieses finde ich immer unterstützenswert.

Interessehalber wollte ich deshalb gerade mal nachschauen, ob man den Quelltext nicht auch auf DOS portieren könnte, aber ein Blick auf den .EXE-Header offenbart, daß zumindest die hier angebotene Version "für Windows 98/SE/2000/XP" mit DJ Delories DJGPP compiliert wurde, eine Portierung also gar nicht mehr nötig ist - es handelt sich bereits um eine reinrassige 32-Bit-DOS-Anwendung. /smile.gif" style="vertical-align:middle" emoid="" border="0" alt="smile.gif" /> Das bedeutet, daß dieses Executable auch unter Windows 3.0 - 3.11, Windows 95 sowieso unter jedem DOS ab 3.0 ohne irgendwelche Anpassungen läuft, solange dessen Speichermanagement nur einen 32-bittigen DPMI 0.9- oder 1.0-Host bereitstellt. DJGPP greift dabei defaultmäßig auf Charles W. Sandmanns DPMI 0.9 Host (CWSDPMI) zurück (der allerdings weder "full DPMI" implementiert, noch das Subset der 16-Bit-Funktionen abdeckt und damit nicht auf 286-Prozessoren läuft - gut, das dürfte heute keine Einschränkung mehr darstellen... /wink.gif" style="vertical-align:middle" emoid="" border="0" alt="wink.gif" /> )

Spaßeshalber ein größerer Exkurs für DOS-Fans: /biggrin.gif" style="vertical-align:middle" emoid="" border="0" alt="biggrin.gif" />
ZITAT[off-topic]
DJs DJGPP ist eine auf dem GNU C-Compiler (GCC) basierende 32-Bit-DOS-Entwicklungsumgebung. Ich kenne DJ u.a. aus den OpenDOS-Mailinglisten, wo wir beide damals aktiv waren und z.T. auch noch sind. Mit DJGPP erzeugte Anwendungen enthalten einen sog. DOS-Extender, der die Anwendung im 32-Bit-Protected Mode eines 386-Prozessors laufen läßt und ihr "flachen", bei Bedarf auch virtuellen Speicher zur Verfügung stellt.
Nachdem ganz frühe proprietäre DOS-Extender in den Achtziger Jahren noch mit den jeweiligen Compilern fest verzahnt waren und jede Menge Kompatibilitätsprobleme verursacht haben, benutzten DOS-Extender später "nach unten" das VCPI 1.0 (Virtual Control Program Interface), das als eine Art Protected Mode-Erweiterung des EMS 4.0 (Expanded Memory Services) Standards angesehen werden kann und dementsprechend im EMM386-Speichermanager zu lokalisieren ist. VCPI ermöglicht die geregelte Übergabe der Kontrolle zwischen zugrundeliegendem DOS + Speichermanager und der Anwendung. Leider konnte bei VCPI immer nur einer "Herr im Haus" sein, so daß mit Windows 3.0 eine weitere Schnittstelle eingeführt wurde:
DPMI (DOS Protected Mode Interface) regelt auf einer höheren Schicht die konkurrierende Ressourcenvergabe mehrerer parallel laufender Extended-DOS-Anwendungen in einer Protected Mode-Multitasking-Umgebung, wobei der DPMI-Host die Kontrolle nicht abgibt, sondern immer behält. Windows ist praktisch DPMI Host als auch Client in einem - man kann Windows (bis ME) guten Gewissens als DOS-Extender plus graphische Oberfläche betrachten. Während Windows selbst eine Implementation des (undokumentierten) sog. "full DPMI" repräsentiert, hat Microsoft nur einen kleinen Teil der zugrundeliegenden Architektur als "DPMI 0.9" veröffentlicht. "Full DPMI" stellt also eine Obermenge von DPMI 0.9 dar. Der spätere DPMI 1.0 Standard stammt nicht mehr federführend von Microsoft selbst und stellt keinesfalls "full DPMI", sondern eine Erweiterung von DPMI 0.9 um andere, neue Belange dar, die teilweise sogar mit denen von "full DPMI" konkurrieren - deshalb konnte sich DPMI 1.0 auch nicht besonders weit durchsetzen, wird aber von heutigen DPMI-Hosts (außer eben von Windows, das sich nach außen hin nach wie vor nur als DPMI 0.9 ausgibt) meist als Alternative unterstützt. Unter reinem DOS wird DPMI entweder in Form eines zusätzlichen Treibers wie CWSDPMI bereitgestellt, welcher auf einem vorhandenen VCPI- oder XMS-(Extended Memory Specification) Speichermanager aufsetzt oder - falls keiner geladen ist - sich selbst um die Verwaltung des rohen INT 15-Speichers kümmert. Leistungsfähiger (d.h. nach außen hin kleiner und dabei deutlich performanter) sind jedoch Lösungen, die direkt in den EMM386-Speichermanager integriert sind - dies ist aber leider nur bei wenigen Produkten der Fall, z.B. bei Quarterdecks QEMM und beim DR-DOS EMM386. Beide bilden zu großen Teilen auch "full DPMI" nach, so daß z.B. unter dem DR-DOS Multitasker neben mehreren DOS-Tasks (auch Extended-DOS-Applikationen, solange diese auf dem DPMI-Standard fußen) auch mehrere Windows 3.x-Sessions gleichzeitig laufen können (im Standard Mode), wobei der DR-DOS Multitasker die volle Kontrolle über das Gesamtsystem behält. Sowas wäre ohne DPMI nicht denkbar. Wird eine ältere Extended-DOS-Anwendung gestartet, die nicht DPMI nutzt, sondern auf dem tieferliegenden VCPI aufzusetzen versucht, so wird die Anwendung angehalten, bis alle anderen im Hintergrund laufenden Tasks beendet sind.
(Darüberhinaus gibt es noch zwei weitere APIs mit ähnlicher Zielsetzung, wenn auch anderer Ausrichtung: Das von Digital Research/Novell entwickelte DPMS (DOS Protected Mode Services), das bei DR-DOS und PC DOS zum Lieferumfang gehört (aber auch unter anderen DOSen und Windows funktioniert), und Helix' CLOAKING. Beide erlauben es nicht nur Anwendungen, sondern auch TSRs und Treiber im Protected Mode und Extended Memory zu laufen (quasi für "Extended-DOS-TSRs" und helfen so signifikant mit, den kostbaren Real-Mode-DOS-Speicher zu entlasten. DPMS kann parallel zu DPMI verwendet werden und ist absolut multitaskingfest. CLOAKING stellt sogar einen "cloaked" DPMS-Host bereit, ist dafür aber leider mit vielen Multitaskern nicht kompatibel. Hat aber beides mit DJGPP nichts zu tun und wird von daher hier nicht weiter ausgeführt.)
[/off-topic][/quote]

Unter DR-DOS sollte folgender Aufrufparameter beim Laden von EMM386 in [D]CONFIG.SYS ausreichen, damit DCRAW laufen kann:

REM DR-DOS EMM386 enthält bereits einen XMS-Provider, arbeitet aber auch mit HIMEM.SYS
REM zusammen - nur nötig, wenn man mehr als 64 MB XMS-Speicher braucht.
REM DEVICE=C:\WINDOWS\HIMEM.SYS /TESTMEMN /VERBOSE

DEVICE=C:\DRDOS\EMM386.EXE [/MULTI] [/HANDLES=128] [/FRAME=AUTO] /DPMI [/VERBOSE=DEBUG]

Viele Grüße,

Matthias

ZITAt (Mark @ 27.05.2006 - 13:22) Ich denke das 99,99% viel viel zu hoch gegriffen ist. Ich würde diese Zahl auf alle Amateur- und Gelegenheitsfotografen beschränken (nicht abwertend gemeint).

Mark[/quote]

na da habe ich mich wohl etwas weit aus dem fenster gelehnt, aber ich meinte dann doch wohl auch diese Gruppe Fotografen die Mark erwähnt, zu denen auch ich mich zähle.

Gruß Micha

Vielleicht sollten wir ja hier mal eine Umfrage starten, wie viele Leute immer mit RAW arbeiten, wie viele nur gelegentlich und wie viele überhaupt nicht.
Also ich hab's noch nie getan und bis dato auch nicht vermisst!

LG

Alex 8)

P.S. Trotzdem kann man Dennis nur seinen Dank aussprechen für diese intensive Arbeit!

ZITAt (AlexDragon @ 27.05.2006 - 17:21) Vielleicht sollten wir ja hier mal eine Umfrage starten, wie viele Leute immer mit RAW arbeiten, wie viele nur gelegentlich und wie viele überhaupt nicht.[/quote]
Ich denke, Heim-Laboranten haben eine natürliche Affinität zu Entwicklungsarbeiten. Deshalb meine ich, daß dieses wunderbare Werkzeug (DCRaw) in diesen Kreisen die gleiche Priorität hat, wie ein gutsortierter Filterkasten zum Vergrößerer.

Also, ich gestehe: Ich arbeite mit Rohdaten. Dort, wo's nicht darauf ankommt, verwende ich .JPG. Und was mir wichtig ist, banne ich auf Film.

Dank Dennis für Deine Überzeugungstätigkeit!

Servus
Gerhard

ZITAt (Fischvati @ 27.05.2006 - 10:33) ich glaube 99,99 Prozent der Nutzer des Raw Formates wollen, um das Bildergebniss am PC auszuwerten, keine umständliche Programierung mit undefinierbaren komplizierten Zahlenkombinationen machen, sondern die einfachen, unkomplizierten, anwenderfreundlichen und kostenlosen Programme nutzen![/quote] /blink.gif" style="vertical-align:middle" emoid="" border="0" alt="blink.gif" /> Äh - ja? Hat das irgendwas mit meinem Thread zu tun?

Ich glaube, Du hast da etwas falsch verstanden: Ich starte hier keine Mission, um irgendjemanden zu dcraw zu bekehren. Ich habe eine Anleitung und Erläuterung für diejenigen geschrieben, die sich dafür interessieren, bzw schon damit arbeiten. Wer das nicht tut oder sich nicht dafür interessiert, übergeht diesen Thread am einfachsten. Ich war nämlich vor ein paar Tagen in der Situation, mal wieder dcraw ausgegraben zu haben, aber ich fand mich nicht mehr mit den neuen Parametern zurecht. Das, was ich mir in vielen Stunden mit unzähligen Konvertierungen an Wissen angeeignet habe, habe ich hier niedergeschrieben, damit es auch anderen nutzt. Hätte ich so eine Anleitung gehabt, hätte es mir viel Zeit erspart.

Es ist auch keine Frage: dcraw ist umständlich, und im Endeffekt HighEnd-Konvertern wie ACR oder C1 unterlegen. Aber laut vielen Berichten soll es zT. deutlich besser sein, als die ganzen Konverter der Kamera-Hersteller. Der eigentliche Clou dieses Programmes ist aber die einzigartige Möglichkeit, die Rawdaten quasi auf Bit-Ebene gezielt bearbeiten und konvertieren zu können. Das ist sehr hilfreich, wenn man den Sensor seiner Kamera ausloten will, um so seine Belichtungstechnik zu optimieren. Man kann zwar auch bei einigen anderen Konvertern "linear" anklicken, aber man weiß nie so genau, was hinten raus kommt.

Mark hat es genau auf den Punkt gebracht: Es ist sehr schnell, und für so einen Batch-Job ideal. Außerdem ist dieser geniale Konverter, der ALLE DSLRs unterstützt, gerade mal läppische 325 KB groß, dazu kommt noch eine DLL mit 705 KB. Das Ding ist einfach ein waschechtes Tool.

Ansonsten vielen Dank für die Kommentare und Ergänzungen! /smile.gif" style="vertical-align:middle" emoid="" border="0" alt="smile.gif" />

Das finde ich ganz interessant. Hatte mir die Seite des Autors auch mal vor einiger Zeit angeschaut.
Ihr sagt, das sei z.B. für die Konvertierung von großen Bildermengen relevant.
Hat jemand Erfahrung, wie lange dcraw für die Konvertierung von z.B. 100 Bildern braucht?
Danke + beste Grüße.

ZITAt (tatatu @ 28.05.2006 - 1:32) Hat jemand Erfahrung, wie lange dcraw für die Konvertierung von z.B. 100 Bildern braucht?[/quote]Das kann man so nicht sagen, weil das natürlich von den Raw-Daten abhängt (ein EOS D30 Raw ist halt deutlich kleiner, als das einer 1Ds II) und vor allem von den gewählten Parametern. Ein Zeitfresser ist die aufwändige AHD Interpolation, und vor allem die (nicht nutzbare) -H 2..9 Spitzlicht-Weiderherstellung. Probier es einfach aus, das Programm ist in Sekunden runtergeladen und installiert, dann ab ins cmd, die richtigen Parameter bestimmen, und probekonvertieren. Dann kannst Du hochrechnen.

ZITAt (tatatu @ 28.05.2006 - 1:32) Das finde ich ganz interessant. Hatte mir die Seite des Autors auch mal vor einiger Zeit angeschaut.
Ihr sagt, das sei z.B. für die Konvertierung von großen Bildermengen relevant.
Hat jemand Erfahrung, wie lange dcraw für die Konvertierung von z.B. 100 Bildern braucht?
Danke + beste Grüße.[/quote]

Die Gretchenfrage /smile.gif" style="vertical-align:middle" emoid="" border="0" alt="smile.gif" />, zu dem was Dennis angeführt hat kommt naütrlich noch dein Rechner dazu. Es sollte sich ein Unterschied zwischen einem PIII 1.3GHz und einem A64 X² 2.4GHz oder einem G4 und G5 abzeichnen.
Eine einfache Methode zur Hochrechung ist dcraw in einen "watch" oder "Time" Container einzubetten.
Time ist ein Kommando um die Zeit zu ermitteln die ein Prozess zu Abarbeitung benötigt. Anhand von 10 Bildern kannst du dann auf größere Mengen hochrechnen. Der Haken dabei ist, ich weiß nicht ob es das Kommando in Windows gibt, ich habe so ein paar Hochrechungen für MacOS X angestellt. Da war es ziemlich schnell und ist an das was ich von den Herstellern hatte herangekommen.

Noch ein Tipp für Windows, für solche Arbeiten lohnt es sich ein Tool wie den Total Commander und/oder UltraEdit zu installieren. Der Total Commander erlaubt den schnellen Zugriff auf Verzeichnisse und Dateien, so lässt sich durch die Verzeichnisse browsen und direkt aus einem Verzeichnis die Konsole starten. UltraEdit ist dann das ideale Tool um kleine Batchroutinen um das Programm zu schreiben und nicht nur das, IMHO ist Ultraedit einer der mächtigsten Editoren unter Windows.
Für die etwas mehr in den Quellcode interessierten, da möchte ich mal noch die Powershell von WIndows erwähnen. Kürzlich vom Redmonder Giganten freigegeben nähert sie die Möglichkeiten etwas an die Pinguinfraktion an und bietet sogar die Möglichkeit Methoden un Klassen direkt auf der Kommandozeile anzusprechen (was mir in Verbindung mit dcraw die Option anbot andere C Klassen anzubinden). In Vewrbindung mit (dem kostenlosen) Visual C++ Express aus Redmond hat man damit eine leistungsfähige digitale Hexenküche in der man sich relaitv unkompliziert etwas sehr leistungsfähiges zusammenbauen kann. Als Beispiel sei da die Anpassung der Raws in dcraw und die direkte Anpassung der Größen und Formate in einem Skript. So das ich am Ende das *.raw, ein *.psd, ein *.tif und ein *.jpeg jedes Bildes in einem fertigen ISO-Image habe, das ich nur noch brennen muss (und selbst das würde das Skript mit Boardmitteln lösen).
Das Ganze ist so für einen meiner Kunden entstanden, der mit Buchbühnen arbeitet. Das sind Geräte mit denen Kopien von Dokumenten (meist Bücher) erstellt werden, egal ob analog oder digital. Im Moment erproben einige Bibliotheken digitale Lösungen und wollen die anfallenden Datanmengen auf sinnvolle Art verarbeiten. Da will sicher niemand vor einem Compüuter sitzen und per Hand 5000 Seiten starke Wälzer bearbeiten. Also ein weißes Blatt am Anfang aufgenommen und ab geht's. Am Ende muss dann nur noch jemand die "Bandmaschine" oder die "Brennerei" anwerfen.

Mark

Hallo Mark,

den Total Commander nutze ich auch in anderer Beziehung für die Verwaltung meiner digitalen Bilder. In TC ist die Möglichkeit der Synchronisation von Verzeichnissen super. Sobald ich auf der Platte im Rechner Dateien verändert habe, z.B. die Beschreibung / Stichworte und IPTC-Einträge gemacht habe, synchronisiere ich die ganzen Verzeichnisse mit denen auf der externen Harddisk mittels TC. Ich brauche also nicht einzeln die Dateien rausfummeln, die geändert wurden, das findet TC von alleine.
Auch sonst ist die Aufteilung in zwei Fenster für das Verwalten von Dateien und Verzeichnissen (nach meinem Empfinden) erheblich schneller zu bedienen beim Kopieren, Löschen und Schieben als der Explorer.

Moin moin
Jürgen

Der Commander kann noch einiges mehr, ich bin erklärter Fan des Norton Commanders gewesen und hab daher die gesamte Entwicklung des Total Commanders mitgemacht. Man kann übrigens nicht nur Verzeichnisse vergleichen, sondern auch Dateien. Man kann riesige Listen vergleichen und ein- bzw. aussortieren. Editor und Hexeditor sind an Board, verschiedene Packer, ein FTP Client. Ich möchte ihn nicht mehr missen.
Gerade wer viel mit Perl und Konsole "rummacht" sollte ein genaues Auge drauf werfen, die Konsole allein unter Windows ist do ein bischen zu rudimentär als das ich sie dauerhaft benutzen möchte /wink.gif" style="vertical-align:middle" emoid="" border="0" alt="wink.gif" />.

Mark

Hallo,

und auch meinen Dank an Dennis, der hier offensichtlich sehr viel mehr getan hat, als die Man-Pages (Format der Unix-Dokumentation) zu übersetzen.

Ich habe dcraw erst vor wenigen Tagen entdeckt, nachdem ich mich gezwungen sah, mich ein wenig mit RAW-Konvertierung zu beschäftigen, da ich bei Bildern mit hohem Helligkeitsumfang mit den JPEG-Bildern der Dynax 7D etwas unglücklich war (weiß oder schwarz abgesoffen). Als ich über die Suche nach dem GIMP-Plugin zum Konvertieren von RAW-Dateien bei UFraw bzw .RAWPhoto angekommen war, war es nur noch ein kleiner Schritt zu erkennen, dass laut dcraw-Homepage hinter vielen Progammen, die Raw-Formate unterstützen, wohl dcraw werkelt. Bislang habe ich dcraw nur indirekt über das GIMP-Plugin genutzt und mit diesen Ergebnissen bin ich sehr zufrieden.

Der Parameter -c um das Ergebnis von dcraw über die Standardausgabe (stdout) wegzuschreiben könnte man vielleicht unter Linux im Zusammenspiel mit sogenannten Pipes nutzen, um die Ergebnis direkt als Eingabe in ein weiteres Kommandozeilentool weiterzuleiten. Beispielsweise könnte man so noch ein weiteres Filtertool zum Schärfen anschließen.

Gruß,
Andreas