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.

Since conventional systems aim to represent phonemes, a correct reading is necessary and this requires expertise in the language being represented. For Ottoman, this is a deeper problem since the writing system is not actively used.

Labels should correspond to classes in the classification of visual elements. For example, in some cases we label ى, ي and ـيـ identically as y but their visual features are distinct from each other. In other cases, an identical letter is coded as y, e or i albeit represented identically in visual terms, because of their difference in reading. This makes visual classes mixed and fuzzy, and any measurement of performance gives little clue about the effectiveness of features or classifiers.

Here we document a new transliteration system for visual items in Ottoman Turkish. In this work, our aim is to provide a simple visual approach to transliteration and then devise necessary conversion tables into phonetic transliteration or transcription systems.

Except for numerals, words in Arabic-based writing systems are composed of items in two categories. The first category is a large letter group composed of a continuous movement of the pen, like کلمه. The other category is the smaller elements like dots and diacritics found around these larger items.

A visual transliteration should represent distinct visual elements differently. In order to keep simplicity in labeling and application, dotless letters will be used as base letters and the other letters will be written in terms of these dotless items.

A full letter code is composed of one base letter code and an optional set of diacritic codes. The base letter code is a small Roman letter. The diacritic codes have two parts: the first part is one of o, u or i, which mean over, under or ligature respectively. The second part of the diacritic code shows the type of diacritics and is a string of digits or letters. A full letter code conforms to the following regular expression: [a-h,j-n,p-t,v-z](([ou][0-9]+)|(i[a-h,j-n,p-t,v-z]))*

The letters o, u and i are not used as base letter codes, so there is no ambiguity in parsing the elements.

The tables for all visual elements can be found in Tables tab:baseletters, tab:diacritics and tab:numerals.

Letter Shape Transliteration Used in Letters

ا e ا

ٮ b ب, ت, ث, ن, پ, یـ

ح x ح, خ, ج, چ

د d د, ذ

ر r ر, ز

س s س, ش

ص z ص, ض

ط t ط, ظ

ع a ع, غ

ٯ f ف, ق

ک k ک, گ

ل l ل, ك

م m م

و w و

ه h ه, ة

ی y ی

ﺀ c ﺀ

Table: The Transliterations of Base Letters

Transliteration Description

1 Dot of ب, ن or خ

2 Dots of ق, ت or یـ

3 Dots of ث, ش or چ

5 ء hamza and also in ك

8 ـّ shadda

0 ـْ sukun

6 ـٓ madda

7 / sign above گ

4 ـَ fatha and ـِ kasra

9 ـُ damma

44 ـً fathatan and ـٍ kasratan

99 ـٌ dammatan

Table: Transliterations for Diacritics

Description Transliteration

۱ n1

۲ n2

۳ n3

۴ n4

۵ n5

۶ n6

۷ n7

۸ n8

۹ n9

۰ n0

Table: Transliterations for Numerals

The advantages of using this transliteration instead of a phonetic transliteration can be summarized as follows:

Representing visual elements in a phonetic way is not an optimal representation for Computer Vision research. The information from the phonetic representation slips into visual information which results in classes that bear no direct connection with visual features. In turn, these classes become harder to classify and understand.

The transliteration system described in this paper does not need expertise in the language. Anyone who recognizes the letters should be able to transliterate word images.

It is possible to denote single elements which do not represent a sound in the language with visual transliteration. No transliteration system for Arabic and similar languages represents diacritics as in Table tab:diacritics. This is important for Computer Vision, since these items are as legitimate visual elements on a paper as others. Without independent representation, these items would have to be represented along with others, and their classification could not be done independently.

The system is much more flexible than a phonetic transliteration system. It allows for the development of new letter signs by combining existing diacritics with base letters. For example, ﭪ is a letter not found in historical documents, but can be seen in modern Arabic to represent the v sound. Although not thought of beforehand, this can be represented as fo3 in the system we describe. There are also writing variations, for example, in Maghribi (Western) Arabic, the letter ف is written as ڢ but is phonetically identical. In a phonetic transliteration this difference is lost, but the visual transliteration is able to represent the usual case with fo1 and the specific case with fu1.

It is common in handwriting to attribute diacritics of one letter to another. For example, three dots in the middle of سر may be read as شر or سژ. In a phonetic transliteration system, the first might be represented as şr and the second as sj. This leads to complexity in describing such middle cases. In a visual transliteration system, these two are represented as so3r and sro3, in which we are able to write rules that exchange o3 between neighboring letters and decide for the best reading in later stages.

In handwriting and print, diacritics are especially written loosely. For example, three dots above ث are written as three separate dots in print, but usually contracted as a single shape in handwriting. For the print case, we can have so1o1o1 denoting three dots separately while for the handwriting case so3 is used and in an upper level, the former is converted to the latter by a rule specifying three separate dots mean a single three dot.

Table tab:ottoman-letters shows all letters of the Ottoman alphabet.

**Ottoman **Transliteration** Ottoman Transliteration Letter Letter** \\

ا e اَ eo4

اِ eu4 اُ eo9

أ eo5 إ eu5

آ eo6 ب bu1

پ bu3 ت bo2

ث bo3 ج xu1

چ xu3 ح x

خ xo1 د d

ذ do1 ر r

ز ro1 ژ ro3

س s ش so3

ص z ض zo1

ط t ظ to1

ع a غ ao1

ف fo1 ق fo2

ك lo5 گ ko7

ل l م m

ن bo1 ڭ lo5o3

ه h و w

ی y ـیـ bu2

لا lie ک k

Table: Ottoman Letters and Transliterations

I’m looking for a one-to-one mapping between the different visual elements of a word and its representation in UTF-8. The labels should be simple to remember, yet distinctive enough to represent visual variations of words.

I’m considering creating letter+digit codes. The letter part will reflect the most similar sound, and the digit will reflect the visual variation. In this case, I need a Latin letter for each letter in the Ottoman alphabet, but there are not enough letters in the standard Turkish alphabet to denote all the letters of Ottoman. So, how can I solve this?

For example, in Ottoman, a word is spelled as mnwr (mim-nun-vav-ra), following the Arabic orthography, but in Modern Turkish, the spelling reflects the pronunciation as münevver. Since a one-to-one mapping is not possible between these two writing systems, a set of possible Ottoman spellings must be produced using a regular expression.

When the parser sees münevver, it should convert this to a pattern like mv?nh?(a1)?ww?h?r. This pattern produces a set of strings, where mvnha1vvhr might be the longest and mnwr the shortest. By performing a dictionary search, the system can verify that there is a word in Ottoman spelled as mnwr, thus selecting it as the correct spelling.

The dictionary in our study consists of word labels. The system will look up a set of handwritten word images after this label lookup and search for these images in the document. It can also create a set of candidate images from the regular expression by rendering each candidate spelling.