Warum sollte man Cosima benutzen?

Why Using Cosima?

Interpolation digitaler Bilder

Digitale Bilder besitzen ihre Farbinformationen ausschliesslich auf den Gitterpunkten. Beim Betrachten des Bildes sieht man trotzdem eine lückenlose geschlossene Farbfläche, weil die Pixel natürlich gerade so groß dimensioniert sind, dass sie sich exakt berühren.

Wenn man digitale Bilder verkleinern oder vergrößern will, muss man sich die Größe der Pixel allerdings wiederum auf einen Punkt zusammengeschrumpft vorstellen. Verkleinern und Vergrößern bedeutet also nichts anderes, als eine Farbinformation zwischen den Pixeln zu gewinnen. Diesen Prozess nennt man Interpolation. Hierbei ist es von erheblicher Bedeutung, ob digitale Bilder vergrößert oder verkleinert werden.

Beim Vergrößern von Bildern müssen also aus den schon vorhandenen Pixeln neue Pixel berechnet werden. Die insgesamt vorhandene Anzahl von Pixeln ist ein Mass für die mögliche Detailgenauigkeit des Bildes: Wenn sich die Pixelabfolge im Bild schnell ändert, besitzt es hohe Frequenzanteile, wenn sich die Pixelabfolge nur langsam ändert, besitzt es nur niedrige Frequenzanteile. Offensichtlich könnte man beim Vergrößern von Bildern also Details hinzufügen, aber welche nur? Da man dies nicht weiss, fordert man als Bedingung beim Vergrößern von Bildern:

Beim Vergrößern von Bildern dürfen keine neuen Details (keine höherfrequenten Bildanteile) hinzugefügt werden!

Und für diese Forderung liefert uns die Mathematik auch schon das Ergebnis: Wir müssen als Interpolationsfunktion eine sin(x)/x - Funtion verwenden. Damit sind die Mathematiker fertig, aber für uns fängt die Arbeit jetzt erst an, denn die sin(x)/x- Funktion ist für die Praxis völlig unbrauchbar - Aufwand und Rechenzeit sind nicht vertretbar! Also denken wir uns einfachere Lösungen aus, die aber nicht viel schlechter sein sollen, als die optimale Lösung.

Die einfachste Interpolationsfunktion ist die lineare Interpolation (bilinear, weil in 2 Dimensionen). Hierbei werden die Farbwerte zweier benachbarter Pixel durch eine Gerade verbunden und der gesuchte Farbwert auf der Geraden abgelesen. Um einen neuen Pixel zu berechnen, braucht man also nur die 4 Nachbarpixel auszuwerten und linear zu gewichten. Einfach und gut! Etwas bessere (im Sinne von: näher an der Forderung) Ergebnisse erhält man, wenn man den Verlauf der sin(x)/x-Funktion durch Polynome 3.ten Grades approximiert und dazu nicht nur 4 Pixel sondern eine Umgebung von 4x4=16 Pixel auswertet. Dies ist die kubische Interpolation (bikubisch, weil in 2 Dimensionen). Alle anderen von den verschiedensten Programmen verwendeten Methoden sind mehr oder weniger gute Approximationen der sin(x)/x-Funktion - die aufwendigeren unter ihnen verwenden bis zu 6x6=36 Pixel der Umgebnung, um jeweils einen neuen Wert zu berechnen.

Alle haben sie jedoch eines gemeinsam: Vergrößerte Bilder wirken immer unscharf, da sie im Verhältnis zu der Anzahl ihrer Pixel zu wenig Bilddetails (zu wenig hochfrequente Bildanteile) besitzen. Das war ja gerade die Ausgangs-Forderung.

Streng genommen geben die so vergrößerten Bilder die Verhältnisse aber unverfälschter wieder, als die Originale, denn die am Anfang erwähnte Ausdehnung der Pixel (bis sie sich berühren) ist eine Massnahme, durch die das Bild schärfer gewirkt hat, als es in Wirklichkeit gewesen ist. Die Pixelkanten sind immer scharf und täuschen Bildschärfe auch dort vor, wo gar keine Schärfe vorhanden ist. Diesen Effekt bieten die hochskalierten Bilder nicht mehr.

