EasyOCR İncelemesi: Temiz Metinde Güçlü Sonuçlar, Boyutta Keskin Bir Eşik ve CPU’da 1 GB’lık Süreç

EasyOCR, JaidedAI’nin Python için kullanıma hazır OCR kütüphanesi: pip install easyocr, iki satır kod ve görselin içine gömülü metin string olarak geri gelir. Apache-2.0 lisanslıdır, 80’den fazla dili desteklediğini belirtir ve iki PyTorch modelinden oluşan bir akış olarak çalışır: metin olabileceğini düşündüğü alanların etrafına kutular çizen bir CRAFT dedektörü, ardından bu kutuların içindeki karakterleri okuyan bir tanıyıcı. Önceden eğitilmiş ağırlıklar ilk kullanımda otomatik olarak indirilir. Yapı olarak, sayfa başına çalışan bulut OCR API’si değil; Tesseract ve PaddleOCR’a benzer, kendi sunucunuzda çalıştırabileceğiniz bir alternatiftir.

Temel API oldukça kısadır: Reader(['en']), ardından readtext(). Ancak dağıtım tarafı daha ağırdır — bu ortamda yaklaşık 2 GB PyTorch bağımlılığı ve ölçülen yeni bir işlemde kabaca 1 GB’a yakın en yüksek resident memory kullanımı. 36 İngilizce PNG test görseli hazırladım, CPU üzerinde easyocr 1.7.2 çalıştırdım ve okumaları üretilmiş gerçek veriyle karakter karakter karşılaştırdım. En büyük CER düşüşlerini boyut ve yön sorunu yarattı; panel ayrıca kısa token tespiti ve dolar işareti okuma hatalarını da ortaya çıkardı.

Bu hataların en çarpıcısı, herkesin önerdiği tek parametreyle ilgili. rotation_info, döndürülmüş görseller için asıl çözüm olarak issue tracker’da ün kazanmış durumda; bu yüzden aynı cümlenin üç farklı ortogonal döndürülmüş kopyasında denendi. 270°’de, iddiasını tam olarak yerine getirdi ve karakter hata oranını 0.83’ten 0.10’a çekti. 180°’de yarı yarıya işe yaradı: 0.85’ten 0.67’ye düştü ama bir ifade kayboldu. 90°’de ise ters tepti, 0.81’den 0.92’ye çıktı ve tanıyıcı ayna görüntüsü gibi metinler üretmeye başladı. Aynı parametre, aynı açı listesi, üç farklı sonuç — yani bunu açmak, size “dönüş sorunu çözüldü” garantisi vermez. Aynı 36 test görseli ayrıca belirgin bir yazı boyutu eşiği, sistematik dolar işareti hatası ve tamamen yanlış çıkan bir tahmin de üretti.

İki model, tek trençkot

EasyOCR tek model değildir. İki aşamalı bir boru hattıdır ve hangi aşamanın başarısız olduğunu bilmek, nasıl hata ayıklayacağınızı değiştirir.

Birinci aşama CRAFT, yani dedektördür. Tek görevi yer tespiti yapmaktır — görüntünün neresinde metin olduğunu belirleyip kutuları geri vermek. Hiçbir karakteri okumaz. İkinci aşama ise bir CRNN tanıyıcıdır — ResNet özellik çıkarımı, ardından BiLSTM, ardından CTC greedy decoding — ve her kutunun içindeki karakterleri okur. İkisi de PyTorch üzerinde çalışır. CPU’da tanıyıcı, varsayılan olarak dinamik şekilde int8’e quantize edilir; bu da onu ham parametre sayısının düşündürdüğünden daha hızlı ve hafif yapar.

Pratik sonuç şudur: EasyOCR’nin iki tamamen farklı hata modu vardır ve bunlar farklı çözümler gerektirir. Dedektör hiç kutu çizmiyorsa, tanıyıcıyı ne kadar ayarlarsanız ayarlayın fayda etmez — karakterler boru hattına hiç girmemiştir. Kutular var ama metin yanlışsa, bu bir tanıma problemidir ve ön işleme sizi kurtarabilir. Okuduğum neredeyse her “EasyOCR metnimi atladı” başlığı bu ikisini birbirine karıştırıyor.

