Dùng công cụ lập trình AI để khắc phục lỗi hiển thị sọc trên máy đọc sách Xteink X3

Tôi là một người đọc sách suốt đời, một thói quen vốn rất mong manh trong kỷ nguyên của những sự xao nhãng tầm thường không hồi kết này. Mặc dù sách giấy và máy đọc sách e-ink giải quyết được vấn đề cạnh tranh sự chú ý, nhưng chúng không thể so sánh với điện thoại về độ tiện lợi. Thiết bị nhỏ bé trong túi quần đó đã khiến việc đọc sách trở nên dễ dàng hơn, nhưng cũng dễ bị gián đoạn bất cứ khi nào có thông báo hiện lên.

Vài ngày trước, lần đầu tiên tôi biết đến một thế hệ máy đọc sách e-ink nhỏ gọn mới. Vì giá thành rẻ, tôi dễ dàng chiều theo sự tò mò của mình: tôi đã mua một chiếc Xteink X3. Nó không chỉ nhỏ đến kinh ngạc mà tôi còn có thể cài đặt ngay lập tức firmware mã nguồn mở CrossPoint đầy thú vị. Tôi nhanh chóng chép được vài cuốn sách vào máy. Tôi cũng đánh giá cao việc có thể cài đặt thêm phông chữ tùy chỉnh, mặc dù hơi ngạc nhiên về khả năng hiển thị không mấy ấn tượng của chúng (một điềm báo…).

CrossPoint có khả năng tùy biến rất cao ngay khi vừa cài đặt, vì vậy tôi đã chuyển đổi một bức ảnh sang định dạng bitmap đen trắng (dithered) để làm màn hình "ngủ" cho thiết bị, và rất hài lòng với vẻ ngoài của nó. Khi đọc được thông tin rằng thiết bị hỗ trợ đủ 4 sắc độ xám, tôi thấy tò mò: liệu hình ảnh thang độ xám trông có đẹp hơn không?

Đi sâu vào hang thỏ: những lỗi hình ảnh đầu tiên

Điều này đã bộc lộ thứ trông giống như một lỗi: màn hình ngủ hiển thị các hình ảnh thang độ xám với những vùng tối rất mờ đục. Hoặc là đôi mắt trung niên của tôi cuối cùng cũng đã xuống cấp, hoặc là màu xám đậm đang bị hiển thị thành màu đen? Tôi đã tạo nhanh một hình ảnh kiểm tra và xác nhận rằng màu xám đậm thực sự là màu đen, trong khi màu xám nhạt lại cực kỳ nhạt (gần như trắng). Hơi khó chịu một chút, nhưng không có gì đáng ngạc nhiên trên một thiết bị giá rẻ và cũng dễ dàng khắc phục: hãy tạo một hình ảnh ba tông màu!

Với việc hình ảnh được tạo lại ít chứa các vùng đen lớn hơn, tôi bắt đầu thấy một lỗi mới: trong ứng dụng trình xem CrossPoint, nội dung màn hình trước đó vẫn còn hiện lên dưới dạng bóng mờ (chỉ xuất hiện ở những phần nhạt hơn của màn hình, đó là lý do tại sao lần đầu tôi không nhận ra). Tuy nhiên, trên cùng một hình ảnh đó, màn hình ngủ lại không gặp vấn đề này. Điều này cho thấy có hai trình kết xuất hình ảnh đưa ra các quyết định khác nhau, và mã nguồn của ứng dụng trình xem đang bị lỗi.

Tuy nhiên, trong cả hai trường hợp, bức ảnh đều có các sọc dọc đặc trưng chạy ngang qua mà không hề có trong tệp bitmap gốc.

Một bức ảnh chụp bằng điện thoại về hình ảnh ba tông màu của tôi. Các sọc dọc mảnh rất dễ thấy ở phần nền.

