Forum Übersicht - RE: dcraw - 3

Hallo,

ich berufe mich da auf den Autor vom pixel grouping verfahren im dcraw, siehe
http://web.cecs.pdx.edu/~cklin/demosaic/
der hata uch einen Artikel geschrieben in dem er ACR etwas genauer unter die lUpe nimmt,
und versucht zu erraten was die eigentlich machen.
(wenn man da ein bischen googelt findet man noch mehr Versuche der Analyse,
und manche kommen zum Schluss das ACR ein verfahren anwendet das in der
Form nicht publiziert ist)

ZITAt (Dennis @ 2007-11-04, 21:53) dcraw ist völlig unkomfortabel und sehr steinzeitmäßig - aber das ist ja gerade seine stärke. Da muss man nicht Angst haben, dass im Hintergrund irgendwelche "Optimierungsalgorithmen" ablaufen. Vor allem für analytische Zwecke ist es sehr gut geeignet. Es gibt da noch eine handvoll Tools aus dem astronomischen Bereich, die da mithalten können, oder sogar noch besser sind. Aber für den fotografischen Bereich ist es ein einzigartiges Produkt. Wer damit professionell arbeiten will, kann seine Dateien per batch in das 16-bittige PS-Format konvertieren lassen, und dann alle Korrekturen ind PS vornehmen.[/quote]
Einzigartig ist es nur im Sinne von "es ist Sourceoffen und unterstuetzt alle moeglichen und unmoeglichen Kameras".
Die eingesetzten Demoisaicing Verfahren dagegen sind allesamt publiziert und nicht nur in dcraw anzutreffen.
Andersrum kann man davon ausgehen das Hersteller wie Adobe da noch einen draufsetzen koennen, weil da vermutlich
>1 Person vollzeit dran arbeitet diese Verfahren zu verbessern. Und die publizieren fuer gewoehnlich nicht...
Wenn man sich die Verfahren in dcraw anschaut sieht man auch, dass die Implementierungen nicht immer
von der selben Person kommen, und teilweise sher schoen optimiert sind, andere dagegen nicht.
Das fauehrt dazu das schlechtere teilweise langsamer sind als bessere (obwohl sie weniger aufawendig sind)
und solche netten Effekte...
Ich wuerde (ausser unter Linux) nicht unbedingt dazu raten das wirklich einzusetzen, da gibts preisguenstige bis kostenlose
komfortablere Alternativen unter Windows.
Aber zum Studium sehr interessant, wenn man wissen will was da so vor sich geht "under the hood"

ZITAt (hobel @ 2007-11-05, 13:23) ich berufe mich da auf den Autor vom pixel grouping verfahren im dcraw, siehe
http://web.cecs.pdx.edu/~cklin/demosaic/
der hata uch einen Artikel geschrieben in dem er ACR etwas genauer unter die lUpe nimmt,
und versucht zu erraten was die eigentlich machen.
(wenn man da ein bischen googelt findet man noch mehr Versuche der Analyse,
und manche kommen zum Schluss das ACR ein verfahren anwendet das in der
Form nicht publiziert ist)[/quote]Das ist ja ein längst bekannter, schon oftmals zitierter Artikel. Es ist natürlich
klar, dass ACR hinsichtlich der Geschwindigkeit getrimmt werden muss aber es macht
imho keine bessere Qualität in der Konvertierung als dcraw. Zudem hat man bei dcraw
noch die Wahl verschiedener Algorithmen.

Wenn man dann diese Analyse betrachtet spricht wohl eher einiges gegen ACR.
http://web.cecs.pdx.edu/~cklin/demosaic/adobe-raw.html

Zudem finde ich dass sich dcraw extrem gut in den Workflow einbauen lässt.
1. Konvertierung eines ganzen Verzeichnisses von arw in dng mit dem Adobe Tool
2. Konvertierung der dng mit dcraw
3. Individuelle Bearbeitung mit Photoshop oder eben gimp

Sollen individuell einzelne raws gewandelt werden geht das auch mit ufraw ganz gut.

Ich musste auch erst lernen, dass sehr gute raws in der Praxis gar keine Schärfung
bei der Konvertierung benötigen. Es reicht erst bei der eigentlichen Zielgröße
(www, Druck usw.) minimal mit USM nachzuschärfen. Die Ausdrucke schauen dann
sehr natürlich und trotzdem genügend scharf aus.

Aus meiner Sicht sind die Unterschiede zwischen ACR und dcraw trotz allem marginal, man
kann also getrost mit der freeware arbeiten.