Um in hochskalierten Bildern wieder einen schärferen Bildeindruck zu erhalten, ist es also sinnvoll, das Bild nachzuschärfen.

Was passiert nun beim Verkleinern von Bildern? Das verkleinerte Bild hat weniger Pixel als das Originalbild und kann deshalb nur weniger Details zeigen. Diese Details verschwinden aber nicht automatisch beim Verkleinern, viel schlimmer: sie führen zu häßlichen Bildfehlern, wenn man sie nicht vorher entfernt! Im Frequenzbereich tauchen sonst die höherfrequenten Bildanteile plötzlich bei niederen Frequenzen wieder auf (aliasing). Die Tiefpaßfilter, die man deshalb zu diesem Zweck einsetzt, werden darum auch Anti-Aliasing Filter genannt. Diese Filter müssen so bemessen sein, dass alle Frequenzanteile, die im verkleinerten Bild nicht mehr dargestellt werden können, weggefiltert werden. Das ist so wichtig, dass es nochmals verdeutlicht werden soll:

Beim Verkleinern von Bildern müssen vor der Verkleinerung alle höherfrequenten Bildanteile mit einem Anti-Aliasing Filter herausgefiltert werden.

Auch hier bietet uns die Mathematik wieder die sin(x)/x-Funktion an (jetzt natürlich mit entsprechend gedehnter x-Achse) und auch hier lehnen wir wieder dankend ab und realisieren etwas viel einfacheres, zum Beispiel einen Mittelwert- oder Gaussfilter. Diese Operation hat natürlich zur Folge, dass auch das verkleinerte Bild unscharf wirkt, und deshalb gilt die gleiche Empfehlung wie bei der Vergrößerung:

Um bei herunterskalierten Bildern wieder einen schärferen Bildeindruck zu erhalten, muss das Bild nachgeschärft werden.

Sowohl das Herauf- wie auch das Herunterskalieren ist also mit einem (subjektivem) Schärfeverlust verbunden. Glücklicherweise gibt es aber Schärfeverfahren, die - bei vorsichtiger Anwendung - ganz erstaunliche Ergebnisse liefern und den Schärfeverlust durch die Skalierung wieder ausgleichen können.

Interpolation of digital images

In digital images the color information exist exclusively on the grid points. While looking to the image, one sees, nevertheless, a complete closed color surface, because the pixels are dimensioned of course just so largely, that they touch another precisely.

If one wants to reduce or increase digital images, one has to imagine the pixels however again shrinked down to point size. Reducing and increasing means nothing else, than to gain color information between the pixels. This process is called interpolation. For this, it is of considerable meaning whether digital images are increased or reduced.

While increasing images, there must be calculated new pixels from the quite available pixels. The number of available pixels alltogether is a measuring of the possible detail exactness of the image: If the pixel sequence changes fastly in the image, it contents high frequencies and if the pixel sequence changes only slowly, it only contents low frequencies. Obviously one could add detail content while increasing images, but which details? Because one doesn't know this, it is demanded as a conditioning for the increasing of images:

While increasing images, no new details (higher frequent image detailes) may be added!

And for this demand the mathematics already delivers the result to us: We must use as an interpolation function the sinc-function. The mathematicians are ready with it, but for us the work now only starts, because the sinc-function is absolutely useless for the practise - the expenditure and the processing time are not defensible! So we have to develope simpler solutions, which shouldn't be much worse, however, than the optimum solution.

The easiest interpolation function is the linear interpolation (bilinear, because in 2 dimensions). Using this method, the colors of two neighboring pixels are just connected by a straight line and the color value in request is read on the line. To calculate a new pixel, one needs only to evaluate the 4 neighbouring pixels and to weight them linearly. Simply and well! A little better results (for the purposes of: closer at the demand) are received if the sinc-function is approximated by polynominals of 3.order and an environment of 4x4=16 pixels is used instead of only 4 surrounding pixels. This is the cubic interpolation (bicubic, because in 2 dimensions). All the other methods used by the different programs are more or less good approximations of the sinc-function - costlier among them use up to 6x6=36 pixels of the environment to calculate a new value.

