PDF içindeki JPEG gerçekten JPEG olarak mı duruyor?

Evet, DCTDecode filtresiyle kodlanmış görseller gerçek JPEG verisidir ve dosyadan çıkarıldığında doğrudan .jpg olarak kullanılabilir. Bu, PDF'in akıllı bir tasarım tercihidir: JPEG'i çözüp yeniden sıkıştırmak yerine olduğu gibi saklar, böylece hem dosya küçük kalır hem ek kalite kaybı olmaz. FlateDecode ile saklanan görseller ise ham piksel verisidir ve çıkarılırken PNG gibi bir formata sarılması gerekir.

Bir görselin çözünürlüğü PDF'te nasıl belirlenir?

Görsel nesnesinin kendi piksel boyutları (Width/Height) ile sayfada kapladığı fiziksel alan arasındaki orandan hesaplanır. 2400 piksel genişliğindeki bir görsel sayfada 8 inç genişliğinde çiziliyorsa efektif çözünürlük 300 DPI'dır. Aynı görsel 4 inçe sığdırılırsa 600 DPI olur. Yani PDF'te görselin 'çözünürlüğü' sabit bir özellik değil, yerleştirme ölçeğine bağlı bir sonuçtur.

Neden bazı görseller yatay şeritlere bölünmüş?

Genellikle bellek verimliliği için. Tarayıcı yazılımları ve bazı PDF üreticileri çok büyük görselleri işlerken tamamını belleğe almak yerine şerit şerit işler ve dosyaya da öyle yazar. Sayfada birleşik görünürler çünkü şeritler tam bitişik konumlara yerleştirilir. Ham çıkarma her şeridi ayrı nesne olarak bulur ve ayrı dosya olarak verir.

SMask nedir, neden ayrı bir dosya olarak çıkıyor?

SMask (soft mask), bir görselin saydamlık bilgisini taşıyan ayrı bir gri tonlamalı görüntüdür. Her pikselin ne kadar saydam olduğunu 0-255 arası bir değerle belirtir. PDF'te saydamlık, görselin kendisine gömülü değil bu ayrı nesnede saklandığı için, ham çıkarma ikisini ayrı dosyalar olarak verir ve saydamlık kaybolur. Geri kazanmak için ikisini bir düzenleyicide birleştirmek gerekir.

PDF'te Görseller Nasıl Saklanır? XObject, Filtreler ve Maskeler

Bir PDF'i açtığınızda gördüğünüz fotoğraf, dosyanın içinde nasıl duruyor? Cevap ilk bakışta göründüğünden karmaşık: görsel verisi, renk bilgisi, saydamlık maskesi ve yerleştirme bilgisi ayrı yerlerde saklanır. Bu yazıda PDF'in görsel saklama mimarisini ve bunun çıkarma işlemine nasıl yansıdığını açıklıyoruz.

Image XObject: temel yapı

PDF'te bir görsel, Image XObject adı verilen bir nesne olarak saklanır. Bu nesne bir sözlük ve bir veri akışından oluşur:

<< /Type /XObject
   /Subtype /Image
   /Width 2400
   /Height 1800
   /ColorSpace /DeviceRGB
   /BitsPerComponent 8
   /Filter /DCTDecode
   /Length 458392
>>
stream
...(JPEG verisi)...
endstream

Anahtarların anlamı:

| Anahtar | Anlamı | |---|---| | /Width, /Height | Piksel cinsinden boyutlar | | /ColorSpace | Renk uzayı (DeviceRGB, DeviceCMYK, DeviceGray, Indexed) | | /BitsPerComponent | Kanal başına bit sayısı (genellikle 8) | | /Filter | Verinin nasıl kodlandığı | | /SMask | Varsa, saydamlık maskesi nesnesine referans | | /Decode | Renk değerlerinin ters çevrilip çevrilmeyeceği |

Kritik nokta: bu sözlük görselin sayfada nerede olduğunu söylemez. Konum ve ölçek bilgisi sayfa içerik akışındadır:

q
400 0 0 300 100 500 cm     % ölçek ve konum matrisi
/Im1 Do                    % Im1 görselini çiz
Q

Buradaki matris "bu görseli 400 punto genişlik, 300 punto yükseklikte, (100,500) konumuna çiz" demektir.

Bu ayrım, ham çıkarmanın davranışını açıklar: çıkarma görsel nesnesini alır, sayfadaki yerleştirmesini değil. Sayfada döndürülmüş, kırpılmış veya küçültülmüş görünen bir görsel, çıkarmada orijinal hâliyle gelir.

Filtreler: verinin nasıl kodlandığı