ZITAT1. Konvertierung eines ganzen Verzeichnisses von arw in dng mit dem Adobe Tool
2. Konvertierung der dng mit dcraw[/quote]
Falls du deine Daten nicht ohnehin nach dng konvertierst ist das nicht nötig. David Coffin hat mir auf Anfrage eine Beta von dcraw geschickt, welche die A700 .ARW unterstützt. Falls du diese haben willst, schreib mir einfach eine pm mit deiner Emailadresse.


Gruss

co2

ZITAt (Hans-J. @ 2007-11-05, 18:06) Das ist ja ein längst bekannter, schon oftmals zitierter Artikel.[/quote]
Ich habe ja nicht behauptet was neues zu erzaehlen, aber man bedenke
das an ACR eben inzwischen fleissig gefeilt wird... (ich bin bestimmt kein grosser
Freund von Adobe Produkten, aber eine Firma hat da eben andere Moeglichkeiten)
ZITATEs ist natürlich
klar, dass ACR hinsichtlich der Geschwindigkeit getrimmt werden muss aber es macht
imho keine bessere Qualität in der Konvertierung als dcraw. Zudem hat man bei dcraw
noch die Wahl verschiedener Algorithmen.[/quote]
bzgl Geschwindigkeit bin ich mir nicht so sicher wer da schneller ist, das muesste mal
untersuchen, kann gut sein dass dcraw schneller ist, da ich stark vermute dass es die einfacheren
Algorithmen hat.

ZITATWenn man dann diese Analyse betrachtet spricht wohl eher einiges gegen ACR.
http://web.cecs.pdx.edu/~cklin/demosaic/adobe-raw.html[/quote]
Ja, das ist ein Artikel der einige Vorteile von ACR aufzeigt :-)
So interpretiere ich das...

ZITATZudem finde ich dass sich dcraw extrem gut in den Workflow einbauen lässt.
1. Konvertierung eines ganzen Verzeichnisses von arw in dng mit dem Adobe Tool
2. Konvertierung der dng mit dcraw
3. Individuelle Bearbeitung mit Photoshop oder eben gimp

Sollen individuell einzelne raws gewandelt werden geht das auch mit ufraw ganz gut.

Ich musste auch erst lernen, dass sehr gute raws in der Praxis gar keine Schärfung
bei der Konvertierung benötigen. Es reicht erst bei der eigentlichen Zielgröße
(www, Druck usw.) minimal mit USM nachzuschärfen. Die Ausdrucke schauen dann
sehr natürlich und trotzdem genügend scharf aus.[/quote]
Also ich habe eher das Gefuehl das moeglichst viel moeglist "dicht" am Ursprungsmaterial
gemacht werden sollte, sprich im Raw Converter.
Aber das ist nur ein Gefuehl :-)
Bin erst dabei mich in Theorie und Praxis der Bearbeitung von Raw Daten einzuarbeiten,
deswegen schmoekere ich auch in draw.c ;-)

ZITATAus meiner Sicht sind die Unterschiede zwischen ACR und dcraw trotz allem marginal, man
kann also getrost mit der freeware arbeiten.[/quote]
Sicher kann man damit arbeiten, aber man kann auch was mit ner GUI nehmen, wie z.b.
Rawtherapee (das nicht free ist)

ZITAt (hobel @ 2007-11-05, 13:29) Einzigartig ist es nur im Sinne von "es ist Sourceoffen und unterstuetzt alle moeglichen und unmoeglichen Kameras".[/quote]Na, dann versuch Dich mal mit ACR und einer linearen Entwicklung... oder mal eine Entwicklung ohne Demosaicking /wink.gif" style="vertical-align:middle" emoid="" border="0" alt="wink.gif" />
Jetzt klar, was ich meine?

ZITAt (Dennis @ 2007-11-05, 20:56) ZITAt (hobel @ 2007-11-05, 13:29) Einzigartig ist es nur im Sinne von "es ist Sourceoffen und unterstuetzt alle moeglichen und unmoeglichen Kameras".[/quote]Na, dann versuch Dich mal mit ACR und einer linearen Entwicklung... oder mal eine Entwicklung ohne Demosaicking /wink.gif" style="vertical-align:middle" emoid="" border="0" alt="wink.gif" />
Jetzt klar, was ich meine?
[/quote]
Jo, aber wer braucht das normalerweise?
2. nutze ich gerade weil ich selber ein paar mosaicing Sachen testen will, und kein Bock hatte
gleich nen raw-reader zu schreiben, also mit dcraw -> pgm und das dann lesen.