They all have in common nevertheless: Enlarged images look always blurred, because they content not enough image details (not enough high frequencies) in relation to their number of pixels. This was just the demand above.

Strictly speaking, the so enlarged images return the relations, however, more genuinely than the originals, because the expansion of the pixels (up to their touch as mentioned at the beginning) is a method by which the images look more sharp than they are in reality. The pixel edges are always sharp and simulate image sharpness also where no sharpness exists. The high-scaled images offer this effect no more.

So, to receive a more sharp impression again with high-scaled images, the images have to be postsharpened.

What happens now while reducing the images? The reduced image has less pixels than the original image, and therefore can show only less details. However, these details do not disappear automatically while reducing, much more badly: they lead to ugly image errors if they aren't removed before! Otherwise, in the frequency domain, the higher frequencies suddenly appear again with low frequencies (called aliasing). The low-pass filters, which are used for this purposes, are therefore called anti-aliasing filter. These filters have to be calculated to supress all frequency shares, which cannot be shown in the reduced image any more. This is so important that it has be made clear again:

While reducing images, all higher frequency shares have to be suppressed using an anti-aliasing filter before the reduction.

Also here the mathematics offers us again the sinc-function (now of course with accordingly stretched x-axis) and also here we decline again with thanks and realize something else, which is a lot of easier, for example, an average or Gauss filter. This operation entails of course, that also the reduced image looks somewhat blurred, and, therefore, the same recommendation follows like with the enlargement:

To receive again a sharp impression with down-scaled images, the images have to be postsharpened.

Both, up- and downscaling images come along with a (subjective) loss of sharpness. However, fortunately, there are sharpness procedures which can deliver - with careful application - quite astonishing results and compensate the sharpness loss due to the scaling.

Deinterlacing

Als das Fernsehen erfunden wurde, hatte man sich eine (aus Sicht der damaligen technischen Möglichkeiten) geniale Methode ausgedacht, um bei gleicher verfügbarer Übertragungsbandbreite die Bilder flüssiger darstellen zu können: Das Zwischenzeilenverfahren (eng: interlaced mode). Anstatt 25 Bilder je Sekunde aufzunehmen und jedesmal das volle Bild zu übertragen, wurden 50 Bilder je Sekunde aufgenommen und abwechselnd nur die geraden Zeilen beziehungsweise nur die ungeraden Zeilen übertragen (PAL). Am Fernseher waren dann für jeden Abtastzeitpunkt zwar weniger Bilddetails verfügbar, aber die Bildfrequenz konnte verdoppelt werden, wodurch sich schnellere Bewegungen flüssiger darstellen ließen.

In der Computertechnik hatte sich dagegen nach einer gewissen Übergangszeit das Vollbildverfahren (engl: progressive mode) durchgesetzt, da es aus technischer Sicht keinen Grund mehr gab, auf die Bildinformationen jeder 2.ten Zeile zu verzichten. In der Videotechnik wird das Zwischenzeilenverfahren allerdings immer noch eingesetzt (ein Wechsel deutet sich gerade an), so dass die Weiterverarbeitung von 3D-Videos auf dem Computer immer einen Umrechnungsvorgang vom Zwischenzeilenverfahren in das Vollbildverfahren benötigt. Dieser Umrechnungsvorgang wird Deinterlacing genannt.

Zerlegt man Videostreams, welche mit einer Videokamera aufgenommen wurden, in Einzelbilder, so erhält man 25 Einzelbilder je Sekunde, wobei aber in jedem Einzelbild die Bilddaten von 2 Aufnamezeitpunkten vereinigt wurden. Die geraden Zeilen wurden also zu einem anderen Zeitpunkt aufgenommen als die ungeraden Zeilen. In den Bildern sieht man deshalb bei schnellen Bewegungen ausgefranste Ränder.

