The reason I had to stop was the lack of data, since without a considerable amount of data, statistical methods for both Natural Language Processing and Computer Vision fail. Producing and maintaining data seemed a much greater burden than providing technical solutions, so I mostly gave up the idea that a working solution is obtainable with classical OCR techniques. The research is still waiting for me to finish.

I am beginning this series of explorations in Computer Vision, Machine Learning, and related fields to document my achievements and provide a basis for further research. From time to time, I will provide results regarding the ideas discussed here. Currently, this is mostly a hobby/side project.

My current endeavor is to write a robust translation engine between Ottoman and Turkish in Dart.¹

Instead of performing a full-fledged morphological analysis like TRMorph, Google Research Morphological Analyzer, or Starlang Morphological Analyzer, our aim is to provide a surface-level to surface-level translation between Arabic and Turkish scripts.

It is true that it’s possible to use something like:

+-----------------+                +----------------+                 +---------------+
|                 |                |                |                 |               |
|                 |                |                |                 |               |
|    kelimeler    |    +------->   |  kelime+PLU    |  +----------->  |   کلمهلر      |
|                 |                |                |                 |               |
|                 |                |                |                 |               |
+-----------------+                +----------------+                 +---------------+

to translate between Turkish Latin and Ottoman, but there are two problems here:

1. There is no Ottoman morphological analyzer, and although grammatically Turkish, surface-level forms should be translated. Even morphological analyzers for Turkish in the Latin alphabet are relatively recent.

2. Translating the output of a Turkish Latin morphological analyzer to Ottoman seems like more work than writing a translation method itself.

For example, for the query kelimeler TRMorph gives

    kelime<N><pl>
    kel<Adj><0><N><p1s><dat><0><V><cpl:pres><3p>
    kel<Adj><p1s><Prn><dat><0><V><cpl:pres><3p>
    kelime<N><0><V><cpl:pres><3p>
    kelime<N><pl><0><V>
    kelime<N><pl><0><V><cpl:pres><3p>
    kelime<N><pl><0><V><cpl:pres><3s>

and although most of the items’ surface forms are identical, we need to work through all suffixes and their different kinds of connections. Also, as the surface form of Ottoman Turkish has less information, Ottoman morphological analysis would yield many more results than its corresponding counterpart.

Because of these hindrances and trying to come up with a quick-and-dirty yet workable solution, I have made the following observations:

1. Our part-of-speech system does not need to be highly specialized. Actually, we only need to have three classes: Nouns, verbs, and proper nouns. Proper nouns are grammatically nouns, but their orthography may require different rules. We will call these three word classes.

2. We can get away with a set of surface-level rules to translate suffixes for each word class. These rules use attributes that can be derived from Turkish Latin orthography.

These rules are:

• Part of Speech: The root class we discussed above.
• Last Vowel: The last vowel in a Turkish root that is required to find the actual suffix when vowel harmony is utilized.
• Last Consonant: The last consonant of the Turkish root. This is needed to find the palatalization/softening of certain consonants.
• Ends with Vowel: Whether the root ends with a vowel, like ata, or not.
• Has Single Vowel: Whether the root has a single vowel. This is important for aorist inflection irregularities in verbs.
• Last Vowel Hard: Whether the last vowel is one of a, ı, o, u (back vowels) or not.
• Last Consonant Hard: Whether the last consonant is one of p, ç, t, k and undergoes softening when it receives a suffix starting with a vowel.
• Has Consonant Softening: The inverse of the last consonant hard rule, occurring when a root ends with b, c, d, g and receives a suffix.

From these rules, which can be derived from the Turkish Latin forms of the words using regular expressions, we can write rules to translate Turkish to Ottoman and vice versa.

To be continued.

1. Dart has the little benefit of being able to run both on mobile (in Android and iOS) and servers with support for the web, so write once, run on Linux, iOS and Android is feasible without much architecture jumping. I hope Flutter gains more traction and becomes the mainstream way of writing mobile applications. ↩

Here, I describe the transliteration system. The system is organized as a pipeline in which the tools at a stage produce the input for the next stage. The input to the system is a set of historical document images. The output is either a search result or a textual representation of these documents.

The sections below describe these stages briefly.

Binarize Color Images to Binary Images

Binarization is the process of converting color or grayscale images to black-and-white binary images. Document images come in various flavors, mostly as color images. Color information is mostly noise for further stages. It is better to remove the color while keeping the textual representation intact.

Although seemingly easy at first, this stage includes challenges like determining the ink color or removing ink stains from images.

In the literature, the standard idea is to use a mathematical model, like Otsu’s method, to convert color to binary. We approach this problem differently, as a classification problem. The idea is briefly as follows:

Color images consist of 3 channels. The ink color of a region should be persistently present or absent in these channels. For example, a dark blue ink should be represented within similar numeric ranges in each of these channels, and a red ink should be represented more in the red channel than others. A standard binarization approach tries to come up with a cumulative ink color value using all three channels. We do it differently.

Instead of trying to find a cumulative threshold for binarization, we detect edges in each channel, considering each channel as a separate binary image. When components in each channel are found, they are evaluated by various features (like size, presence in other channels) and classified as text or non-text.

After classification, the text elements are drawn to a canvas in black, and the document hence becomes binarized.

Extract Components: Convert Binary Images to Components

Although the components are extracted during the binarization stage, we extract them in an independent stage to have a definite input and output. The primary reason for this is to evaluate the performance of different binarization options. This stage works even if the binarization part uses another (standard) approach.

Binarized document images are converted to sets of components by finding their edges. Each component is recorded with its location and binary image.

Extract Features: Find Features of Components for Comparison

Each component can have several different features, such as height, width, number of holes, number of ascenders and descenders, etc. Some of these features work better than others in classification. However, we don’t know beforehand which ones work better than others.

In order to find a set of good features, we extract all the features we can think of and run a Principal Component Analysis (PCA) on them. Previously, since we lacked classifications for these components, it was impossible to find good features, and we had to check the outputs manually. However, now that we have labeled around 11,000 components from 50 handwritten pages, we can determine which features are better than others.

extract-features extracts a large set of features from the component set. These features are stored in CSV files and analyzed for their classification value.