Projenin güncel durumu, 27 Temmuz 2026 itibarıyla kontrol edildi: 29.825 yıldız, 528 açık issue, Apache-2.0 ve v1.7.2 (Eylül 2024), ayrıca master’a son push Aralık 2025’te yapılmış. Bu tarihler mimari istikrarı ya da bakım sağlığını kanıtlamaz. Kullanıma almadan önce Python/PyTorch yığınınızla uyumu, bakım veren yanıtlarının güncelliğini ve girdilerinize uygun issue’ları doğrulayın.

OCR, CAPTCHA çözme ile sıkça ilişkilendirilir; ancak burada ele aldığımız kullanım senaryosu bu değildir. Bot tespitini aşmaya yönelik hiçbir şey test edilmedi ve burada böyle bir şey teşvik edilmiyor. Kapsam dahilindeki iş, okumaya hakkınız olan görsellerden ve ekran görüntülerinden metin çıkarmaktır.

Ne ölçtüm ve bu sayılar neyi kapsamıyor

Test seti, kendi oluşturduğum 36 PNG görselden oluşuyor: 35 tek satırlık görsel — yedi font, sekiz boyut, yedi kontrast seviyesi, yedi eğim açısı, üç ortogonal döndürme ve üç arka plan boyunca tarandı — buna ek olarak 19 ayrı etiketli öğeye sahip sentetik bir dashboard ekran görüntüsü. Her görsel, ground-truth etiketini yazan aynı işlemde sabit bir string’den (Sphinx of black quartz, judge my vow. 1234567890 — 48 karakter, büyük/küçük harf, rakam ve noktalama işaretleri karışık) üretildi; bu yüzden görüntü ile etiketi fiziksel olarak birbirinden kayamaz.

Doğruluk ölçütü character error rate (CER): karakter cinsinden Levenshtein uzaklığının ground-truth uzunluğuna bölünmesi. CER 0, mükemmel okuma demektir. CER 0.10, her on karakterden yaklaşık birinin yanlış olduğu anlamına gelir. Başlıkta büyük/küçük harfe duyarlı CER veriyorum; yanında da büyük/küçük harfe duyarsız sürümünü ekliyorum, çünkü “hata”nın büyük kısmının aslında harf durumundan kaynaklandığı ortaya çıkıyor.

Sınırları sayılardan daha önemlidir:

• Yalnızca İngilizce. english_g2 tanıyıcısı. EasyOCR 80’den fazla dili desteklediğini söylüyor; ben bir tanesini test ettim. Buradaki sonuçlar Latin olmayan yazılar için bir şey söylemez; o alan için yayımlanmış akademik OCR karşılaştırmaları referans alınmalıdır.
• Yalnızca sentetik veri. Fotoğraf değil, render edilmiş metin. Kamera gürültüsü, JPEG artefaktı, ışık değişimi, perspektif yok.
• El yazısı yok. Projenin kendisi de bunu henüz desteklenmeyen bir alan olarak listeliyor.
• Yalnızca CPU. macOS arm64, gpu=False. Makinede MPS vardı ama EasyOCR, CUDA olmayan her şeyde CPU kullanıyor. GPU performansı hiç ölçülmedi; bu yüzden burada GPU sayısı yok.
• Tek makine, tek sürüm. easyocr 1.7.2, torch 2.13.0, Python 3.12.

Özetle: Bunlar, temiz ve render edilmiş Latin metinde doğruluğun tam olarak nerede bozulduğunu gösteren kontrollü, tek değişkenli eğriler. Gerçek dünya veri kümesi puanı değiller ve onun yerini tutmazlar.

Kanıtlar bir not defterine hapsedilmiş değil, incelenebilir durumda. Test görseli üreticisi ve tam string’ler tests/build_fixtures.py ve tests/fixtures/ground_truth.json içinde; tanıma, zamanlama ve kaynak ölçümü tests/run_easyocr.py dosyasında; tests/metrics.py ise ham çıktılardan raporlanan hata oranlarını hesaplıyor. Ortaya çıkan tanıma kayıtları ve toplu metrikler artifacts/raw/ altında saklanıyor. Bu zinciri yeniden çalıştırmak, bu makine ve sürüm için kontrol yapmada faydalıdır. Yine de EasyOCR’nin sizin telefon fotoğraflarınızda, dillerinizde, düzenlerinizde ya da ön işleme zincirinizde nasıl davranacağını söylemez; bu nedenle üretim kabulü için bu görselleri sertifikasyon paketi gibi görmek yerine temsil edici girdiler eklemek gerekir.