Die zentrale Frage ist deshalb: Mit welchen Deinterlace-Operationen können die ursprünglichen Vollbilder wiederhergestellt werden? Da der Inhalt der fehlenden Bildzeilen völlig unbekannt ist, ist es prinzipiell auch nicht möglich, das Originalbild wieder komplett zu rekonstruieren. Es ist lediglich möglich, den Inhalt der fehlenden Zeilen entsprechend gewisser Methoden zu schätzen. Da hier aus einem Videobild beide Abtastzeitpunkte in getrennten Ergebnisbildern rekonstruiert werden, verdoppelt sich beim Deinterlacen die Anzahl der Bilder: Aus 25 Interlaced-Bildern je Sekunde entstehen also 50 Vollbilder je Sekunde. Bei manchen Anwendungen wird hiervon dann allerdings wieder jedes 2.te Bild verworfen. Die wichtigsten bekannten Verfahren sind:

Zeilenverdoppelung (line doubling):

Die gültige Zeile wird einfach wiederholt. Denkbar schlechtestes Verfahren, zu rechtfertigen nur bei Echtzeit-Bildverarbeitung mit einfacher Hardware. Diese Methode bietet Cosima nicht an, die Ergebnisse sind nicht zufriedenstellen.

Interpolation innerhalb des gleichen Abtastzeitpunktes (field interpolation):

Ähnlich wie bei der Vergrößerung digitaler Bilder kann auch hier das fehlende Pixel aus den Farbinformationen der Pixel aus den benachbarten oberen und unteren Zeilen interpoliert werden. Die Ergebnisse sind recht brauchbar, allerdings noch nicht perfekt, denn die zeitliche Abfolge - Originalpixel - interpoliertes Pixel - Originalpixel - interpoliertes Pixel - usw. kann in bestimmten Fällen zu deutlichem Flimmern führen (engl. bobbing). Cosima bietet diese Methode mit den Parametern InterlacedMode = 1,2,3 an. Um das Flimmern zu reduzieren, ist eine postoperative Nachverarbeitung der Bilder mit einem Tießpassfilter (FlickerFilter) ratsam, allerdings ist dies mit einem Schärfeverlust verbunden.

Smarte Interpolation (field- and frame interpolation):

Um das oben erwähnte Flimmern gar nicht erst entstehen zu lassen, werden zur Interpolation auch die zeitlich früheren und späteren Bildinformationen des gleichen Pixels verwendet. In Abhängigkeit der Bewegung im Bild verwendet man zur Interpolation dann entweder die Information aus den Zeilen darüber und darunter (bei schnellen Bewegungen; field interpolation) oder die Information aus den Bildern davor und danach (ohne Bewegung; frame interpolation). Die Ergebnisse mit diesem Verfahren sind schon recht brauchbar, allerdings noch mit starken Kompromissen behaftet. Es muss eine Schwelle festgelegt werden, ob eine bestimmte Bildänderung als schnell oder als langsam zu bewerten ist. Auch bei optimaler Wahl dieser Schwelle ist Flimmern immer noch sichtbar und es verbleiben Artefakte an den Kanten schnell bewegter Objekte. Auch hier bietet eine Nachverarbeitung mit einem Tiepassfilter etwas größere Freiheitsgrade bei der Wahl der Bewegungsschwelle. Cosima hat diese Interpolationsmethode bis zur Version 0.8 angeboten, seit der Version 0.9 ist das optimale lineare Deinterlacing implementiert.

Optimales lineares Deinterlacing:

Da die Interpolation zwischen Pixeln aus zeitlich unterschiedlichen Abtastzeitpunkten niemals komplett störungsfrei möglich ist (schnelle Objekte werden unter Umständen komplett weginterpoliert!) muss die Basis eines hochqualitativen Deinterlacingprozesses allein auf den Pixeln eines einzigen Abtastzeitpunktes beruhen. Allerdings stellen die Gewichtskoeffizienten der zur Bewertung der Pixel darüber und darunter noch einen Freiheitsgrad dar. Wer das Kapitel über die Interpolation digitaler Bilder aufmerksam gelesen hat, erinnert sich noch, dass dort eine Interpolationsfunktion verwendet wurde, welche die höherfrequenten Bildanteile innerhalb des Bildes minimiert. Wir lassen diese Forderung jetzt fallen und berechnen die Gewichtskoeffizienten jetzt für jedes Pixel individuell neu, und zwar so, dass die höherfrequenten Bildanteile in der zeitlichen Abfolge des gerade interpolierten Pixels minimiert werden. Diese Methode ist im mathematischen Sinne optimal, alle Bildinformationen werden ausgewertet und gleichzeitig die Störungen minimiert. Das optimale lineare Deinterlacing kennt kein Flimmern, deshalb ist auch kein Flickerfilter mehr notwendig, die Schärfe bleibt bestmöglich erhalten! Cosima bietet diese Methode seit der Version 0.9 mit den Parametern InterlacedMode = 4,5,6 an. Es ist nach meinem Kenntnisstand die einzige und bisher erste Software, welche dieses Verfahren implementiert hat.

Bewegungskompensiertes Deinterlacing (motion compensation):

Bewegungen werden automatisch identifiziert und daraus der Aufenthaltsort der Objekte in den fehlenden Bildanteilen geschätzt. Sehr aufwendige nichtlineare Methode, die (bei entsprechender Implementierung) sicherlich sehr gut funktionieren kann. Eine absolute Fehlerfreiheit bleibt bei einer Bewegungschätzung natürlich ausgeschlossen. Ein Qualitätsvergleich zwischen dem optimalen linearen Deinterlacen und dem motion-compensiert basiertem Deinterlacen wäre sicherlich einmal interessant!

Verzögerung von Halbbildern mit Cosima. Bei der Verarbeitung von Einzelbildern können eventuell vorhandene größere Asynchronitäten (Unterschiede im Abtastzeitpunkt beim linken und rechten Videostream) durch einfache Bild-Umbenennung ausgeglichen werden. Da die Original-Interlacedbilder einen zeitlichen Abstand von 1/25 Sekunde besitzen, verbleiben bei dieser Methode Restfehler von maximal 1/50 Sekunde. Beim Deinterlacen mit der Verdoppelung der Anzahl der Bilder entsteht ein weiterer Freiheitsgrad in der Links-Rechts-Bildzuordnung. Die wahlweise Verzögerung um ein Halbbild im linken oder im rechten Bildstrom reduziert hierbei die maximale Rest-Asynchronität auf +- 1/100 Sekunde. Mit den Parametern InterlacedMode = 1 und 4 werden keinerlei Verzögerung vorgenommen, mit den Werten InterlacedMode = 2 und 5 wird der komplette rechte Bildstrom um ein Halbbild verzögert und mit InterlacedMode = 3 und 6 wird der komplette linke Bildstrom um ein Halbbild verzögert. Achtung: Eine Rest-Asynchronität von +- 1/100 Sekunde ist nur für sehr bewegungsarme Videos ausreichend! Für übliche Bewegungsabläufe sollte die Rest-Asynchronität besser als etwa 1/1000 Sekunde sein!

Deinterlacing

When the television was invented, an (from the view of the technical possibilities at that time) ingenious method was applied in order to represent a more fluently movement with the same available transmission bandwidth: The interlaced mode line procedure. Instead of taking up 25 pictures per second and each time transfering the full picture, 50 pictures per second were taken up and alternating only the even lines and only the odd lines were transferred (PAL). At the receiver, for each time sample, only fewer picture details were available, but the image frequency could be doubled and therefore faster movements could be represented more fluently.

In the world of computers, after a while, the progressive image processing had been established, since from technical view point there was no longer a reason to skip the image information of every second line. Because in the video technology the interlaced line procedure is still used (a change is just on its way), the treatment of 3D-Videos on the computer always needs a conversion process from the interlaced line procedure into the progressive frame procedure. This conversion process is called deinterlacing.

The separation of a camcorder video stream results in 25 frames per second, whereby each frame combines the image data from two different time samples. The even lines were taken up from another time sample than the odd lines. With fast movements this can also be seen in the image by frayed edges.