ZITAt (hobel @ 2007-11-06, 0:55) Jo, aber wer braucht das normalerweise?[/quote] /wacko.gif" style="vertical-align:middle" emoid="" border="0" alt="wacko.gif" />
Ich dachte, ich hätte eigentlich in ziemlich einfach verständlichen Worten geschrieben, dass dcraw nicht gerade der komfortabelste Konvertierer für die "normalen" Sachen ist, sondern seine Stärke in der Raw-Analyse hat.

ZITAt (Dennis @ 2007-11-06, 14:59) ZITAt (hobel @ 2007-11-06, 0:55) Jo, aber wer braucht das normalerweise?[/quote] /wacko.gif" style="vertical-align:middle" emoid="" border="0" alt="wacko.gif" />
Ich dachte, ich hätte eigentlich in ziemlich einfach verständlichen Worten geschrieben, dass dcraw nicht gerade der komfortabelste Konvertierer für die "normalen" Sachen ist, sondern seine Stärke in der Raw-Analyse hat.
[/quote]
Na dann sind wir uns ja einig.
Btw "raw entwicklung" ohne demosaicing ist eine ziemliche Null-Operartion.
Das Wort "Entwicklung" ist hier noch mehr fehl am Platz als sonst...
(ich kann das Wort in dem Kontext einfach nicht hoeren, sorry :-) *)


* lassen wir mal wikipedia sprechen:

Entwicklung, ein nasschemisches Verfahren zum Herstellen eines Bildes auf einem belichteten Film, einer Fotoplatte oder einem belichteten Papierbild. Diese Bedeutung, eine konkrete Handlung, ist nahe an der ursprünglichen Bedeutung (s. u.).
...
Entwicklung stammt vom Verb entwickeln ab, das wiederum eine Bildung zu wickeln ist. Noch im 17. Jahrhundert wurde entwickeln als aktives und transitives Verb im Sinne von aufwickeln oder auseinanderwickeln gebraucht, beispielsweise wurden Schriftrollen entwickelt; im gleichen Jahrhundert erfolgte die Bildung des Substantivs. Im 18. Jahrhundert wurde der Begriff aus der Alltagssprache in die Wissenschaftssprache übernommen. Um 1800 erhielt entwickeln die übertragene Bedeutung (sich) entfalten, (sich) stufenweise herausbilden und wurde zunehmend als intransitives Verb verwendet. Aus A entwickelt B wird jetzt häufiger etwas entwickelt sich, d. h. aus einer Handlung wird eine Veränderung, deren Verursacher und Gegenstand ungenannt bleiben können.

ZITAt (hobel @ 2007-11-06, 16:22) Btw "raw entwicklung" ohne demosaicing ist eine ziemliche Null-Operartion.[/quote]Eben. dcraw kann es, ACR nicht, C1 nicht, LR nicht.

ZITATDas Wort "Entwicklung" ist hier noch mehr fehl am Platz als sonst...
(ich kann das Wort in dem Kontext einfach nicht hoeren, sorry :-) *)[/quote]Dein Pech, ich verwende es trotzdem - gezielt und absichtlich. Weil es m.E. passt.

ZITAT* lassen wir mal wikipedia sprechen:[/quote]In der Wiki darf jeder Dödel etwas schreiben - für die Richtigkeit garantiert niemand. Wahrheitsgehalt: Zwischen 0% und 100%.

ZITATEntwicklung, ein nasschemisches Verfahren zum Herstellen eines Bildes auf einem belichteten Film, einer Fotoplatte oder einem belichteten Papierbild. Diese Bedeutung, eine konkrete Handlung, ist nahe an der ursprünglichen Bedeutung (s. u.).
...Aus A entwickelt B wird jetzt häufiger etwas entwickelt sich, d. h. aus einer Handlung wird eine Veränderung, deren Verursacher und Gegenstand ungenannt bleiben können.[/quote]Ja, und? Da steht rein gar nichts, was dem Gebrauch des Wortes "Entwicklung" im digitalen Bereich engegensteht - ganz im Gegenteil.

Wie auch immer, ich beende für meinen Teil diese nutzlose Diskussion hier. In diesem Thread sollte es um den Gebrauch von dcraw gehen, meinetwegen auch um die Vor- und Nachteile im Vergleich zu anderen Raw-konvertern - aber nicht um persönliche Aversionen bzgl des Gebrauchs bestimmter Wörter.

