Bir nesne tespiti projesinde en sinir 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 tip 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? Onu 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 ise 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 dur, 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 edilmis | Kutuphanenin ic mantigi |
Düzgün haliyle ş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 ise 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 olur.
Hmm, bunu nasıl anlatsamdı…
yolo formatındadır. Yani merkez nokta + genişlik/yükseklik ve hepsi normalize edilmiş halde 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 — yanında 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 sizi 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 ucu 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 olur.
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.
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.
