xiota

2019-06-11 23:51:22 UTC

view on stackexchange narkive permalink

在WiFi強的情況下從網站上下載圖像會導致設備上的圖像質量更高嗎？

信號質量通常不是影響發送的數據的傳輸，儘管可能會導致傳輸不完整。 但是...

網站經常向移動設備和台式機發送不同的數據。
某些網站 do 使用腳本來根據鏈接質量和速度發送不同的數據。這在視頻流網站上尤其常見。
某些瀏覽器使用代理服務器通過壓縮數據來加快傳輸速度。該可能包含有損的圖像重新壓縮和大小調整。
某些網站可能會顯示比發送的圖像壓縮程度更高的圖像下載。存在縮放功能時通常是這種情況。

當我還是個孩子的時候，我的父母辛苦了一張PCMCIA移動數據卡，服務提供商會壓縮所有圖像，包括圖標，然後再將其通過。壓縮非常激進。

一些網絡提供商（WiFi和蜂窩數據）會攔截流量並降低圖像質量以節省帶寬。

@OrangeDog另一個確保您訪問的網站在可用時使用TLS（HTTPS）的原因。

@SethR這取決於您是希望更高質量還是更快加載。使用TLS的原因是因為它們可能會對您的流量進行*其他*較少無害的操作。甚至是出於善意無法正常工作的事情。

此外，某些網站（例如Google圖片搜索）在等待接收較大圖片時可能會使用低質量的佔位符（並且由於某種原因或其他原因，此過程可能無法完成）。

user85259

2019-06-11 14:00:23 UTC

view on stackexchange narkive permalink

其他答案指出，數字圖像的質量在傳輸過程中不會降低。值得指出的是，如今，許多移動數據計劃都對電影進行了轉碼，並且如果它們是通過服務提供商可訪問的頻道進行傳輸的，則其質量要低於原始電影。這可能意味著非加密傳輸，也可能意味著加密通道的傳輸，服務提供商為此與內容提供商進行了緩存安排（通常適用於Netflix等平台）。根據計劃及其提供者的不同，網站上的未加密圖像可能同樣受到困擾。

使用這種數據計劃，通過WiFi連接可以提高典型的圖像質量。結果不會因WiFi連接的質量而異，而取決於電話是否完全使用它而不是依賴可能的重新編碼移動數據計劃。獲取渠道的質量，以及是否有人弄亂了您的數據。這些天，他們可能會。

同樣，大多數情況下，大多數流服務會根據連接速度和質量來調整質量（分辨率，壓縮級別）。（無論任何ISP交互。）

@mattdm經常（例如tmobile進行暴飲暴食時這樣做），它們只會限制您與youtube / netflix / etc的連接，並讓該應用決定以較低的質量進行流式傳輸。

當您打開免費視頻流時，@Jon Optus也會執行此操作，但是它確實不能很好地工作，並且嚴重干擾了Netflix和Stan的自動質量系統。它將以低質量開始流式傳輸，並逐漸提高質量，直到最終達到720p或1080p，然後在幾秒鐘之內Optus限制連接和流式緩衝並下降到最低質量。壞話系統。

“服務提供者與內容提供者之間有緩存安排的加密通道” –沒有加密密鑰怎麼辦？

@xiota Simple:服務提供者擁有加密密鑰。在這種情況下，它們充當CDN。 https://security.stackexchange.com/questions/107835/does-a-content-delivery-network-cdn-interrupt-end-to-end-security

@mattdm該頁上的圖看起來像“中間人”。我們如何確保諸如銀行信息之類的信息得到保護？

@xiota歡迎使用現代互聯網-您不能。

AiliquddqaCMT –

“結果不會因WiFi連接的質量而異”：對於視頻，質量必然隨連接質量而異。例如。如果連接速度緩慢（無論出於何種原因）（包括本地WiFi），Youtube或TED都會降低分辨率。

Opifex

2019-06-11 23:59:35 UTC

view on stackexchange narkive permalink

儘管這裡的其他答案已經非常好，但請允許我給出不同的看法：

通常，不會。

當您在瀏覽器中下載圖像，很有可能將通過傳輸控制協議（TCP）下載該文件（圖像）。 TCP會將您的圖像分成幾小包，然後分別通過Internet發送這些圖像。每個數據包都附帶一個校驗和。此校驗和是對數據包進行某些數學運算的結果。接收到校驗和後，接收器會再次計算校驗和。兩個校驗和應該相同。如果沒有，則意味著至少一位已更改或信息被遺忘。在這種情況下，接收方將請求再次發送該特定數據包。收到所有數據包後，下載的文件將與從其下載的服務器上的原始文件相同。