ZITAt (Dennis @ 2007-11-07, 13:49) Wie auch immer, ich beende für meinen Teil diese nutzlose Diskussion hier. In diesem Thread sollte es um den Gebrauch von dcraw gehen, meinetwegen auch um die Vor- und Nachteile im Vergleich zu anderen Raw-konvertern - aber nicht um persönliche Aversionen bzgl des Gebrauchs bestimmter Wörter.[/quote]
Gut, full ack.
Nur ein Hinweis warum Entwickeln das falsche Wort ist: Die Raw-Verarbeitung ist kein einmaliger Vorgang.
Ich kann sie jederzeit wieder anstossen, und mit anderen Parametern die zu anderem Ausgang fuehrt.
Und das unterscheidet diesen Vorgang von den anderen Bedeutungen von Entwicklung.

Die Version 8.79 von dcraw unterstützt jetzt auch die Sony A700.
dcraw.c gibts beim Autor

http://cybercom.net/~dcoffin/dcraw/

Nachdem jetzt doch einige neue Sony Kameras A33, A55 A560, A580 unterstützt werden
hab ich am WoE die neueste Vesion 9.05 von dcraw mal wieder durch Visual Studio gejagt.

Das Resultat könnt ihr hier bei Francisco Montilla als dcrawMS.exe herunterladen:
http://www.insflug.org/raw/

Die Version von mir umgeht diverse Probleme, der anderen Windowsversionen, da sie mit dem
original Microsoft Compiler erstellt wurde. Sie läuft natürlich nicht nur unter Windiws 7 und Vista
und den Serverversionen 2003 und 2008, sondern auch unter XP und Windows 2000.
Windows NT ;-) kann ich jetzt nicht mehr testen, aber es sollte eigentlich auch da ohne Probleme laufen.


Den originalen Quellcode dcraw.c gibts beim Autor zum runterladen:
http://cybercom.net/~dcoffin/dcraw/

BG Hans

ZITAT(Hans-J. @ 2010-11-22, 17:07) Das Resultat könnt ihr hier bei Francisco Montilla als dcrawMS.exe herunterladen:[/quote]
Danke für Dein Engagement.
ZITATDie Version von mir umgeht diverse Probleme, der anderen Windowsversionen, da sie mit dem
original Microsoft Compiler erstellt wurde.[/quote]
Zum Hintergrund, mir sind folgende zwei Probleme bekannt:

Bei der Entwicklung von Windows Vista hat Microsoft irgendwas an der Implementierung der VDM (Virtual DOS Machine) "verbockt", so daß standardmäßig jetzt wohl nur noch maximal 32 MiB Speicher über DPMI (DOS Protected Mode Interface) alloziert werden können - mit der Folge, daß dcraw in der normalen Distribution für Windows mit einer Fehlermeldung aussteigt.

Wie weiter oben in diesem Thread schon beschrieben wird dcraw in der Standard-Distribution für Windows mit DJ Delories DJGPP 2.x compiliert. DJGPP ist ein DOS-Compiler, der 32-Bit-Extended-DOS-Anwendungen erzeugt, die auf DPMI basieren. Beim Start der Anwendung überprüft der Stubloader im Executable, ob die Laufzeitumgebung DPMI-Services bereitstellt. Falls ja, so werden diese verwendet. Falls das nicht der Fall ist, so versucht der Loader, den standardmäßig dem Paket beliegenden DOS-DPMI-Host CWSDPMI von Charles W. Sandmann zu laden, so daß die Anwendung laufen kann. Damit ist es unter DOS möglich, bis zu 4 GiB physikalischen oder virtuellen Speicher zu adressieren, d.h. den vollen Adreßraum von 32-bittigen CPUs auszunutzen. Neben CWSDPMI gibt es aber auch noch etliche andere DPMI-Hosts, die genausogut verwendet werden können, wenn sie vor dem Start der Anwendung, die DPMI-Services benötigt, geladen wurden. Einige wenige DOS-Systeme (wie z.B. DR-DOS und inzwischen wohl auch FreeDOS) kommen auch schon von Haus aus mit einem DPMI-fähigen Speichermanager. Die VDM von Windows stellt(e) DPMI ebenso bereit - jedenfalls von Windows 3.0 (im Erweiterten 386-Modus) bis Windows ME und von Windows NT bis Windows XP (und neuer). Und genau da liegt das Problem: Selbst wenn Windows in einer DOS-Box kein DPMI anbieten würde, könnte man in der DOS-Box keinen DPMI-Host eines Drittanbieters nachladen, da DPMI auf einer Privilegstufe der CPU läuft (typischerweise auf Ring 0, im Einzelfall auch mal auf Ring 1), die im V86-Modus gerade nicht verfügbar ist (Ring 3). Der DPMI-Host hat die nahezu vollständige Kontrolle über das System. In einer DOS-Box ist dcraw deshalb auf den bereits verfügbaren DPMI-Host von Windows angewiesen - und wenn der nicht mehr richtig funktioniert, gibt es Probleme... Die 32 MiB DPMI-Speicher, die Windows unter Vista in einer DOS-Box bereitstellt, sind offenbar zu wenig für dcraw.