The main question is: With which deinterlace operations can the original frames be restored? Since the content of the missing lines are of course unknown, it is in principle not possible to reconstruct the original image completely. It is only possible to estimate the missing content according to certain methods. Since both scanning times of the video image are reconstructed here in separate resulting images, the number of images is doubled during the deinterlacing operation: Thus, from 25 interlaced image frames per second 50 full (progressive) image frames will be generated. With some applications however, each second image will be afterwards rejected, but this depends on the application. The most important well-known deinterlacing procedures are:

Line duplication:

Every valid line is simply repeated. Conceivably worst procedure, to justify only for real time image processing with simple hardware. Cosima doesn't offer this method, the results are not satisfying.

Interpolation within the same scanning time (field interpolation):

Similarly as with the enlargement of digital images, the missing pixels are interpolated from the color information of the neighbouring upper and lower lines. The results are quite usefully, however not yet perfect, because the temporal succession - original pixels - interpolated pixel - original pixels - interpolated pixel - and so on - leads in certain cases to a flickering effect (sometimes called bobbing). Cosima offers this method with the parameters InterlacedMode = 1, 2, 3. In order to reduce the flickering, a post processing of the images with a low-pass filter (FlickerFilter) is advisable, however this is always connected with a loss of sharpness.

Smart interpolation (adaptive field and frame interpolation):

In order to reduce the above mentioned flickering, additionally the temporally earlier and later image information of the same pixel is used for the interpolation. Dependent on the movement in the image, either the color information from the upper and lower lines (with fast movements; field interpolation) or the color information from the earlier and later time samples are used (without movement; frame interpolation). The results with this procedure are all right usefully, however still with strong compromises afflicted. A threshold must be specified whether a certain movement of the image is to be evaluated as fast or as slow. Also with the optimal choice of this threshold, flares are still visible and artifacts remain at the edges of fast moved objects. Using a post-processing low-pass filter offers somewhat larger degrees of freedom with the choice of the movement threshold. Cosima offered this deinterlacing method up to the version 0.8, since the version 0.9 the optimal linear deinterlacing is implemented.

Optimal linear deinterlacing:

Since the interpolation between pixels from temporally different scanning times is never completely errorfree possible (fast objects may perhaps completely away-interpolated!), the method of a high-quality deinterlacing process must be based alone on the interpolation of pixels of only one scanning time. However, the color weighting coefficients for this interpolation offers still another degree of freedom. Who reads the chapter about the interpolation of digital images attentively, may remembers, that an interpolation function was used there, which minimizes the higher-frequency image details within the whole image. We let now fall this demand and compute the weighting coefficients for each pixel individually in that way, so that the higher-frequencies in the temporal succession of each pixel stream is minimized. This method is optimal in the mathematical sense, all image information is considered and the disturbances minimized at the same time. The optimal linear deinterlacing does not know any flickering, therefore no more Flickerfilter is necessary and sharpness remains optimum! Cosima offers this method since the version 0.9 with the parameters InterlacedMode = 4.5.6. It is to my level of knowledge the only and so far first software, which has implemented the procedure described so far.

Motion-compensated deinterlacing:

With this method, movements are identified and from this, the place of location of the objects in the missing images pixels estimated. A very complex nonlinear method, which may work surely very well (if appropriatly implementated). An absolute accuracy remains naturally impossible with motion estimation. A performance comparison between the optimal linear deinterlacing and motion compensated based deinterlacing would be surely once interesting!

Delay of half-frames with Cosima. During the frame processing there exists the possibility to align larger time differences between the left and right video streams simply by image renaming. Since the original interlaced images possess a temporal distance of 1/25 second, residual errors of maximum 1/50 second remain with this rough method. During the deinterlacing with doubling the number of images a further degree of freedom to balance out time differences between the left and right images arises. This alternative delay of a half-frame in the left or in the right image stream reduces the maximum remaining imbalance to + - 1/100 second. With the Cosima parameters InterlacedMode = 1 and 4 no delay is added at all, with InterlacedMode = 2 and 5 the complete right image stream is delayed by a half-frame and with InterlacedMode = 3 and 6 the left image stream is delayed by a half-image. Note: A remaining imbalance of + - 1/100 second is sufficient only for very poor-movement videos! For usual motions the remaining time error should be better than about 1/1000 second!