Bir harness tuzağını özellikle belirtmek lazım, çünkü neredeyse yanlış bir başlık sayısı ürettiriyordu. İlk metrik geçişim, temiz siyah Arial için CER 0.375 raporladı; bu, en kolay giriş için bile çok kötü bir sonuç. Sorun EasyOCR değildi. Dedektör tek bir görsel satırı bir kelime kutusu ve bir rakam kutusuna bölmüştü ve benim naif y’ye göre sonra x’e göre sıralayıp birleştiren kodum rakamları öne koyuyordu. Satır farkındalığı olan gruplaya geçilince (kutuları dikey örtüşmeye göre grupla, sonra soldan sağa oku), temiz fontlar yaklaşık 0.04–0.10 bandına indi. Kendi OCR değerlendirmenizi kuruyorsanız, bu tuzak sizi de bekliyor olabilir.

Kurulum: yükleme küçük, bağımlılık büyük

pip install easyocr

Hepsi bu kadar — ama bu cümlenin çok az şeyi dürüstçe anlattığını söylemek gerek. Paket küçük; fakat beraberinde getirdiği şey yaklaşık 2 GB PyTorch. Sonra readtext() ilk kez çağrıldığında, EasyOCR ağırlıkları sessizce ~/.EasyOCR/model/ klasörüne indirir — toplam 93.7 MiB: bunun 79.30 MiB’i CRAFT dedektörü (craft_mlt_25k.pth), 14.44 MiB’i ise İngilizce tanıyıcı (english_g2.pth).

Bunu eğitimlerde kimse vurgulamaz: ilk çalıştırmada ağ erişimi gerekir ve indirme için bekleme olur; container içinde çalışan her dağıtım ya bu ağırlıkları imaja önceden koyar ya da soğuk başlangıçta indirmenin bedelini öder. Bir kez cache’e alındığında ise her şey çevrimdışı çalışır.

Soğuk Reader() başlatma — modellerin diskten RAM’e alınması, artı int8 quantization geçişi — birkaç çalıştırmada 1.3–1.7 saniye sürdü. Sonrasında:

import easyocr
reader = easyocr.Reader(['en'], gpu=False)
result = reader.readtext('screenshot.png')

Ve çalışır. İki satır, yapılandırma yok, model seçme telaşı yok. İsminin içindeki “easy” burada gerçekten hak edilmiş; sürtünme API’de değil, bağımlılık ağırlığında.

Temiz metin tabanı: karakterler neredeyse kusursuz, büyük/küçük harf değil

Yedi sistem fontu, beyaz zemin üstünde siyah, 32 px, her seferinde aynı string:

Ortalama CER 0.071; büyük/küçük harf normalleştirildiğinde ise 0.024’e düşüyor. Asıl bulgu bu fark. EasyOCR, temiz Latin metinde karakterleri kaybetmiyor — şekli doğru yakalıyor, harf durumunu ise yanlış yapıyor.

Özellikle vow kelimesini altı fontta VOW olarak döndürüyor (Comic Sans bunu Vow ile biraz yumuşatıyor). Impact ise ek olarak of → Of hatası yapıyor. Tekrarlayan diğer hata noktalama: cümlenin sonundaki nokta bazı fontlarda : ya da _ olarak geri geliyor. Georgia, büyük/küçük harfi umursamayı bıraktığınızda mükemmel okunuyor.

Bu bilginin pratik değeri gerçekten yüksek. Eğer sonraki adımınız fuzzy matching, anahtar kelime arama ya da metni bir dil modeline beslemekse, harf değişimi neredeyse hiçbir şey kaybettirmez. Ama hedefiniz bir veritabanı anahtarıyla birebir karşılaştırmaysa, her şeyi kaybedersiniz. Karşılaştırmadan önce harf durumunu normalize edin; EasyOCR’nin görünürdeki hata oranının yarısı ortadan kaybolur.

Courier’in en kötü olması da (0.1042) mantıklı: monospace fontlar karakter aralıklarını alışılmadık biçimde geniş tuttuğu için, tipik harf aralığını öğrenmiş bir CTC çözücü için bu daha zor.