Unter einigen Windows-Versionen (inklusive Windows Vista SP 1) soll es möglich sein, die Menge an DPMI-Speicher, die Windows einer DOS-Box bereitstellt, über einen Registry-Key zu konfigurieren, hier mal beispielhaft für 128 MiB (nicht selbst überprüft):

Windows Registry Editor Version 5.00
 
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\WOW]
"DpmiLimit"=dword:08000000
 

Siehe auch:

http://www.trnicely.net/misc/vista.html#Solutions
http://www.ee.iitb.ac.in/student/~sachinp/...d=win32_-_vista
http://tech.groups.yahoo.com/group/BCX/message/40157
http://support.microsoft.com/kb/102986
http://forums.dpreview.com/forums/readflat...mp;changemode=1

Das zweite Problem besteht darin, daß 64-Bit-Ausgaben von Windows Vista und Windows 7 leider keine VDMs mehr unterstützen, weder für DOS noch für WoW (Windows on Windows). Der Grund dafür liegt darin, daß der V86-Modus, der die Grundlage für die Implementierung von VDMs bildet, von 64-Bit-Prozessoren der x86-64-Familie nur im Legacy Mode unterstützt wird, die 64-Bit-Betriebssysteme jedoch im Long Mode laufen. Da wollte man bei den CPU-Herstellern wohl offensichtlich ein "paar" Transistoren einsparen und bei der Umstellung von 32 Bit auf 64 Bit einen zusätzlichen Layer an Komplexität rausnehmen, was ich persönlich allerdings sehr bedauere, da sich damit viele interessante Systementwicklungen nicht rückwärtskompatibel realisieren lassen.
ZITATSie läuft natürlich nicht nur unter Windiws 7 und Vista und den Serverversionen 2003 und 2008, sondern auch unter XP und Windows 2000. Windows NT ;-) kann ich jetzt nicht mehr testen, aber es sollte eigentlich auch da ohne Probleme laufen.[/quote]
Der Grund, warum Deine Version funktioniert, liegt darin, daß Du dcraw nicht als Extended DOS-Anwendung compilierst, sondern als Win32-Anwendung. Die Anwendung läuft dann nicht in einer VDM und ist auch nicht auf DPMI angewiesen, sondern benutzt stattdessen das Win32-API. Aber dafür ist sie eben abhängig von Windows. (Ob man Deine Win32-Version von dcraw mit dem DOS-Extender HXDOS, der unter DOS Unterstützung für Teile des Win32-APIs bereitstellt, auch unter DOS zum Laufen bekommt, habe ich noch nicht überprüft.)

Ich schreibe das, damit nicht der falsche Eindruck entsteht, es gäbe einen Fehler in der normalen Windows-Distribution von dcraw, etwa verursacht durch den benutzten Compiler (DJGPP). Das Problem liegt eindeutig auf der Seite von Windows.

Viele Grüße,

Matthias

Danke Matthias für deine Ausführungen.

Die Intention hinter meiner Version ist einfach die, dass die >95% der technisch unbefangenen User
mit Vista oder neueren Windows Versionen einfach problemlos damit arbeiten können.

Du und ich und eine handvoll weiterer alter "Haudegen" kennen noch PC-DOS, MS-DOS, Dr-DOS usw.
und wir haben uns noch persönlich oft stundenlang mit EMM386, QEMM , Extended und Expanded Memory
herumgeärgert, Karten noch mit Chips bestückt und auch Jahre zuvor noch Z80 Selbstbauplatinen gelötet.
Auch das Bios und die Treiber hab ich dafür (mit MASM) noch selbst programmiert, damit dann CP/M darauf
lief. Ja auch meine erste Festplatte mit 6MB ("Winchester Drive" habe ich noch selbst mit der Oszilloskop auf
den Controller eingemessen, denn damals war ein Abgleich der PLL noch unumgänglich...

Aber wir können das bei den heutigen Usern eben nicht mehr als Grundlage vorraus setzen. Da ist oftmals schon
die Bedienung eines Kommandozeilenprogramms das oberste der Gefühle.

Die Zeiten ändern sich eben, und selbst ein Andreas Stiller ist mehr und mehr aus seinem angestammten Terrain
vertrieben worden.

Ein gutes Neues an alle Weggefährten hier

Hans