Bedingungen für störungsfreie Anaglyphenbilder

Conditions for ghostless anaglyphes

Details zu cosima_files.txt

Cosima legt bei jedem Analyselauf (EstimateGeometry = 1) eine Bilderliste mit allen gefundenen Analysewerten an. Es handelt sich hierbei um eine reine ASCII-Textdatei. Der Name dieser Datei wird mit dem Parameter ListofImages vorgegeben, per default ist hierfür cosima_files.txt voreingestellt. Mit dem Parameter WriteDataBase läßt sich überdies steuern, ob eine neue Datei angelegt oder ob eine schon vorhandene weitergeführt werden soll.

Aktuell (Version 0.9i4) werden folgende Einträge verwendet:

1. Dateiname oder (bei links-rechts getrenntem Input) Dateinamen.
2. Kennung: OK (Okay): Das Bild wurde erfolgreich korrigiert. Werte sind zuverflässig. IM (Imperfect): Die Ergebnisse der Korrektur sind fragwürdig, das Bild wurde aber trotzdem korrigiert und unter Vorbehalt geschrieben. QU (Quit): Die Bearbeitung des Bildes wurde im PostViewer abgebrochen. Kein Eintrag: Die Korrektur des Bildes ist nicht gelungen.
3. PreViewer: Drehung linkes Bild in Grad: mathematische Orientierung, positiv entgegen dem Uhrzeigersinn
4. PreViewer: Drehung rechtes Bild in Grad: mathematische Orientierung, positiv entgegen dem Uhrzeigersinn
5. PreViewer: (vertikale) Vergenz in Grad: negativ, falls toe-in korrigiert wird
   
   
6. PreViewer: linkes Bild, linke Kante in Prozent der originalen Bildbreite:
7. PreViewer: linkes Bild, untere Kante in Prozent der originalen Bildhöhe:
8. PreViewer: linkes Bild, Breite in Prozent der originalen Bildbreite:
9. PreViewer: linkes Bild, Höhe in Prozent der originalen Bildhöhe:
10. PreViewer: rechtes Bild, linke Kante in Prozent der originalen Bildbreite:
11. PreViewer: rechtes Bild, untere Kante in Prozent der originalen Bildhöhe:
12. PreViewer: rechtes Bild, Breite in Prozent der originalen Bildbreite:
13. PreViewer: rechtes Bild, Höhe in Prozent der originalen Bildhöhe:
    
    
14. Höhenfehler in Pixel: positiv, wenn rechtes Bild zu weit oben montiert ist, gemessen in Inputpixel
15. Grössenfehler in Prozent: positiv, wenn rechtes Bild zu gross ist
16. Rotationsfehler in Grad: positiv, wenn rechtes Bild positiv verdreht ist
17. Vertikale Vergenz in Grad: positiv, bei konvergenten Aufnahmeachsen
18. Horizontale Vergenz: positiv, wenn rechtes Bild von erhöhtem Standpunkt
    
    
19. Seitenverhältnis des Ergbnisbildes: Breite:Höhe
20. Angewendete seitliche Verschiebung: gemessen in Inputpixel
21. Deviation des Ergbnisbildes: relativ zur Bildbreite
22. Nahpunkt im (geometrisch korrigierten) Originalbild: gemessen in Inputpixel
23. Seitliche Referenzverschiebung: Dieser Wert wird nur intern verwendet und ist für das Ergebnis ohne Relevanz, gemessen in Inputpixel
    
    
24. Manuelle seitliche Verschiebung im PostViewer: relativ zur Bildbreite
25. Linke Schnittkante im PostViewer: relativ zur Bildbreite, Ursprung links unten
26. Rechte Schnittkante im PostViewer: relativ zur Bildbreite, Ursprung links unten
27. Obere Schnittkante im PostViewer: relativ zur Bildhöhe, Ursprung links unten
28. Untere Schnittkante im PostViewer: relativ zur Bildhöhe, Ursprung links unten
29. Linkes schwebendes Scheinfenster im PostViewer: relativ zur Bildbreite
30. Rechtes schwebendes Scheinfenster im PostViewer: relativ zur Bildbreite
    
    
31. Phantogram im PostViewer: Aufstellen des Raumbildes, Einheiten wie im Postviewer
32. EdgeTwist im PostViewer: Gegenseitige Verdrehung der linken und rechten Bildkante, Einheiten wie im Postviewer
33. Vertikale Achse im PostViewer: Rotation um Yaw-Achse (auch Gierachse genannt), Einheiten wie im Postviewer
34. Trapezverzerrung im PostViewer: Korrektur stürzender Linien, Einheiten wie im Postviewer
35. Skalierung in x-Richtung im PostViewer: >1: Dehnung, <1: Stauchung in x-Richtung
36. Parallelogrammverzerrung im PostViewer: Korrektur stürzender Linien, Einheiten wie im Postviewer
37. CroppOutput: verwendeter Parameter