Boyut eşiği, belgede söylendiği yerde tam olarak duruyor

readtext() içinde belgelenmiş bir parametre var: min_size=10; bu, yüksekliği 10 pikselden kısa tespit kutularını eliyor. Çoğu kişi bunu geçip gider. Oysa ekran görüntüsü veya PDF çıkarımı yapan herkes için API’deki en kritik sayıdır. Render edilmiş karakter yüksekliğini taradığımda ne yaptığını burada görebilirsiniz:

12 px ile 8 px arasında 0.04’ten 0.77’ye sıçrama, kademeli bir bozulma değil. Belgede açıkça söylendiği gibi çalışan bir filtre var ve bunun sonucu olarak yaklaşık 10 px altındaki metinler varsayılan EasyOCR için fiilen görünmez hale geliyor.

En iyi aralık 12–28 px; 16 px’te tam CER 0. Büyük boyutta, 40 px ve üstünde CER tekrar hafif yükseliyor — çünkü karakterler kaybolduğu için değil, vow → VOW dönüşü geri geldiği için. Büyük metin okumak daha zor değil; sadece 16 px’i kusursuz yapan yerleşim avantajını artık almıyor.

Ekran görüntülerinden metin çıkaran herkes için: Modeli suçlamadan önce render edilmiş karakter yüksekliğini kontrol edin. HiDPI ekranda 1× alınmış bir dashboard ya da 72 DPI’da rasterize edilmiş bir PDF sayfası, gövde metnini sıkça 10 px altına indirir. 2× yakalayın ya da OCR öncesi büyütün; böylece “EasyOCR sayfamın yarısını görmedi” sınıfındaki bug raporlarını tamamen atlamış olursunuz. Bunlardan hiçbiri mümkün değilse min_size’ı düşürün — ama gürültü bekleyin, çünkü bu filtre zaten çöp tespitleri bastırmak için var.

Döndürme: 10° tolerans ve simetrik olmayan bir düzeltme

Önce eğim. Küçük açılar, Arial 32 px, varsayılan ayarlar ile rotation_info=[90,180,270] karşılaştırması:

Varsayılan EasyOCR, yaklaşık 10°’ye kadar olan eğimi rahatça tolere ediyor (CER ≤ 0.083), 15°’de sallanıyor ve 20°’de dağılıyor. rotation_info, eğim için hiçbir şey yapmıyor; bu da ne yaptığını bildiğinizde mantıklı: sadece listelediğiniz açılarda yeniden deniyor ve 15° bir eğim 90, 180 ya da 270 değildir. 10°’de ise aslında biraz daha kötüleşti (0.021 → 0.083), çünkü yanlış açılı bir yeniden deneme güven oylamasını kazanabildi.

Ortogonal döndürmelerde iş garipleşiyor:

Aynı parametre. Aynı açı listesi. Üç farklı sonuç.

270°’de rotation_info, issue başlığında vaat edildiği gibi çalışıyor: CER 0.83’ten 0.10’a düşüyor ve bu gerçekten kullanılabilir bir okuma. 180°’de yarım çalışıyor — CER 0.67’ye iyileşiyor ama my vow. ifadesi tamamen düşüyor. 90°’de ise tersine gidiyor; 0.81’den 0.92’ye çıkıyor ve ham çıktı bunun nedenini gösteriyor: tanıyıcı ayna görüntüsü gibi string’ler döndürüyor. VOW, MOA olarak geliyor. quartz, zuuenb olarak geliyor. Bunları aynada okursanız doğru oluyor; eğlenceli bir parti numarası, ama veri hattı olarak işe yaramaz.

Bunu toplu metrikler yerine ham tahminlerle karşılaştırdım; çünkü ilk şüphem “birleştirme sırası karıştı” idi. Ama sorun bir birleştirme artefaktı değil — EasyOCR’nin gerçekten döndürdüğü şey buydu.

Mekanizma bir ölçüm değil, bir hipotez; dönüş konvansiyonu üzerine özel bir deney yapılmadı. Pillow pozitif açıları saat yönünün tersine render eder; bu yüzden yalnızca 270° render edilmiş görsel, tanıyıcının iyi başa çıktığı bir yeniden deneme yönüyle hizalanıyor olabilir ve 90° vakasında en yüksek puanlı yeniden deneme ters çevrilmiş bir yöne denk geliyor olabilir. Sebep ne olursa olsun, operasyonel ders buna bağlı değil:

Bu test, rotation_info’nun tüm yönlerde simetrik davranacağı varsayımının güvenli olmadığını gösteriyor. Girdilerinizde beklenen döndürmeleri doğrulayın; yukarı akışta yön normalizasyonu olası bir azaltım stratejisidir, bu üç render örneğinin zorunlu kıldığı bir kural değildir.

Yanlış çıktığım tahmin

İçeri girerken düşük kontrastın EasyOCR’nin zayıf noktası olacağını düşünüyordum. Soluk gri metinli beyaz zemin, klasik OCR başarısızlık hikâyesidir; üstelik bunun için belgelenmiş bir kurtarma yolu da var: contrast_ths=0.1 ile adjust_contrast=0.5, düşük kontrastlı kutuları güçlendirilmiş bir kopyayla tekrar çalıştırıp daha güvenilir sonucu tutar.

Hiç devreye girmedi, çünkü gerekmedi.

CER, Weber 0.14’e kadar — beyaz üstünde gri-220, ki metnin orada olduğunu doğrulamak için test görseline gözümü kısmak zorunda kaldım — temiz bandın dışına hiç çıkmadı. Ve kontrast artırma sütunu, her adımda varsayılan sütunla aynı kaldı; çünkü varsayılan zaten başarıyordu.

Arka planlar da aynı hikâyeyi anlattı. Her yerde siyah metin:

Setteki en gürültülü test görselinde bile mükemmel okuma.

Kapsam dar: Bu, sensör gürültüsü ve JPEG sıkıştırması olmayan, düz renkli düşük kontrast; fotoğraflanmış fiş değil. Bu test setinde en büyük başarısızlıkları geometri ve kısa token’lar yarattı; test edilen renk ve sentetik gürültü varyantları yaratmadı.

Gerçek bir senaryo: dashboard ekran görüntüsünden sayıları çekmek

Python ile OCR işlerinin büyük kısmı aslında buna dönüşür. Birisi size iç dashboard’un ekran görüntüsünü yollar, ya da sayıların yalnızca render edilmiş pikseller olarak bulunduğu grafik ağırlıklı bir analytics sayfasına karşı bir Python scraping pipeline çalıştırırsınız ve değerleri veri olarak almak istersiniz.

Ben bir “Sales Dashboard” penceresi render ettim — başlıklı koyu üst bar, dairesel avatar rozeti, üç KPI paneli, üç buton, 2×3 tablo — ve tüm 19 metin öğesini tam string’leri ve piksel kutularıyla etiketledim; sonra EasyOCR çıktısını kutu örtüşmesine göre bunlarla eşleştirdim.

Tespit geri çağırma: 19’un 16’sı. Kaçan üç öğe:

• tek harfli rozet, “A”
• tablo hücresi “Q1”
• tablo hücresi “Q2”

Ve “Q3” tespit edildi. Aynı font, aynı boyut, aynı sütun — dedektör benzer görünen iki karakterli bir token’ı bırakıp diğer ikisini kaçırdı. Tespit, görsel olarak benzer hücreler arasında tutarsızdı. Bu çalışmalarda çıktı deterministik olduğu için, bu durum rastgele “yazı tura” davranışının kanıtı değil. Benzer bir ekran görüntüsü kalite sorunu #460 içinde izleniyor.

Bulduğu 16 öğede metin neredeyse kusursuzdu: ortalama CER 0.027, 16’nın 13’ü birebir doğru. Başlıklar, etiketler, butonlar (“Save”, “Cancel”, “Export CSV”), sütun başlıkları ve virgülle gruplanmış sayılar CER 0 ile geldi. 1,284 doğru okundu, virgül dahil.

Üç kusurlu okumanın hepsi aynı hatadan kaynaklanıyor: dolar miktarları.

Dört dolar işaretinin üçü büyük S olarak okundu. Görsel olarak bakınca anlaşılır; ama bu, çıkarımını yaptığınız para alanlarının her birini bir karakterlik çöpe çevirebilir ve basit bir float() hepsinde hata verir.

