Bir nesne tespiti projesinde en sınır bozucu anlardan biri şu: görüntü güzelce dönüyor, kırpılıyor, parlaklık oynuyor… ama kutular kayıyor. Hani modelin gözü var sanıyorsunuz, meğer gözlük ters takılmış. İşin aslı şu ki, bounding box dönüşümü doğru yapılmadığında veri artırma fayda yerine sessiz bir sabotaj işine dönüşüyor.
Ben bu tıp hatayı ilk kez 2023 baharında, Kadıköy’de küçük bir ürün kataloğu projesinde görmüştüm. Görüntüler düzenliydi, etiketler de “doğru” görünüyordu; ama eğitimden çıkan sonuçlar tuhaf şekilde sağa sola sapıyordu (kendi tecrübem). Meğerse kırpma sonrası kutuların yarısı yanlış koordinat sisteminde kalmış (yanlış duymadınız). Açık konuşayım — o gün yarım saat değil, neredeyse yarım gün kaybettik. Albumentations burada bayağı işe yarıyor çünkü görüntüyle kutuyu birlikte taşıyor. Bu ne anlama geliyor? Önü da doğru anlatman gerekiyor, yoksa fark yok.
Durun, bir saniye.
Neden bbox konusu bu kadar kritik?
Görüntü sınıflandırmada iş nispeten rahat. Resim ya kedidir ya köpek. Nesne tespitinde işe aynı sahnenin içinde onlarca obje var. Her biri ayrı koordinatlarla temsil ediliyor — bu fark küçük görünüyor ama pipeline tasarımını baştan sona etkiliyor. Bir yatay çevirme işlemi yaptığınızda piksel dünyası değişiyor; eğer kutular yerinde sayarsa modeliniz yanlış yeri öğreniyor. Yani mesele sadece “augmentasyon yapmak” değil, augmentasyonu etiketle aynı ritimde yürütmek.
Albumentations’ın güzelliği tam burada başlıyor. Siz dönüşümü tarif ediyorsunuz, kütüphane hem pikseli hem de bounding box’ı aynı anda güncelliyor. Bu kulağa basit geliyor — ve açıkçası öyle de — ama pratikte hayat kurtarıyor. Geçen ay Şişli’de bir startup ekibiyle konuşurken bunu net gördüm; YOLOv8 kullanan ekipler veri setini COCO’dan YOLO’ya çevirirken hata yapmıştı ve sorun modelde sanılıyordu. Aslında — hayır dür, daha doğrusu sorun formatta çıkmıştı… klasik.
Bounding box augmentasyonunda en büyük hata çoğu zaman kod değil, varsayım oluyor. Etiket formatını yanlış kabul ettiğiniz anda bütün pipeline düzgün çalışıyor gibi görünür; fakat model yanlış bölgeleri öğrenmeye başlar.
Kutu formatları: Küçük fark, büyük bela
Kendi deneyimimden konuşuyorum, Albumentations birkaç farklı bbox formatını destekliyor ve burada doğru olanı seçmek şart. Herkesin verisi aynı damardan gelmiyor. PASCAL VOC başka konuşur, COCO başka, YOLO bambaşka… Hatta bazen aynı ekip içinde iki farklı annotation aracı yüzünden üç farklı dünya oluşuyor — bunu yaşamadan anlatamazsınız insana.
| Format | Koordinatlar | Birim | Nerede sık görülür? |
|---|---|---|---|
| pascal_voc | [x_min, y_min, x_max, y_max] | Piksel | PASCAL VOC ve özel veri setleri |
| coco | [x_min, y_min, genişlik, yükseklik] | Piksel | COCO tabanlı işler |
| yolo | [x_merkez, y_merkez, genişlik, yükseklik] | 0-1 arası normalize | Ultralytics YOLO ailesi |
| cxcywh | [x_merkez, y_merkez, genişlik, yükseklik] | Piksel | Kimi özel pipeline’lar |
| albumentations | [x_min, y_min, x_max, y_max] | Normalize edilmiş | Kütüphanenin ic mantığı |
Düzgün hâliyle şunu söyleyelim: pascal_voc köşe noktalarıyla çalışır; coco sol üst köşe artı genişlik/yükseklik kullanır; yolo merkez tabanlıdır ve normalize edilir; cxcywh işe yine merkez tabanlıdır ama piksel değerleriyle gider. Ben açıkçası yeni başlayanlara önce kullandıkları anotasyon aracının dışa aktarma biçimini kontrol etmelerini söylüyorum. Çünkü format yanlışsa sayıların hepsi “mantıklı” görünür… ama içerik çorba ölür.
Hmm, bunu nasıl anlatsamdı…
yolo formatındadır. Yani merkez nokta + genişlik/yükseklik ve hepsi normalize edilmiş hâlde gelir.
Aynı görüntüye dönüşüm uygulamak yetmez
Bazen insanlar augmentasyonu sanki yalnızca fotoğrafın üstüne filtre çekmek sanıyor. Değil işte. Nesne tespitte görüntünün — itiraz edebilirsiniz tabi — yaninda label listesi de taşınıyor olmalı — ikisi birbirinden koparsa ortaya sadece güzel görseller çıkar, model öğrenmez. Albumentations bunu A.Compose() ile hallediyor; siz de A.BboxParams() içine format bilgisini veriyorsunuz.
import albumentations as A
import cv2
import numpy as np
train_transform = A.Compose(
[
A.RandomCrop(width=450, height=450, p=1.0),
A.HorizontalFlip(p=0.5),
A.RandomBrightnessContrast(p=0.2),
],
bbox_params=A.BboxParams(
format='yolo',
label_fields=['labels']
)
)Kodun özü şu kadar basit aslında: “Kutular şu formattadır ve etiket isimlerini de beraber taşı.” Basit. Ama bu basitlik sızı kandırmasın — kırpma eklediğinizde bazı kutular kadraj dışında kalabiliyor, yatay flip yaptığınızda x koordinatı ters dönüyor, parlaklık değiştirince kutu değişmez ama görüntünün algısı değişiyor. Bunların hepsi birlikte düşünülmeli, sırayla değil.
E tabi kurumsal ölçekte bu daha da önemli oluyor. Veri setleri büyüdükçe hata sayısı geometrik artıyor sanki — küçük startup’ta belki fark edilmeyen şey enterprise tarafta haftalık rapora giriyor. Bir bankanın belge işleme projesinde 18 bin görselle çalışırken tek bir yanlış format yüzünden geri dönüş oranı düşmüştü; sorun bulunana kadar iki sprint geçti. Daha fazla bilgi için 50 Doların Altında Taşınabilir Monitör: MNN Fırsatı yazımıza bakabilirsiniz.
A.BboxParams içinde ne var?
Bence burada en çok atlanan şeylerden biri, bbox_params‘ın yalnızca format seçmediği gerçeği. Mesela hangi alanların label olduğunu da bildiriyorsunuz; ayrıca bazı durumlarda minimum alan filtresi veya görünürlük eşiği gibi ayarlar devreye girebiliyor. Yani burası bir tür trafik polisi gibi çalışıyor — sadece yön vermiyor, aynı zamanda yolda kalanları da ayıklıyor. Daha fazla bilgi için Cx Derleyici Günlüğü: Backend Bir Günde Nasıl Sıçradı? yazımıza bakabilirsiniz.
Bunu ilk kez İzmir’de bir arkadaşımın e-ticaret projesinde gördüm. Ürün fotoğraflarında sık sık yarım kalan kutular vardı ve model bunları “öğrenmeye değer” sanıyordu. Sonra visibility filtresi devreye alınınca metrikler biraz düştü — ilk bakışta hayal kırıklığı gibi durdu — ama gerçek test performansı toparlandı. Aslında daha dürüst sonuç almış olduk. Bazen düşük metrik iyi haberin habercisi oluyor (ki bu çoğu kişinin gözünden kaçıyor)
Kırpma stratejileri: Güzel fikir mi yoksa risk mi?
Cropping, yani kırpma işi nesne tespitte iki üçü keskin bıçak gibi. Bir yandan modeli yakın plan örneklerle besliyorsunuz, diğer yandan önemli nesneleri tamamen kadraj dışına atabiliyorsunuz —. İkisi arasındaki fark bazen tek bir parametre. En çok da de küçük objelerle uğraşıyorsanız dikkat etmek lazım; mesela drone görüntüsünde araç tespiti yapıyorsanız agresif crop bazen resmen felaket çıkarır. Daha fazla bilgi için Tarayıcıda Ekran Okuyucu Testi: 5 Dakikada Başla yazımıza bakabilirsiniz. Klasörlerden Hafıza Kurmak: Claude Code ile İkinci Beyin yazımızda da bu konuya değinmiştik. Yazılım Mühendislerinde Tükenmişlik: Sessiz İşaretler yazımızda da bu konuya değinmiştik.
- Küçük nesnelerde agresif crop kullanmayın.
- Sahnede az obje varsa crop oranını daha temkinli tutun.
- Sık kullanılan sınıflar için görünürlüğü düşük örnekleri elemek mantıklı olabilir.
- Tamamı beyaz veya boş kare üretmeyin; model boşluğu ezberlemeye başlıyor.
- Dengeyi validation tarafında da kontrol edin — sadece train set yetmez. (bence en önemlisi)
Lafı gevelemeden söyleyeyim: kırpmayı körlemesine açmak kötü fikir değildir ama iyi fikir de sayılmaz. Denedikten sonra örnek çıktıları tek tek görmek gerekiyor. Ben kendi projelerimde genelde ilk turda rastgele 20-30 augmented örnek inceliyorum; kutunun hâlâ objeyi sardığını görmeden eğitime geçmem. Bu bazen can sıkıcı geliyor — ama sonradan iki gün hata ayıklamaktan çok daha az can sıkıcı.
Kör nokta nerede çıkıyor?
Hani, Crop sonrası tamamen kaybolan kutuları nasıl ele aldığınız önemli. İki seçenek var: ya silersiniz ya da belli oranda görünenleri tutarsınız. Albumentations’ın yaklaşımı burada düzen getiriyor ama karar sizin — kütüphane karar veremiyor çünkü bu tamamen projenin mantığına bağlı.
Düşünün ki lojistik deposunda koli sayıyorsunuz, ama kameranın görüş alanına sadece kolinin yarısı giriyor. O yarımı sayıp bütün koli diye kayıt almak istemezsiniz, değil mi? Nesne tespitte de mantık aşağı yukarı böyle çalışıyor.
Sık yapılan hatalar ve küçük kurtarma taktikleri
Yani, Meseleyi teoriden pratiğe çekelim. En yaygın hata format uyuşmazlığı. İkinci sırada label field unutmak geliyor. Sonra da crop sonrası sıfırlanan kutuları kontrol etmemek… Bunların hepsi makul görünen hatalar olduğu için tehlikeli — kod patlamıyor, pipeline çalışıyor, grafikler çıkıyor… ve siz saatler boyunca neden sonuçların kötü olduğunu anlayamıyorsunuz.
- Anotasyon formatını doğrulamadan pipeline’a başlamayın.
- Dönüşüm sonrası birkaç örneği mutlaka görselleştirin.
- Eşik değerlerini körlemesine bırakmayın.
- Sadece train değil validation augmentasyonlarını da düşünün. (bu kritik)
- Tek kamera açısına güvenmeyin; sahadaki gerçek kullanım başka ölür.
Bak şimdi, Neyse uzatmayalım: bir test akışı kuracaksanız ben şunu öneririm — önce ham görüntüyü alın, ardından augmentation sonrası bbox’ları çizdirip karşılaştırın. Gözünüzle görmeden güvenmeyin. Geçen yıl Berlin’de katıldığım bir bilgisayarlı — en azından ben öyle düşünüyorum — görü buluşmasında herkes F1 skorundan konuşuyordu ama masadaki en faydalı demo basitçe “kutuyu nereye koymuşuz?” sorusunu cevaplayan demoydu. Sade, hızlı, dürüst.
Kişisel bir pratik ipucu
Şunu da ekleyeyim: augmentation pipeline’ınızı bir kez yazıp bırakmayın. Veri setiniz değiştikçe, kamera açısı değiştikçe, sınıf dağılımı değiştikçe bu parametrelerin de gözden geçirilmesi gerekiyor. Ben genellikle her yeni veri seti geldiğinde ilk 100 örnek üzerinde hızlıca bir görsel kontrol yapıyorum — beş dakika süren bu alışkanlık beni defalarca kurtardı. Küçük ama etkili.
Sıkça Sorulan Sorular
Albumentations’ta bounding box’ı yanlış formatta verirsem ne olur?
En yaygın sorun “kutular doğru görünüyor ama aslında koordinat sistemi yanlış” durumu. Format uyuşmazsa dönüşümler uygulanır; fakat etiketler görüntüyle aynı ritimde gitmez ve model yanlış bölgeleri öğrenir. Ben bir projede yanlış format yüzünden sonuçların ciddi şekilde sağa kaydığını görmüştüm; etiketler ekranda “mantıklı” görünüyordu ama eğitim boşa gidiyordu.
Görüntü augmentasyonu yaparken bbox dönüşümünü otomatik mi yönetmeliyim?
Evet, mümkünse tek bir augmentasyon pipeline’ı içinde hem görüntüyü hem de bounding box’ı birlikte güncellemelisin. Albumentations bunu özellikle bu amaçla tasarlıyor: sen dönüşümü tarif ediyorsun, kütüphane kutuyu da aynı şekilde taşıyor. En büyük fark da burada ortaya çıkıyor; ayrı ayrı yapınca istemeden asenkronluk kaçınılmaz oluyor.
COCO, Pascal VOC, YOLO… Hangisini seçmeliyim?
Seçim, elindeki etiket dosyasının gerçek formatına göre olmalı. COCO genelde [x_min, y_min, width, height] kullanırken, YOLO çoğu zaman [x_center, y_center, width, height] ve ayrıca 0-1 normalize değerler ister. Benim önerim, önce tek bir örneği görselleştirip (augmentasyon öncesi/sonrası) kutunun gerçekten doğru yere oturduğunu kontrol etmek.
Albumentations bbox’ta normalize mi, piksel mi kullanıyor?
Bu tamamen kullandığın bbox formatına bağlı. Bazı formatlar piksel koordinatlarını (ör. x_min/x_max), bazıları normalize değerleri (ör. YOLO) bekler. Albumentations tarafında doğru parametreyi/formatı seçersen dönüşümler doğru çalışır; yanlış seçimde ise kutular “sessizce” hataya düşer.
Kutu taşınması doğru mu diye nasıl hızlı kontrol yapabilirim?
En pratik yol: aynı görseli bir augmentasyonla dönüştür, sonra hem orijinal hem augmentasyonlu hali üzerinde kutuları görselleştir. Kutular görüntüyle birlikte dönüyor/kırpılıyor mu, sınırları taşmış mı, normalize/piksel dönüşümü doğru mu hızlıca anlarsın. Ben ekiplerle çalışırken bu kontrolü “ilk 10 görsel” kuralı gibi uygulatıyorum; zaman kazandırıyor.
Kaynaklar ve İleri Okuma
Albumentations Resmi Dokümantasyon
Microsoft Azure AI Services (Genel Kaynaklar)
Microsoft Docs: Görüntü/Koordinat İşleme Referansları
20+ yıl deneyimli Azure Solutions Architect. Microsoft sertifikalı bulut mimari ve DevOps danışmanı. Azure, yapay zekâ ve bulut teknolojileri üzerine Türkçe teknik içerikler üretiyor.
İlgili Yazılar
Bu içerik işinize yaradı mı?
Benzer içerikleri kaçırmamak için beni sosyal medyada takip edin.