但是，您正在流傳輸電影或通過網絡流查看圖像，則很可能它不是TCP，而是 UDP （用戶數據報協議）。 UDP不會執行與TCP相同的檢查。它被稱為“火與忘”。如果數據包丟失或損壞，將無法修復。

同樣，誤碼（不是有意的有損轉碼）會明顯破壞大多數格式的圖像。壓縮格式使用最廣泛，壓縮的最外層（有損量化或無損處理之外）是某種熵編碼（例如JPEG的Huffman或PNG的[zip aka DEFLATE]（https：// en.wikipedia.org/wiki/DEFLATE）），其中更改比特流中的1位可能會導致其餘解碼方式發生重大變化。對於視頻格式，這可能只是一個損壞的8x8宏塊或其他東西。

現在，每個人都已從Flash轉到HTML5，流媒體網站更可能使用TCP。請參閱[YouTube是否通過TCP流視頻？]（https://stackoverflow.com/q/19620219）

UDP也使用校驗和。您將丟失整個數據包，而不是單個數據包。

@Dubu:為應用程序層提供了校驗和。 UDP本身根本不提供任何校正甚至檢測功能。 TCP使用數據包，而UDP不使用。

@Opifex否。TCP有流，UDP有數據報，但都具有數據包（或者說，它們位於較低的級別）。但是UDP確實可以保證數據完整性（與校驗和一樣多）-您永遠不會得到損壞的數據報或不完整/碎片化的數據報。 UDP不會重新傳輸損壞的數據報-就您的應用程序而言，它們從未實現過。

vlumi

2019-06-11 12:54:14 UTC

view on stackexchange narkive permalink

否，計算機的通訊水平是完美的-傳輸過程中的微小變化也可能會完全破壞數據，並且可以防止使用校驗和（並在出現錯誤時重試）。

但是，則可能會“逐步加載”圖像，例如網站可能會首先將較低分辨率的圖像顯示為快速的佔位符（以降低感知的加載速度），一旦下載了較高分辨率的圖像，它們就會被替換。如果您的連接確實很慢和/或不可靠，則可能會卡在分辨率較低的佔位符圖像上。

編輯：為澄清起見，由於以下原因，質量可能會降低：數量眾多的因素，但這是因為網頁（或代理）選擇了這種方式-不是因為通過wifi傳輸會降低質量。

確實，通過HTTP進行的數據傳輸是無損的，但是肯定會有一些站點可以破解/優化圖像和其他資源加載。如果圖像加載時間太長，將來它們將不會加載更高分辨率的版本。隨著瀏覽器將測量的帶寬（基於最近的吞吐量）報告給頁面，以便頁面可以決定要做什麼，這實際上已經變得標準化。某些WiFi連接也有可能被標記為計量連接，站點可能會針對這些連接進行優化以實現低帶寬。

網站當然可以像這樣優化其圖像，但是通常是由客戶端來決定從服務器請求正確的圖像。如果您從服務器上簡單地下載圖像，則它肯定不會知道您使用的wifi的強度，因此不會基於該圖像更改圖像的質量（如原始問題中所述）。

JimmyB

2019-06-12 16:27:37 UTC

view on stackexchange narkive permalink

其他答案是正確的（WiFi上的圖像質量沒有損失），但我只想指出：

您可能已經看到流式傳輸（！）視頻的質量在“弱”連接上似乎會下降。但是，這不是由於某些信息在傳輸期間丟失而引起的（*）：當今大多數視頻流服務器都維護同一視頻的多個副本，每個副本以不同的壓縮率進行壓縮。較高的壓縮比可生成較小的文件，但是由於壓縮有損，這些較小文件的質量較差。

現在，在流式傳輸視頻時發生的情況是流式傳輸服務器監視連接的“質量”，即連接的數據速率。當服務器檢測到您的連接速度變慢時，例如因為您移動了設備並且WiFi信號變得微不足道，所以它將或多或少無縫地切換到同一視頻的較低比特率流，從而犧牲了圖像質量以能夠繼續觀看視頻，而不是（高質量）視頻暫停在流的下幾秒鐘被下載時反復進行。

這也可以通過另一種方式進行：當服務器檢測到您的連接帶寬增加時，它可能會切換到流的更高質量版本，以嘗試始終可以在您當前的帶寬下為您提供最佳的圖像質量。