Eğer ekran görüntüsü hattınız kısa etiketler veya para birimi içeriyorsa, büyütme, dolgu kırpma, alan beklentilerini daraltma veya sembol farkındalıklı son işlem gibi olası çözümleri doğrulayın. Burada bunların hiçbiri benchmark edilmedi; ayrıca baştaki S harfini düzenli ifadeyle değiştirmek meşru değerleri bozabilir. Düzeltmeleri yalnızca şema ve doğrulama kuralları güvenli kılıyorsa uygulayın.

Çalıştırma maliyeti

Aynı makinedeki sayılar (macOS arm64, CPU, tek host, muhtemel eşzamanlı yük altında ölçüldü — bunları evrensel benchmark değil, eğilim olarak değerlendirin):

Başlıca maliyet 94 MB’lık ağırlık değil — her worker süreci için yaklaşık 1 GB resident memory; buna bir de ~2 GB’lık torch kurulumu ekleniyor. Bir container’a sığıp sığmadığını belirleyen sayı budur ve kimsenin sık söylemediği sayı da budur.

Hız, kolay durum için gayet iyi. CPU üzerinde temiz tek satır için 0.1 saniyenin altı sıcak gecikme, rahatlıkla kullanılabilir. Ama bu gerçekten kolay durumdur: tek kısa, yüksek kontrastlı satır. “CPU’da EasyOCR on saniyeler sürüyor” yönündeki tekrar eden şikayetler büyük çok bölgeli belgeler ve tam tuval boyutundaki işler hakkındadır; ben bunları yeniden üretmedim — farklı iş yükü, dolayısıyla yalnızca alıntılıyorum.

Küçük bir miti de düzeltelim: detail=0, EasyOCR’yi daha hızlı yapmaz. Yalnızca dönüş değerinden kutuları ve güven skorlarını çıkarır. Hesaplama zaten yapılmıştır. Medyan farkı milisaniye düzeyindedir; bu da gürültüdür.

Artılar ve eksiler

Artılar

• Temiz, render edilmiş Latin metinde karakter geri çağırımı neredeyse mükemmel — büyük/küçük harfe duyarlı ortalama CER 0.071, büyük/küçük harfe duyarsız 0.024, 16 px’de tam CER 0 mümkün.
• Gerçekten iki satırlık API: Reader(['en']), sonra readtext(), yapılandırma yok, model seçimi yok.
• Söylentilerden çok daha kontrast dayanıklı: temiz metinde Weber 0.14’e kadar çökme yok ve gürültülü/eğimli/renkli arka planlar da bozmadı (gauss gürültülü görsel mükemmel okundu).
• Tespit ettiği ekran görüntüsü öğelerinde neredeyse kusursuz: ortalama CER 0.027, 16’nın 13’ü birebir, virgülle gruplanmış sayılar dahil.
• Deterministik. Buradaki tüm doğruluk sayıları iki tamamen bağımsız süreç çalıştırmasında byte-byte aynıydı; yalnızca süreler değişti.
• Apache-2.0 ve kendi sunucunuzda çalıştırılabilir; vendor kullanım ücreti yok, yalnızca hesaplama, bellek, depolama ve kuyruklama operasyonel maliyetleri var.

Eksiler

• Belgelendirilen min_size=10 eşiğinin altına sert çöküş — 8 px’de CER 0.77. Küçük UI metni varsayılan olarak görünmez.
• Eğim toleransı yaklaşık 10°’de duruyor ve 20°’de çöküyor.
• rotation_info simetrik bir çözüm değil: 270° toparlıyor, 180° kısmen toparlıyor, 90° daha kötüleşiyor ve ayna metin döndürüyor.
• Dedektör izole kısa token’ları düşürüyor — tek harfli bir rozet ve iki adet 2 karakterli hücre, benzer biçimdeki üçüncü hücreyi bırakırken.
• Para değerlerinde sistematik $ → S hatası (4’ün 3’ü).
• İşlem başına ~1 GB resident memory, üstüne ~2 GB torch bağımlılığı.
• En son sürüm Eylül 2024 tarihli; proje aktif evrim geçiren bir yapıdan ziyade oturmuş durumda.

Kimler kullanmalı, kimler uzak durmalı

Girdileriniz temiz, dik, makul boyutta render edilmiş metinse — ekran görüntüleri, UI yakalamaları, rasterize PDF’ler veya üretilmiş raporlar — ve vendor kullanım ücreti olmayan, kendi sunucunuzda çalışan bir Python boru hattı istiyorsanız EasyOCR’yi değerlendirin. Sentetik İngilizce CPU sonuçları bu senaryoya uygundur; fotoğraflar, el yazısı ve diğer yazı sistemleri ayrı test ister.

