PNG, JPG gibi EXIF ​​verilerini içeriyor mu?

PNG'nin aşağıdaki gibi veriler içerip içermediğini merak ediyordum.

Yaptığım şey jpg dosyasını png formatına dönüştürmekti ve jpg'de sahip olduğum bilgilerin aynısını aşağıdaki gibi almayı bekliyordum:

Şu anda verileri okumak için bu as3 kitaplığı kullanılıyor .

• IDF0 --- IDF @ [134 - 248] (9 giriş)
  • Oryantasyon (KISA): 1
  • XResolution (RASYONEL): 72/1
  • Y Çözünürlüğü (RASYONEL): 72/1
  • Çözünürlük Birim (KISA): 2
  • Yazılım (ASCIIx16): QuickTime 7.6.6
  • DateTime (ASCIIx20): 2011: 10: 02 22:43:37
  • HostComputer (ASCIIx16): Mac OS X 10.6.8
  • Exif IFD (UZUN): 8 34853
  • GPS IFD (UZUN): 248

• EXIF IDF --- IDF @ [8-134] (10 giriş)
  • ExifVersion (UNDEFINEDx4): 0220
  • DateTimeOrigina (ASCIIx20): 2011: 04: 14 17:22:01
  • UserComment (UNDEFINEDx63): ASCII
  • FlashpixVersion (UNDEFINEDx4): 0100
  • ColorSpace (KISA): 1
  • PixelXDimension (UZUN): 1022
  • PixelYDimension (UZUN): 486
  • Bilinmeyen (ASCIIx13): Resim Etiketi-LOL
  • SceneCaptureType (KISA): 0

• GPS IDF - IDF @ [248 - 338] (7 giriş)
  • Birlikte Çalışabilirlik Endeksi (ASCIIx2): N
  • Birlikte Çalışabilirlik Sürümü (RATIONALx3) @ 425: 52/1, 1144/100, 0/1
  • Bilinmeyen (ASCIIx2): W
  • Bilinmeyen (RATIONALx3): 1/1, 4392/100, 0/1
  • Bilinmeyen (RASYONEL): 5/1
  • Bilinmeyen (ASCIIx2): T
  • Bilinmeyen (RASYONEL): 3694/117

Düzenleme: PNG 1.2 Spesifikasyonu Uzantılarının Sürüm 1.5.0 (Temmuz 2017) sonunda bir EXIF ​​parçası ekledi. Kodlayıcı-kod çözücülerin onu desteklemeye başlayıp başlamayacağı görülecek.

Orijinal: PNG, EXIF ​​bilgilerini yerleştirmez. Bununla birlikte, görüntünün içine meta veri " parçalarının " yerleştirilmesine izin verir . Standartlaştırılmış parçalardan bazıları birkaç EXIF ​​özelliğine (fiziksel boyutlar, zaman damgası) karşılık gelir. Ayrıca, rastgele metin verilerini key=>valueçiftler halinde depolamak veya yeni yığın türleri tanımlamak da mümkündür . Yani, teoride herhangi bir EXIF ​​bilgisini depolayabilirsiniz ... ama, ne yazık ki, kendi özel formatınızda. Görünüşe göre, bazı standarlaştırma girişimleri başarısız oldu.

Düzenleme: Temmuz 2017 itibarıyla PNG resmi olarak EXIF ​​meta verilerini ( spesifikasyon ) depolamak için bir eXIf parçasını desteklemektedir . ExifTool 10.59 ve sonraki sürümleri, PNG görüntülerinde bu yeni parçaya EXIF ​​yazar.

Orijinal: ImageMagick, EXIF ​​bilgilerini JPEG görüntülerden dönüştürürken PNG "Raw profil tipi APP1" zTXt yığınında depolar. EXIF'i PNG görüntülerinde saklamanın bu yöntemi ExifTool tarafından da destekleniyor (ve bence Exiv2 de), ancak PNG veya EXIF ​​spesifikasyonunun bir parçası değil.

