
Turkish: 
JPEG videodan belki de net değil
JPEG iyi bir fikir olmadığı zaman.
Demek istediğim, birçok insan "ah, asla JPEG'i bilimsel görüntüler için kullanmamalısın" ya da öyle bir şey söylüyor.
Çünkü tamamen kayıplı sıkıştırma, bu eşitliği kaybedeceksiniz.
Ve bu doğru
ama aynı zamanda kayıplı sıkıştırmasını çok küçük görüntü blokları üzerine uyguladığınız anlamına da gelmiyor.
Böylece bir blok ile diğer blok arasında tutarlılık elde edemezsiniz
ama oldukça iyi görünecek ve çoğu görüntüleme için sorun değil.
Açıkçası pek çok insan çiğ olarak çekim yaparak yemin ediyor ve biliyorsunuz, onlara iyi şanslar.
JPEG çok daha az yer kaplar ve bu nedenle çoğu pratik amaç için bir JPEG görüntüsü iyidir.
JPEG görüntülerinin iyi olmadığı bir zamanlar metindir.
Çoğu insan JPEG artefaktlarını, yani metin etrafındaki görüntünün bit parçalarını gördü.
ve belki de neden JPEG sıkıştırma işleminin yalnızca bir yan etkisi olduğunu bilmiyoruz.
Özellikle, JPEG sıkıştırmasının metin üzerindeki yan etkisi
çünkü metin bizim varsayımlarımızı ihlal ediyor
yüksek frekans bilgisi görüntüye çok fazla katkıda bulunmaz.

English: 
It perhaps isn't clear from the JPEG video
when JPEG isn't a good idea.
I mean, a lot of people say "oh, you should never use JPEG for scientific images" or something like that
because it's totally lossy compression, you're going to lose those equality.
And that is true
but it's also not in a sense that you're applying its lossy compression over very very small image blocks.
So you won't get coherence between one block and the next
but it'll look pretty good and for most imaging that's okay.
Obviously lots of people swear by shooting in raw, and you know, good luck to them.
JPEG uses up a lot less space, and so for most practical purposes a JPEG image is fine.
One time where JPEG images are not fine is text.
Most people will have spotted JPEG artefacts, that is, speckly bits of image around text
and maybe not quite understood why that's there apart from it's just a side effect of JPEG compression.
Well specifically, it's a side effect of JPEG compression on text
because text violates our assumptions that
high frequency information doesn't contribute a lot to the image.

English: 
So this is a small 8x8 image that I've come up with to illustrate its purpose.
So this is, in a sense, text. This is the Computerphile C with its little triangular brackets.
It's 8x8, so it's not the highest resolution, but it serves our purpose quite well.
One thing that this image has that our last image of the flower didn't have is sharp changes in intensity.
So this C has a sharp step down into the background
and that is not something that JPEG handles very well at all.
If we look at the encoded luminosity block of this
we get this.
So this is our C represented as just 0 to 255 luminosity values.
So these are our background ones of about 48.
This is our C here
and our brackets here
Each of these represents the greyscale intensity of that corresponding pixel in our 8x8 image.
Now if we were encoding this in JPEG, what we would then do is we would shift all these
and we would calculate our DCT coefficients.
And then we would get rid of the high frequency ones and we would encode them.
And in doing so, we massively compress the image at what we assume to be a pretty reasonable quality.

Turkish: 
Yani bu, amacını açıklamak için geldiğim küçük bir 8x8 görüntüsü.
Yani bu, bir anlamda, metin. Bu, küçük üçgen braketleriyle Computerphile C'dir.
8x8, bu yüzden en yüksek çözünürlük değil, ancak amacımıza oldukça iyi hizmet ediyor.
Bu görüntünün çiçeğin son görüntüsünün sahip olmadığı bir şey, yoğunluktaki keskin değişimlerdir.
Yani bu C arka plana keskin bir adım attı
ve bu JPEG'in hiç de iyi işlemeyeceği bir şey değil.
Şunun kodlanmış parlaklık bloğuna bakarsak
Bunu anladık.
Yani bu bizim C'miz sadece 0 ila 255 parlaklık değeri olarak temsil edilir.
Yani bunlar bizim 48 yaşında geçmişimiz.
Bu bizim c burada
ve burada parantez
Bunların her biri, 8x8 görüntüdeki ilgili pikselin gri tonlama yoğunluğunu temsil eder.
Şimdi, bunu JPEG olarak kodlarsak, o zaman yapacağımız şey tüm bunları değiştireceğimizdir.
ve DCT katsayılarımızı hesaplardık.
Ve sonra yüksek frekanslardan kurtulup onları kodlardık.
Ve bunu yaparken, görüntüyü oldukça makul bir kaliteye sahip olduğumuza kitlesel biçimde sıkıştırıyoruz.