Vì tôi gần như không biết gì về e-ink, phát triển ESP32 hay CrossPoint, tôi bắt đầu tìm hiểu theo cách thông thường của cuối năm 2026, sử dụng GPT-6 Astra trong Codex. Tôi sẽ chụp màn hình chiếc X3 bằng điện thoại và đưa các hình ảnh đó vào phiên làm việc Codex của mình.

Màn hình e-ink sử dụng các xung điện áp để di chuyển các hạt sắc tố đen và trắng, vốn sẽ giữ nguyên vị trí sau khi ngắt nguồn. Một quá trình cập nhật không hoàn chỉnh hoặc điện áp không đủ có thể để lại dấu vết bóng mờ của hình ảnh trước đó.

Để hiển thị hình ảnh thang độ xám, CrossPoint trước tiên vẽ một lớp nền đen trắng, trong đó ngay cả các điểm ảnh xám cũng bắt đầu bằng màu đen. Sau đó, nó chạy một dạng sóng xung điện áp ngắn để di chuyển các điểm ảnh đã chọn một phần về phía màu trắng. Giai đoạn thứ hai này, gọi là "nudge" (cú hích), tạo ra các sắc độ xám đậm và nhạt bằng cách điều khiển các điểm ảnh đó trong những khoảng thời gian khác nhau.

Astra phát hiện ra rằng trình xem đã thực hiện cập nhật đen trắng nhanh và dừng lại ngay, mà không bao giờ thực hiện "cú hích" xám. Nó đã nhanh chóng sửa lỗi này.

Các sọc dọc tỏ ra cứng đầu hơn nhiều. Ban đầu Astra loay hoay, đổ lỗi cho thuật toán làm mịn Floyd–Steinberg mà nó đã sử dụng để chuẩn bị bức ảnh màn hình ngủ của tôi. Một thuật toán khác cũng không tạo ra sự khác biệt. Sau đó, nó lần theo manh mối xuống các tầng sâu hơn và đánh dấu dạng sóng "nudge" là thứ đáng để điều tra.

Nhưng chúng tôi đang chật vật trong việc thống nhất xem chúng tôi đang nhìn thấy hay đo lường vật thể nhiễu nào, điều này khiến tôi lo ngại; tôi không muốn lãng phí các token hiện đại nhất để đuổi theo những bóng ma. Khi tôi thúc ép, Astra đào sâu hơn và báo cáo về một mô hình sọc rộng hai điểm ảnh. Điều đó hoàn toàn vô lý đối với tôi, vì vậy tôi yêu cầu nó chú thích vào bức ảnh và phát hiện ra rằng nó đã chọn nhầm kết cấu làm mịn (dither) thay vì các dải sọc mà tôi có thể nhìn thấy trên ảnh.

Việc sử dụng biến đổi Fourier nhanh (FFT) ở đây khá thông minh: đó là một công cụ gần như lý tưởng để chọn ra và định lượng các mô hình lặp lại vốn khó đo lường bằng mắt thường. Astra đã áp dụng FFT hai chiều cho các mảng nhỏ của bức ảnh gốc và ảnh chụp, và tìm thấy một sự lặp lại mạnh mẽ ở khoảng hai điểm ảnh màn hình trong cả hai.

Thật không may, thuật toán làm mịn khuếch tán lỗi (error-diffusion dithering) tự tạo ra cấu trúc riêng của nó, theo bản chất thường là nhiễu tần số cao tạo ra tín hiệu mạnh trong FFT. Astra đã chọn nhầm mô hình chấm mịn của Floyd–Steinberg, chính là thuật toán mà nó đã chọn để chuẩn bị hình ảnh và đổ lỗi từ đầu cuộc điều tra. Các dải rộng hơn mà tôi phàn nàn chỉ xuất hiện trên máy đọc sách. Khi tôi thách thức ước tính của nó, nó đã thực hiện chú thích này, xác nhận rằng chúng tôi đang nhìn vào các mô hình khác nhau.