/Filter anahtarı, akıştaki verinin hangi sıkıştırmayla kodlandığını söyler. En yaygın olanlar:

/DCTDecode — JPEG sıkıştırması. Akıştaki veri gerçek bir JPEG dosyasıdır. Bu, PDF'in akıllı bir tasarım tercihidir: bir JPEG'i PDF'e eklerken çözüp yeniden sıkıştırmak yerine olduğu gibi saklar. Sonuç: dosya küçük kalır ve ek kalite kaybı olmaz.

Ham çıkarmada bu veriyi doğrudan .jpg olarak kaydedebilirsiniz — hiçbir dönüşüm gerekmez.

/FlateDecode — Kayıpsız zlib/deflate sıkıştırması. Akıştaki veri açıldığında ham piksel dizisi çıkar. Çıkarmada bu veriyi kullanılabilir bir formata (genellikle PNG) sarmak gerekir — çünkü ham piksel dizisi tek başına bir görsel dosyası değildir.

/JPXDecode — JPEG 2000. Nadir ama bazı tarama sistemlerinde kullanılır. Doğrudan .jp2 olarak çıkarılabilir ama birçok program bu formatı açamaz.

/CCITTFaxDecode — Faks sıkıştırması, siyah-beyaz taranmış belgeler için. Çok verimlidir; bir A4 sayfa taraması birkaç on kilobayt tutabilir. Çıkarmada TIFF'e sarılması yaygındır.

/JBIG2Decode — Gelişmiş siyah-beyaz sıkıştırma. CCITT'den daha verimlidir ama daha az yaygın destek görür.

/LZWDecode — Eski bir kayıpsız sıkıştırma, TIFF ve GIF'te de kullanılır.

Çıkarma aracının çıktı formatı bu filtreye bağlıdır. DCTDecode → JPEG, FlateDecode → PNG, CCITTFaxDecode → TIFF gibi. Bu yüzden aynı PDF'ten farklı formatlarda dosyalar çıkabilir.

Renk uzayları ve çıkarma sorunları

/ColorSpace anahtarı görselin renk yorumunu belirler:

/DeviceRGB — Standart ekran renkleri. Sorunsuz çıkar.

/DeviceGray — Gri tonlama. Sorunsuz.

/DeviceCMYK — Baskı renkleri. Burada sorun başlar: birçok görüntüleyici ve tarayıcı CMYK JPEG'leri düzgün açamaz veya renkleri ters gösterir. Ayrıca bazı CMYK JPEG'ler Adobe'un ters kodlama geleneğini kullanır ve /Decode [1 0 1 0 1 0 1 0] dizisiyle işaretlenir — bu bilgi görsel nesnesindedir, çıkarılan JPEG dosyasında değildir. Sonuç: çıkan dosya negatif görünebilir.

/Indexed — Palet tabanlı renk. Görsel verisi palet indeksleri içerir ve gerçek renkler ayrı bir palet dizisinde saklanır. Çıkarma sırasında palet uygulanmazsa görsel anlamsız renklerde çıkar.

/ICCBased — Gömülü renk profili. Doğru renk için profilin de aktarılması gerekir.

Bu yüzden ham çıkarmada bazı görsellerin renkleri "yanlış" görünebilir. Bu bir hata değil; renk yorumlama bilgisinin görsel dosyasının dışında olmasının sonucudur.

Saydamlık: SMask mekanizması

PDF'te bir görselin saydamlığı, görselin kendisine gömülü değildir. Ayrı bir yumuşak maske (soft mask) nesnesinde saklanır:

/SMask 15 0 R

15 numaralı nesne, ana görselle aynı boyutlarda, gri tonlamalı bir görüntüdür. Her pikselin değeri o noktadaki opaklığı belirtir: 0 tamamen saydam, 255 tamamen opak.

Ham çıkarmada bu iki nesne ayrı ayrı bulunur ve ayrı dosyalar olarak çıkar. Sonuç:

Ana görsel saydamlık bilgisi olmadan, opak olarak gelir. PDF'te saydam görünen arka plan artık siyah veya beyaz görünebilir.
Maske dosyası tek başına, siyah-beyaz bir siluet olarak görünür. Bozuk bir dosya değildir; maskenin kendisidir.

Saydamlığı geri kazanmak için ikisini bir görsel düzenleyicide birleştirmeniz gerekir: ana görseli açın, maskeyi alfa kanalı olarak uygulayın, PNG olarak kaydedin.

Bir de /Mask anahtarı vardır — bu, ikili (1-bit) stencil maske veya renk anahtarı maskeleme için kullanılır ve SMask'tan farklı çalışır ama benzer bir ayrılık sorunu yaratır.