Aşağıdakilerden biri girdilerinizi tarif ediyorsa uzak durun. Fotoğraflar — benim sayılarım sentetik render metindir ve kamera gürültüsü, perspektif ya da ışık hakkında hiçbir şey söylemez. El yazısı — projenin kendisi bunu iddia etmiyor. Latin olmayan yazılar — EasyOCR 80’den fazla dili desteklese de ben bir tanesini test ettim; bu alanda referans sentetik İngilizce taramaları değil, yayımlanmış akademik karşılaştırmalardır. İstediğiniz gibi döndürülmüş girdiler — önce kendi yön düzeltmenizi yapmıyorsanız. Bellek kısıtlı dağıtımlar — worker başına bir gigabayt hızlıca büyür.

OCR seçmeden önce DOM’u ve ağ yanıtlarını inceleyin. İstediğiniz değerler zaten yapılandırılmış metin olarak mevcutsa, o kaynaktan çekmek OCR’nin tespit ve tanıma hatalarını ortadan kaldırır. OCR, pikselin tek mevcut temsil olduğu yerde kullanılmalıdır.

Alternatifler ve yığının içindeki yerimiz

EasyOCR Apache-2.0 lisanslı ve kendi sunucunuzda çalıştırılabilir; vendor kullanım ücreti yoktur ama gerçek hesaplama ve operasyon maliyeti vardır. PaddleOCR, Tesseract ve vision-language modeller bu benchmark’tan geçirilmedi; dolayısıyla birebir kıyas sonucu çıkarılmıyor.

Daha ilginç karşılaştırma OCR ile OCR arasında değil. OCR yapmanız gerekip gerekmediği.

Gördüğüm ekran görüntüsü çıkarma işlerinin çoğu, scrape edilmesi zor bir web sayfası için geçici çözümdür — JavaScript ile render edilen tablo, giriş arkasındaki dashboard, direnç gösteren site. Ekran görüntüsü alıp OCR uygulamak en kolay yol gibi gelir; ama elinizdeki gayet iyi yapılandırılmış metni çöpe atıp, sonra daha kötüsünü geri almak için bir dolar işareti vergisi ödüyorsunuz.

Yazar notu: Thunderbit, web sayfalarından veri çıkarmak için bizim yönetilen seçeneğimizdir. Bu görsel testlerinden geçirilmedi. Buradaki önemli sınır, kaynak temsilidir: yapılandırılmış web verisi varsa DOM/ağ çıkarımını kullanın; piksel tek kaynak olduğunda OCR’yi değerlendirin.

Aynı test tezgâhından ilgili okumalar: tam açık kaynak scraper karşılaştırması, Crawl4AI incelemesi ve seçicilere direnen sayfalar için AI destekli çıkarım üzerine daha geniş bir bakış.

Web Verisi Çıkarımı için Thunderbit’i Deneyin

Karar

EasyOCR kullanmalı mısınız? Evet — görselleriniz dikse, karakterleriniz en az 12 piksel yüksekliğindeyse ve Latin yazı okuyorsanız. Bu sınırlar içinde oldukça iyi: temiz metinde ortalama CER 0.071, büyük/küçük harf normalizasyonundan sonra 0.024, 16 px’te kusursuz okuma ve ününün düşündürdüğünden daha iyi kontrast dayanıklılığı. API gerçekten iki satır ve çıktı deterministik; bir boru hattını hata ayıklarken insanların söylediğinden daha önemli olan da bu.

Bu sınırların dışında ise belirli ve öğrenilebilir şekillerde başarısız oluyor. 10 px altındaki metinler min_size filtresinde kayboluyor. 20°’nin ötesindeki eğim okuma işini bozuyor. rotation_info bir ortogonal yönü düzeltiyor, bir başkasını yarım düzeltiyor ve üçüncüyü ayna metinle daha kötü hale getiriyor. Tek harfler ve iki karakterli token’lar dedektörden düşerken komşuları hayatta kalıyor. Dolar işareti S harfine dönüşüyor.