Chú thích của Astra về kết cấu làm mịn mịn phía sau ước tính hai điểm ảnh của nó.

Làm cho các sọc có thể đo lường được

Hơi mệt mỏi với những giả thuyết không đi đến đâu của Astra, tôi chuyển sang Fable 5.1 trong Claude Code để có một góc nhìn khác.

Tôi có linh cảm rằng chiều rộng của các sọc có ý nghĩa gì đó, nhưng ngay cả việc xác định các sọc cũng đã làm khó Astra. Và điều này không hề dễ dàng, vì rất nhiều nguồn gây ra các mô hình và nhiễu:

Sau khi được cảnh báo tránh xa ngõ cụt xử lý hình ảnh ngây thơ của Astra, Fable đã viết mã để tính trung bình độ sáng dọc theo mỗi cột. Đối với chế độ xem bên dưới, nó sử dụng một cửa sổ trượt cao 200 hàng: mỗi điểm trở thành giá trị trung bình của một dải dọc ngắn xung quanh nó. Điều này làm mờ đi kết cấu làm mịn, trong khi sự khác biệt về độ sáng kéo dài dọc theo một cột sẽ vẫn tồn tại. Các hình khối rộng trong bức ảnh vẫn còn đó, nhưng các sọc trở nên dễ nhìn thấy hơn nhiều:

Một phần cắt sau khi áp dụng tính trung bình dọc trượt. Các hình khối rộng thuộc về bức ảnh; các dải dọc mảnh là lỗi.

Fable hiện đã sử dụng FFT trên cấu hình độ sáng một chiều để đo khoảng cách và cường độ của mô hình dọc. Ước tính đầu tiên của nó cho rằng các sọc cách nhau khoảng bảy điểm ảnh màn hình, nhưng điều này dựa trên một phỏng đoán về tỷ lệ bức ảnh của tôi.

Nó quay lại tập trung vào việc làm mịn, lần này là bên trong firmware, đề xuất rằng các lỗi làm tròn lặp đi lặp lại có thể xếp hàng tạo ra các dải dọc. Khi tôi đề cập rằng hình ảnh nguồn của tôi đã được làm mịn từ trước, nó trở nên hào hứng hơn, nhưng đây lại là một manh mối sai lầm kéo dài 20 phút. Một cuộc điều tra khác liên quan đến việc Fable tỏ ra phấn khích về độ sâu bit của hình ảnh, nhưng điều này cũng không đi đến đâu. Ít nhất thì nó cũng có cách tiếp cận mới lạ hơn Astra trong các cuộc điều tra?

Điều gì khác biệt về màu xám?

Tôi cũng đã điều tra các hình ảnh đơn giản hơn nhiều trên thiết bị. Việc loại bỏ màu xám hoặc mô hình làm cho các sọc biến mất:

Sự kết hợp cụ thể giữa các điểm ảnh xám với các điểm ảnh lân cận có sắc độ khác nhau chính là nguyên nhân gây ra rắc rối. Fable đã khớp các khối nhỏ của hình ảnh nguồn với bức ảnh chụp từ điện thoại, điều này cuối cùng cho phép nó thấy rằng các điểm ảnh màu xám nhạt mang theo sọc, một chi tiết quan trọng mà ngay cả tôi cũng không rõ do tông màu rất nhạt của các điểm ảnh xám nhạt.

Bằng chứng này hiện chỉ ra cách màn hình tạo ra màu xám, thông qua "cú hích" thang độ xám. Mã nguồn cho việc này nằm trong freeink-sdk, thư viện phần cứng mà CrossPoint sử dụng.

Fable ban đầu miễn cưỡng đi xa hơn: "Tôi không thể thiết kế hoặc xác thực thay đổi LUT từ đây." LUT là bảng tra cứu chứa dạng sóng "cú hích". Khi tôi chỉ ra rằng chiếc X3 đang ở trên bàn của tôi và tôi có thể chụp ảnh bất cứ thứ gì mà bản dựng mới hiển thị, nó đã quay lại với các thí nghiệm mà chúng tôi có thể thực hiện.