Turkish: 
Ancak bu durumda bu doğru değil.
DCT katsayılarına bakarsak
Büyüklerin her zaman sol üstte olduğunu varsaydığımızı görebilirsiniz.
böylece düşük frekans görüntüye daha fazla katkıda bulunur.
fazlasıyla ihlal edildi.
Bu özel katsayı, örneğin, yalnızca 0.8'e katkıda bulunur.
Sanırım bu, son videomuzda 200 ya da benzeri bir değerdi.
Aşağıda, büyük, büyük katsayılarımız var. 30, 67.5, 53, -53.
Hepsi bu gerçekten yüksek frekanslı kosinüs dalgaları.
Öyleyse DCT'nin yanındaki logo katsayılarımıza bakarsak
Esasen sahip olduğumuz şeyin buradaki kaybı olduğunu görebiliyoruz, bu yüzden bu.
Demek ki bu C buna çok katkıda bulunuyor.
Hangi tür görebiliyorsunuz çünkü içinde bir tür C şekli var.
Ve bu yüzden, belki de bunun sahip olacağı katkıyı tam olarak anlamak zor.
Çünkü bu katsayılar temelde keyfi sayılardır.
Fakat mesele, bu görüntünün, bu yüksek frekans bölümlerinin çoğunun eklenmesi olduğu.
ve bu düşük frekanslı olanlardan çok daha az.

English: 
But that isn't true in this case.
If we look at the DCT coefficients
you can see that our assumption that the big ones are always in the top left
so that the low frequency contributes more to the image
is hugely violated.
This particular coefficient, for example, only contributes 0.8.
That was, I think, a value of 200 or something in our last video.
Down here we have big, big coefficients.  30, 67.5, 53, -53.
All in these really high frequency cosine waves.
So if we look at our logo coefficients next to our DCT
We can see that what we've essentially got is a loss of this one here, so that's this one.
So this C has a lot of this particularly contributable one
which you can kind of see because there is a kind of C shape in it.
And so, it's hard perhaps to grasp the exact contribution that this will have
because these coefficients are essentially arbitrary numbers
But the point is that this image is the addition of lots of these high frequency sections
and a lot less of these low frequency ones.

English: 
So when we do our standard quantization, we're going to divide all of these numbers by huge amounts
and set most of them to 0
and that's going to be a big problem, because when we then recreate the image on the other side
we're going to find that what was vital in creating this image is now gone and we're not going to get it back.
And in fact that's exactly what you do see. So if we show the actual output here
we can see that our C is kind of visible
but is being completely dwarfed by all this random noise that's been added
to the edge of our text. And this is exactly what happens in normal
compression of text using JPEGs.  Essentially we assume
just like in normal nature photographs
that we can get rid of the high frequency information
and we couldn't do that.  That was a bad
idea. And so we've got all this stuff that
we shouldn't have.
If we look at the block when compared to the
original we can see that this value is 48.  It's now 66.
So a lot of these values have changed by
quite a large amount.  In our last video
I think the standard error between
the old and the new were something like 3.

Turkish: 
Bu yüzden standart nicelememizi yaptığımızda, tüm bu sayıları büyük miktarlara böleceğiz.
ve çoğunu 0'a ayarlayın.
ve bu büyük bir problem olacak, çünkü o zaman görüntüyü diğer tarafa yeniden yarattığımızda
Bu görüntüyü oluştururken hayati olan şeyin şimdi gittiğini ve geri alamayacağımızı bulacağız.
Ve aslında tam olarak gördüğünüz budur. Yani burada gerçek çıktıyı gösterirsek
C'mizin görünür olduğunu görebiliriz.
ancak eklenen tüm bu rastgele sesler tarafından tamamen cüce ediliyor.
metnimizin kenarına. Ve bu tam olarak normalde olur
JPEG’leri kullanarak metnin sıkıştırılması. Temelde biz varsayalım
tıpkı normal doğa fotoğraflarındaki gibi
yüksek frekans bilgisinden kurtulabileceğimizi
ve biz bunu yapamadık. Bu kötü oldu
fikir. Ve böylece elimizde bu kadar şey var
yapmamalıydık.
Bloğa baktığımızda, karşılaştırıldığında
orjinal değerinin 48 olduğunu görebiliyoruz. Şimdi 66.
Yani bu değerlerin çoğu tarafından değişti
oldukça büyük miktarda. Son videomuzda
Bence standart hata arasında
eski ve yeni, 3 gibi bir şeydi.