Neden görseller parçalanıyor

Ham çıkarmada sık karşılaşılan durum: sayfada bir fotoğraf var ama on ayrı şerit dosyası çıkıyor.

Sebep, PDF üreticisinin bellek yönetimidir. Çok büyük bir görseli tek parça olarak işlemek yerine, yatay şeritler hâlinde okuyup dosyaya yazar. Her şerit ayrı bir Image XObject olur.

Sayfada birleşik görünürler çünkü içerik akışı her şeriti tam bitişik konuma yerleştirir:

q 612 80 0 0 0 712 cm /Im1 Do Q
q 612 80 0 0 0 632 cm /Im2 Do Q
q 612 80 0 0 0 552 cm /Im3 Do Q

Bu davranış özellikle tarayıcı yazılımlarında ve bazı ofis programlarının PDF çıktılarında görülür.

Birleştirmek için parçaları bir düzenleyicide yan yana getirmek gerekir. Sıralamayı dosya adlarındaki numaralardan tahmin edebilirsiniz ama garantili değildir; görsel olarak eşleştirmek daha güvenilir.

Efektif çözünürlük kavramı

PDF'te bir görselin "çözünürlüğü" sabit bir özellik değildir. İki değerin oranından hesaplanır:

Efektif DPI = piksel genişliği / sayfadaki fiziksel genişlik (inç)

2400 piksellik bir görsel, sayfada 8 inç genişliğinde çiziliyorsa 300 DPI'dır. Aynı görsel 4 inçe sığdırılırsa 600 DPI olur.

Bu, ham çıkarmanın neden bazen sürpriz kaliteli görseller verdiğini açıklar: sayfada küçük görünen bir fotoğraf, orijinalinde çok yüksek çözünürlüklü olabilir. PDF üretilirken görsel küçültülmemiş, sadece küçük bir alana yerleştirilmiştir.

Tersi de doğrudur: PDF sıkıştırma işleminden geçmişse görseller gerçekten düşük çözünürlüğe indirilmiş olabilir ve ham çıkarma o düşük çözünürlüğü verir. Kaybolan piksel geri gelmez.

Görünmeyen görseller

Ham çıkarma bazen sayfada hiç görmediğiniz görseller de verir. Sebepleri:

Kırpma yolu dışında kalan alanlar. Bir görselin sadece bir kısmı gösteriliyor olabilir; nesne tamamını taşır.
Üzeri kapatılmış görseller. Sonra çizilen bir öğe altındakini gizlemiş olabilir.
Sayfa dışına yerleştirilmiş öğeler. MediaBox dışında kalan içerik dosyada durur.
Kullanılmayan nesneler. Bir düzenleme sonrası artık hiçbir sayfa tarafından referans verilmeyen görseller dosyada kalabilir.

Son madde gizlilik açısından önemli: bir PDF'ten görsel "silmek" için üzerine bir şey koymak yeterli değildir; nesne dosyada durmaya devam eder ve ham çıkarma onu bulur.

Vektör grafikler neden çıkarılamaz

Ham çıkarma yalnızca Image XObject nesnelerini bulur. PDF'teki logolar, şemalar ve grafikler genellikle vektördür — sayfa içerik akışındaki çizim komutlarıyla tanımlıdır, ayrı bir nesne değildir.

Bir vektör logoyu "çıkarmak" için farklı bir yaklaşım gerekir: sayfayı SVG'ye dönüştürüp orada logoyu ayıklamak.

Ayrım için basit test: PDF'te öğeyi çok yakınlaştırın. Pikselleşiyorsa raster (çıkarılabilir), keskin kalıyorsa vektördür (çıkarılamaz).

Özetle

PDF'te her görsel, kendi sözlüğü ve veri akışı olan bir Image XObject nesnesidir; konum ve ölçek bilgisi ise sayfa içerik akışındadır. Bu ayrım, ham çıkarmanın orijinal görseli verip sayfadaki hâlini vermemesinin sebebidir. Veri, filtreye göre gerçek JPEG olarak (DCTDecode) veya ham piksel olarak (FlateDecode) saklanır — çıkarma formatı buna bağlıdır. Saydamlık ayrı bir SMask nesnesinde durduğu için çıkarmada kaybolur ve iki dosya olarak gelir. Bazı üreticiler büyük görselleri şeritlere böldüğü için tek fotoğraf çok sayıda dosya olarak çıkabilir. Ve vektör grafikler bu mekanizmanın dışındadır; onlar için SVG dönüşümü gerekir.