Lựa chọn kỳ lạ của X3 về bộ sạc tiếp xúc từ tính đã giúp ích cho chúng tôi ở đây. Fable có thể flash và khởi động lại thiết bị qua USB trong khi nó vẫn đang được cắm sạc. Sau đó, tôi có thể cầm thiết bị lên để chụp ảnh màn hình và đặt nó xuống mà không cần phải loay hoay với đầu nối USB-C.

Một mô hình kiểm tra, và lỗi thứ hai

"Cú hích" hiện tại kéo dài bảy chu kỳ quét: mỗi lần, bộ điều khiển thực hiện qua các hàng của bảng điều khiển, áp dụng bước tiếp theo của chuỗi điện áp cho từng điểm ảnh. Chúng tôi vẫn nghĩ khoảng cách sọc là khoảng bảy điểm ảnh. Liệu thời gian có đang hiển thị dưới dạng một mô hình không gian? Thay đổi thời lượng của dạng sóng sẽ cho chúng tôi thứ gì đó để so sánh.

Đầu tiên chúng tôi cần một hình ảnh tốt hơn để đo lường, vì vậy tôi gợi ý Fable nên tạo một hình ảnh kiểm tra. Nó đã tạo ra một mô hình với các mảng phẳng ở cả bốn sắc độ, các hỗn hợp xám với đen hoặc trắng, một bàn cờ và các đường kẻ chạy theo cả hai hướng.

Mô hình kiểm tra. Các mảng phẳng thiết lập bốn sắc độ; các khu vực có mô hình kiểm tra cách màu xám hoạt động bên cạnh các sắc độ khác. Bàn cờ nằm ở bên phải của hàng thứ ba.

Hình ảnh kiểm tra giúp tiến độ dễ dàng hơn đáng kể. Fable biết hình ảnh trông như thế nào, vì vậy những thay đổi trong ảnh chụp của tôi và diện mạo của màn hình trở nên có thể nhìn thấy và giải trình được. Ví dụ, ước tính tỷ lệ ban đầu của Fable đã nhầm lẫn một đặc điểm trong phổ của bức ảnh với lưới điểm ảnh của màn hình. Với mô hình kiểm tra làm thước đo, chu kỳ sọc hóa ra là tám điểm ảnh, thay vì bảy.

Tôi đã cung cấp các tệp DNG thô từ điện thoại của mình cũng như các bức ảnh đã qua xử lý. So sánh cả hai cho thấy quá trình xử lý của điện thoại đã làm tăng biên độ sọc lên khoảng 70 phần trăm và làm thay đổi các mức xám hiển thị. Sau đó, chúng tôi đã sử dụng các tệp thô. Fable đã tìm ra cách định vị các mảng kiểm tra bất chấp những thay đổi về khung hình, phối cảnh và biến dạng ống kính, để nó có thể đo lường từng bản dựng và bức ảnh theo cùng một cách.

Chúng tôi đã thử kéo dài "cú hích" từ bảy khung hình lên mười, sau đó là một phiên bản xen kẽ các xung truyền động với các khoảng nghỉ. Không có cách nào ảnh hưởng đến các sọc. Điều này loại bỏ mối liên hệ được đề xuất giữa số lượng khung hình và chu kỳ sọc.

Ba, rồi bốn, sắc độ xám

Mô hình kiểm tra cũng mang lại một vấn đề mà chúng tôi đã giải quyết trước đó.

Mô hình kiểm tra dưới dạng sóng gốc. Hai mảng đầu tiên ở hàng trên cùng đáng lẽ phải là màu đen và xám đậm. Cả hai đều là màu đen. Mảng xám đậm trên nền đen ở bên trái hàng thứ ba cũng đã biến mất.