Turkish: 
Ortalama olarak yaklaşık 3, yukarı veya
aşağı. Bu yaklaşık 11.
Piksellerimizde elde ettiğimiz ortalama hata miktarının üç katından fazla.
Ve bu metin olduğu için, çıktı görüntüsünde bunu açıkça görebiliyoruz.
Yani, bunun çözümü, gerçekten, çok fazla miktarda metniniz olduğunda JPEG'i kullanmamaktır.
aklımda o C aşağı bir 8x8 bloğa sığdırmak için küçülmüş.
Aslında, isterseniz, bir işaretiniz olurdu.
Bir mektubun büyük miktarda görüntü aldığını göreceksiniz.
ve belki de sadece küçük bir kenarını sıkıştırıyorsunuz ve o kadar da kötü görünmeyecek.
Ama kesinlikle, eğer
Yüzde 50 metin içeren JPEG
veya daha düşük kalitede başlayacaksınız
JPEG yapılarını görmek için
Bu yüksek frekanslar kaldırıldığından, benekleri alırsınız.
o yerde donuk olurlardı. Kötü bir şekilde yüklerseniz, aslında görmüş olabilirsiniz
sıkıştırılmış metin belgesi
yakınlaştırdığınızda, iyi ölçeklenmiyor ve
bu yüzden
e-okuyucular böyle bir şey kullanmazlar, metni sıralamaya çalışırlar
kaynaktan olduğu gibi ve bu şekilde bu sorunların hiçbirine sahip değiller.
İşin ilginç yanı, bu hasar bir kez yapıldığında

English: 
On average they changed about 3, up or
down.  This is about 11.
It's over triple the amount of sort of average error that we're getting in our pixels.
And because it's text, we can see that very clearly in the output image.
So, the solution to this, really, is not to use JPEG when you've got a huge amount of text
bearing in mind that I shrank that C down to fit into one 8x8 block.
In actual fact you would have, if you had like, a sign
you would find that a letter took up a huge amount of the image
and so maybe you are only compressing one small edge of it and it won't look so bad.
But certainly, if you're compressing your
JPEG with text in it at 50 percent
or lower quality you're going to start
to see JPEG artifacts where
because these higher frequencies have been removed, you get kind of speckles
where they would have dulled that down.  You might have seen it actually, if you load up a poorly
compressed text document
that when you zoom in it doesn't scale well and
that's why
e-readers won't use something like this, they'll try and render the text sort of
from source, as it were, and that way they don't have any of these problems.
The interesting thing is that once this damage is done

Turkish: 
yeniden kodlamaya devam etmeyi kötüleştirmez, çünkü bunun için katsayılar şimdi
tümü 0, çünkü onları 0 olarak ayarladık. Bunu bir JPEG olarak yeniden kodlarsak
olmadıkça daha da kötüleşecek
kalite ayarlarını değiştiriyoruz.
Aslında sadece bu kadar kötü kalacak. Yani aslında, bu bir
JPEG kullanmaya devam etmek istiyorsanız, buna bağlı kalmanız gereken kötü JPEGable sürümü. Ama aksi takdirde, kaçının.
... hemen hemen her alanda kesinlikle işe yaramaz. Google kendi kendine araba kullanan bir satranç atarsanız
araba sürmekle kalmıyor, aynı zamanda bir konsepti de bilmiyor, arabanın ne olduğunu bilmiyor ...

English: 
it doesn't make it worse to keep re-encoding it, because the coefficients for this are now
all 0, because we set them to 0.  If we re-encoded this as a JPEG, it's not
going to get progressively worse unless
we change the quality settings.
It's actually just going to stay this bad.  So essentially, this is a
bad JPEGable version of this, which you should stick to if you want to keep using JPEG.  But otherwise, avoid it.
...absolutely useless in almost any other domain.  If you put a chess AI in a Google self-driving car
not only can it not drive the car, it doesn't have the concept, it doesn't know what a car is...