*）實際上，它是由數據包丟失間接引起的：當信號變弱時，隨機數據錯誤變得更加頻繁。但是，這些數據錯誤會被硬件檢測到，“破損”的數據包通常會再次發送多次，直到正確接收到數據包為止。但是，這意味著每個數據包（平均）需要在WiFi鏈路上多次傳輸，例如，三倍，這意味著達到的數據速率（即每秒成功傳輸的數據包每秒）降至例如1/3。

Wayne Werner

2019-06-14 00:29:03 UTC

view on stackexchange narkive permalink

為這些其他答案添加更多風味，這是我剛拍攝的幾張照片：

Unikitty 1-尺寸調整為xx400像素，質量不變

Unikitty 2-調整大小？x400px質量50％

Unikitty 3-調整後的？x200px質量50％

Unikitty 4-調整後的？x200px質量5％

在我的計算機上，我已使用 exiftool --all = 剝離了元數據，併計算了圖像的校驗和：

$ sha256sum unikitty * .jpg2ead7f2b1c5453f2a80da46f131c95be3423fc92ef8bce43b95fac3ee483d1b3 unikitty.jpg42358f2f2447568fedc31a03575e8850406f89ff0e5d5a6e2d15c9e492205279 unikitty1.jpg5c05365cb4aea2f100da471cdee85e5a3942509ab09cf3aa646fddb6962bd95a unikitty2.jpge48c7158bbb9476cacdc80308832d76384e3016fb4dd2afd4333970781b367d5 unikitty3.jpg986f8c64745fb61196df662c5e9a7c799ed370749f3dc367f269162bfa413800 unikitty4.jpg 代碼>

然而，當我下載 Unikitty＃4 一種>，則哈希值已更改：

  3b5991bfaeff83bd6c1fef585f2fdee80cf649f84978d249b08c2b17a03702c2

這意味著文件已完全更改。確切如何，我不確定。

如果您想肯定所獲得的圖像是其他人也在看的圖像，那麼您必須對它進行校驗，以確保沒有一個校驗和可以驗證這些碎片在運輸過程中變髒了。在大多數情況下，Internet會這樣做（TCP / IP告訴您如何確保在您發送信息時，所有信息都到達了應該到達的位置，如果沒有到達，則必須大聲抱怨。因此，大多數Internet使用TCP / IP。但是，正如其他人所提到的，可以通過多種方式改變圖像的質量。

如果您下載Unikitty 4並獲得與我相同的SHA-256總和，則可以幾乎完全確定知道您正在查看的圖片和我正在查看的圖片

儘管如此，您仍然需要擔心我們的顯示器是否經過顏色校準，或者周圍的光線是否在影響任何事物，或者...

我很確定imgur會刪除元數據。它們也可能在* upload *處重新壓縮。儘管它們可以根據帶寬改變數據傳輸，但這並不能證明這一點。校驗和不必匹配即可具有相同的圖像。例如，PNG在多個壓縮級別下是無損的。

`wget https：// i.stack.imgur.com / t69qT.jpg`; `sha256sum t69qT.jpg`; 3b5991bfaeff83bd6c1fef585f2fdee80cf649f84978d249b08c2b17a03702c2 t69qT.jpg`

好點子！校驗和只能用作保證圖像相同而不是不同的保證。哎呀，我很難說1和2是否完全不同，並且校驗和完全不同。

raviputcha

2019-06-11 13:23:25 UTC

view on stackexchange narkive permalink

您可能正在查看正在下載的圖像（照片存儲在Google Apps之類的雲應用程序中）或已完全下載，但是用於查看圖像的軟件尚未完成渲染-因此您正在以漸進式渲染模式查看圖像。

要回答您的問題，網絡的質量（我想您是指速度）不會影響圖像的質量。

Anonymous

2019-06-11 12:44:37 UTC

view on stackexchange narkive permalink

不。與模擬文件相反，數字文件始終是完美的副本，因此圖像每次都無法下載或完美下載。同樣的情況也適用於在介質之間進行轉移（從SD到磁盤，pendrive，CD等）或創建副本。

在某些情況下，可能會損壞副本，儘管這種情況不太可能發生，但它們不是質量較低”，但完全錯誤（即：只有一半的圖像等）。

損壞的文件並非“不太可能”，但是它們並不少見。如果未驗證文件，它們可能會被忽略。