Test görseli hataları her iki aşamadan da geldi: geometri tarafında kaçırılan ya da yanlış yönlenmiş kutular ve tanıma tarafında dolar işareti karışması. Büyütme, yön normalizasyonu, dolgu kırpma ve şema farkındalıklı sembol düzeltmeyi evrensel çözüm değil, doğrulanması gereken adaylar olarak düşünün.

Yalnızca benim neredeyse yaptığım gibi, bozuk bir değerlendirme düzeni ve anlamadığınız bir sayı ile test etmeyin. Kendi test görsellerinizi üretin, ground-truth’unuzu tam olarak bilin ve kendi eşiğinizi bulun.

Web Verisi Çıkarımı için Thunderbit’i Deneyin Get Started Free

SSS

EasyOCR, üretim ortamında ekran görüntüsü metni çıkarmak için yeterince doğru mu? Sentetik dashboard’da eşleşen öğeler ortalama CER 0.027 ve 16’nın 13’ünde birebir doğruluk gösterdi. 19 öğenin 3’ü tespit edilmedi ve 4 dolar işaretinin 3’ü S oldu. Bunun kabul edilebilir olup olmadığı — ayrıca büyütme ya da şema farkındalıklı onarımın işe yarayıp yaramadığı — hedef düzenlerde test edilmelidir.

EasyOCR’nin okuyabildiği minimum yazı boyutu nedir? Pratikte, render edilmiş karakter yüksekliğinde yaklaşık 12 piksel. readtext() parametresi olan min_size=10, 10 px’den kısa kutuları eler ve etki eğim gibi değil, ani bir uçurum gibidir: 8 px’de CER 0.77, 10 px’de 0.15, 12 px’de 0.04 ve 16 px’de 0 idi. Taradığım temiz bant 12–28 px arasıydı. Kaynağınız HiDPI ekran görüntüsü olarak 1× yakalanmışsa ya da 72 DPI’da rasterize edilmiş bir PDF ise, min_size’ı düşürmek yerine OCR öncesi büyütme yapın; çünkü bu filtre çöp tespitleri bastırmak içindir.

rotation_info, EasyOCR’de döndürülmüş görselleri düzeltir mi? Güvenilir biçimde değil, simetrik de değil. Aynı cümlenin üç ortogonal döndürülmüş kopyasında rotation_info=[90,180,270] kullanıldığında, 270° görüntü temiz şekilde toparlandı (CER 0.83 → 0.10), 180° görüntü yalnızca kısmen toparlandı (0.85 → 0.67, bir ifade kayboldu) ve 90° görüntü daha kötü hale geldi (0.81 → 0.92); VOW → MOA gibi ayna metinler döndü. Ayrıca küçük eğim açıları için de hiçbir şey yapmaz; çünkü yalnızca listelediğiniz açılarda yeniden dener. EasyOCR’yi çağırmadan önce yönü düzeltmek, bu parametreye güvenmekten daha doğrudur.

EasyOCR ne kadar bellek ve disk kullanır? Ağırlıklar 93.7 MiB’dir ve ilk kullanımda ~/.EasyOCR/model/ klasörüne indirilir — bunun 79.30 MiB’i dedektör, 14.44 MiB’i İngilizce tanıyıcı içindir. Ölçülen yeni CPU sürecinde peak resident memory 984.5 MiB idi; buna yaklaşık 2 GB’lık torch kurulumu eklenir. Soğuk reader başlatma 1.3–1.7 saniye sürdü; temiz tek satır bu makinede p50 olarak yaklaşık 0.062 saniyede çalıştı. detail=0, dönüş biçimini değiştirdi; ölçülen çalışma süresini değil.

EasyOCR ticari kullanım için ücretsiz mi ve hâlâ bakımı yapılıyor mu? Evet, Apache-2.0 lisanslıdır; bu da esnek ve ticari kullanım için uygundur. 27 Temmuz 2026 itibarıyla depo 29.825 yıldız ve 528 açık issue seviyesinde, en son sürüm Eylül 2024 tarihli v1.7.2, master’a son push ise Aralık 2025’te yapılmış. Bunu terk edilmişten ziyade oturmuş bir proje olarak okuyun — mimari bir süredir çok değişmedi ve hareket issue tracker’a kaymış durumda. Üzerine inşa etmeden önce güncel lisansı ve sürüm durumunu kendiniz doğrulayın.