Details for cosima_files.txt

For every analysis run (with EstimateGeometry = 1) Cosima creates an image list with all found analysis values. This is a pure ASCII text file. The name of this file is specified with the ListofImages parameter, the default is cosima_files.txt. With the WriteDataBase parameter you can also control, whether a new file should be created or whether an existing one continued.

Currently (version 0.9i4) the following entries are used:

1. Filename or (left-right separated input) filenames.
2. Identifier: OK (Okay): Image has been successfully corrected. Values are reliable. IM (Imperfect): The results of the correction are questionable, but the image has been corrected anyway and written under reserve. QU (Quit): Processing of the image was aborted in the PostViewer. No entry: The correction of the image was not successful.
3. Previewer: left image rotation in degrees: mathematical orientation, positive counterclockwise
4. Previewer: right image rotation in degrees: mathematical orientation, positive counterclockwise
5. PreViewer: (vertical) vergenz in degrees: negative, if toe-in is corrected
   
   
6. PreViewer: left image, left edge in percent of the original image width:
7. PreViewer: left image, lower edge in percent of the original image height:
8. PreViewer: left image, width in percent of the original image width:
9. PreViewer: left image, height in percent of the original image height:
10. PreViewer: right image, left edge in percent of the original image width:
11. PreViewer: right image, lower edge in percent of the original image height:
12. PreViewer: right image, width in percent of the original image width:
13. PreViewer: right image, height in percent of the original image height:
    
    
14. Height error in pixels: positive if right image is mounted too far up, measured in input pixel
15. Size error in percent: positive, if the right image is too large
16. Rotation error in degrees: positive, if the right image is positively rotated
17. Vertical vergence in degrees: positive, for convergent shooting axes
18. Horizontal vergence: positive, if right image from elevated position
    
    
19. Ratio of the result image: Width:Height
20. Applied lateral displacement: measured in input pixel
21. Deviation of the result image: relative to image width
22. Near point in the original image (geometrically corrected): measured in input pixel
23. Side lateral reference shift: This value is only used internally and is for the result without relevance, measured in input pixel
    
    
24. Manual lateral shift in the PostViewer: relative to image width
25. Left cutting edge in the PostViewer: relative to the image width, origin lower left
26. Right cutting edge in the PostViewer: relative to the image width, origin lower left
27. Upper cutting edge in the PostViewer: relative to image height, origin lower left
28. Lower cutting edge in the PostViewer: relative to image height, origin lower left
29. Left floating window in the PostViewer: relative to image width
30. Right floating window in the PostViewer: relative to image width
    
    
31. Phantogram in the PostViewer: Set up the spatial image, units like in the Postviewer
32. EdgeTwist in the PostViewer: Mutual rotation of the left and right image edges, units like in the Postviewer
33. Vertical axis in the PostViewer: rotation around yaw-axis, units like in the Postviewer
34. Trapezoid distortion in the PostViewer: Correction of tumbling lines, units like in the Postviewer
35. Scaling in x-direction in the PostViewer: >1: stretching, <1: compression in x-direction
36. Parallelogram distortion in the PostViewer: Correction of falling lines, units like in the Postviewer
37. CroppOutput: used parameter