在這篇文章底下的留言
好吧，是我描述不夠完整，以及太過決斷。但不論是我原本的說法還是B2:立風的說法都是對的，只是要看是什麼條件。
首先要先說 JPG 變綠的由來。
這是源自於 Android 7 以前的 bug，目前已修復：
[google/skia] Use
libjpeg-turbo for YUV->RGB conversion in jpeg encoder
會有這個 bug 是為了加速處理速度。
網路上有前輩已經針對這個問題實現了一個模擬工具：連結
以下是在模擬各種壓縮品質迭代 100 次的結果對照表
 |
 |
 |
| Original | Quality: 100% | Quality: 80% |
|---|---|---|
 |
 |
 |
| Quality: 60% | Quality: 40% | Quality: 35% |
 |
 |
 |
| Quality: 30% | Quality: 5% | Quality: 0% |
另外我也嘗試使用 FFmpeg 迭代 100 次 (原始碼)
左圖原始，右圖迭代 100 次結果
可以看出透過 FFmpeg，使用 Quality Level = 0 的情況下，除了右下多了一小塊紅塊外幾乎沒有差別。
這意味著圖片綠化或黑白或噪點等壓爛的原罪並不是 JPG，而是各種加速運算的品質取捨。
上述提到的 Android bug 只是提高速度的一種做法。
其他圖床、網站、應用程式等，可能也會嘗試加速處理圖片，然而我們並不知道它們具體的做法。
通常我們只能看到結果，情況好的可能看起來跟原圖差不多，情況差的我們可能就直接認為圖片被「壓爛」了。
請衆人一起實驗是一個很有趣的事。但裡面變數太多了。
我們不知道誰用了什麼軟體、什麼電腦、什麼手機，除了自己，我們一概不知道其他人是怎麽做的。 這使得一場實驗想要完全重現幾乎不可能。
就變因多到不可數的大型實驗來說，紅豆麵包!!!跟立風你們都是對的。
但如果僅限幾年前 Android 那個相當知名的 bug 來說的話，我的回應也不是錯的。