PNG, EXIF ​​bilgilerinin gömülmesini desteklemez. JPEG'den PNG'ye dönüştürdüğünüzde bilgiler kaybolur.

İtibariyle Temmuz 2017 olarak adlandırılan EXIF verileri ... için tescilli öbek olacaksa görünüyor EXIF :

EXIf öbeğinin veri segmenti, JPEG APP1 işaretçisi, uzunluğu ve "Exif 4.7.2 (C) 'de açıklanan kimlik kodu ", yani" Exif ", NULL ve doldurma baytı dahil değildir.

Bunun hem A) sadece birkaç aylık (yazarken) hem de B) isteğe bağlı bir uzatma olduğunu, temel spesifikasyonun parçası olmadığını unutmayın. Bu nedenle, eXIf parçası desteği birçok uygulamada sınırlı olabilir.

Demek istediğin:

1. PNG dosyaları, listelediğiniz meta veri öğelerini içeriyor mu? Kısa cevap: Değişir.
2. PNG bu tür meta verileri depolamak için EXIF ​​standardını kullanıyor mu? Kısa cevap: Genellikle hayır.

Genellikle PNG, meta verileri depolamak için PNG standardının parçası olan çeşitli parçaları kullanır. Listenizi gözden geçirmek için:

• Yön - PNG için geçerli değildir - sol üstten başlayarak satır satır sabitlenir.
• XResolution, YResolution, ResolutionUnit - pHYs parçası.
• Yazılım, HostComputer, diğer metinsel meta veriler - tEXt, iTXt, zTXt parçaları.
• DateTime - Bunun tarih / saatinin ne olduğu bana açık değil. saat, görüntü verilerinde yapılan son değişiklik tarihini / saatini gösterir; diğer tarihler / saatler metin yığınlarında saklanabilir. Oluşturma Zamanı aslında tanımlanmış bir metin parçası anahtarıdır, ancak biçim ve saat dilimlerinin nasıl işlendiği öngörülmemiştir, bu da kötü bir tasarımdır.
• ColorSpace, PixelXDimension, PixelYDimension - bunların nasıl meta veriler olacağından emin değilim. Görüntünün temelini oluştururlar ve bu nedenle IHDR yığınında yer alırlar .
• Listelediğiniz diğerlerinin ne anlama geldiğinden emin değilim.

Ancak şaşırtıcı bir şekilde, son yıllarda resmi uzantı parçaları listesine bir eXIf parçası eklenmiştir (esasen PNG özelliğine bir ektir ). Muhtemelen JPEG / TIFF'den PNG'ye dönüştürülen dosyalardaki bilgileri korumayı hedefliyor ve orijinal olarak PNG olarak oluşturulan dosyalarda kullanılması amaçlanmıyor, ancak bu net değil.

Evet ve hayır.

Diğer yanıtların daha önce de belirttiği gibi, PNG eXIfv1.5.0 (2017) 'de eklenene kadar resmi bir EXIF ​​parçasına sahip değildi ve bildiğim kadarıyla bu yığın hala geniş bir desteğe sahip değil.

Ama bunun sebebi buna ihtiyacı olmamasıdır. Birçok yazılım parçası, EXIF'i bir PNG'de, "Ham profil tipi APP1" olarak gösterilen bir iTXt(veya sıkıştırılmış zTXt) öbek şeklinde kodlayarak bir PNG'de kodlar . Yeni parçanın bunun için standart bir konum sağlaması amaçlanmıştı, ancak bence gemi şimdi yelken açtı.eXIf

Ek olarak, EXIF ​​standardının meta verilerinin çoğu, tam olarak bu amaç için bir EXIF ​​ad alanına sahip olan alternatif ve daha yeni bir meta veri taşıma mekanizması olan XMP ile temsil edilebilir. PNG dosyaları, iTXtyıllardır yığınlar halinde XMP belgelerini (çevrilmiş EXIF ​​meta verileri dahil) içerir . Birçok işlemcinin anında ikisi arasında dönüşüm yaptığını göreceksiniz.