ASPECT RATIO
CALCULATOR
Hai công cụ cho Framing và Data Planning
Mình bắt đầu làm 2 công cụ này từ 2024, đơn giản vì trong quá trình làm việc mình cứ gặp đi gặp lại hai câu hỏi: “Khung hình này cuối cùng nên là bao nhiêu?” và “Đống footage này sẽ tốn bao nhiêu dung lượng?”
Ban đầu chúng chỉ là 2 calculator khá đơn giản. Sau đó mình cứ thêm dần những thứ mà chính mình muốn có khi prep, ở trên set và trong post. Đến hiện tại, trang này đã phát triển thành 2 công cụ đầy đủ hơn: Aspect Ratio & Monitor Overlay Toolkit dành cho framing và deliverables, cùng DOP / DIT Video Data Rate Reference dành cho camera format, recording data và media planning. Ý tưởng cốt lõi vẫn rất đơn giản: Xử lý phần kỹ thuật càng nhanh càng tốt, để dành thời gian tập trung vào hình ảnh.
ASPECT RATIO & OVERLAY TOOLKIT
Build framing guides, platform safe zones and monitor overlays inside a custom sensor / canvas reference.
1. Aspect Ratio & Monitor Overlay Toolkit
Khi một cái billboard 3.14:1 làm mọi thứ phức tạp hơn mình nghĩ
Gần đây mình có một job khá vui: deliverable chính là 16:9, nhưng kèm theo là một billboard siêu rộng 3.14:1, rồi tất nhiên không thể thiếu 9:16 cho social. Ba khung hình gần như sống ở ba thế giới khác nhau, nhưng budget và thời gian thì lại không cho phép mình mang 3 camera đi quay ba lần. Cuối cùng mình chọn Sony FX5, quay Open Gate 3:2 với lens anamorphic 1.5x. Khi desqueeze, 3:2 × 1.5 cho mình một vùng hình khoảng 2.25:1. Ý tưởng khá đơn giản: lấy một source đủ rộng và đủ cao để sau đó có thể cắt ra cả billboard 3.14:1, master 16:9 và vertical 9:16 mà vẫn có không gian để reframe. Nghe khá đẹp trên giấy. Cho tới khi mình cắm monitor vào. Đây cũng là lần đầu mình dùng FX5 để quay anamorphic. Rental đưa kèm một ngàm Tilta Nucleus Auto Focus E-PL, và với setup mình sử dụng lúc đó, autofocus chỉ hoạt động khi mình không bật desqueeze trên camera.
Okay, that makes sense. Không sao cả. Mình nghĩ đơn giản là cứ gửi hình squeezed ra ngoài, rồi bật 1.5x desqueeze trên monitor Ninja V+, sau đó dùng Frame Guide của monitor để canh 3.14:1, 16:9 và 9:16 cùng lúc. Và đây là lúc mọi chuyện bắt đầu hơi… kỳ.
Vấn đề không nằm ở anamorphic lens, mà nằm ở cái khung 16:9 ở giữa
Open Gate của mình là 3:2, nhưng monitor lại đang nhận một video signal chuẩn 16:9. Nói dễ hiểu hơn, camera không gửi cho monitor một “khung 3:2 độc lập”. Nó phải đặt hình 3:2 squeezed đó vào bên trong một khung 16:9, vì HDMI/SDI vẫn đang làm việc với một raster video tiêu chuẩn. Vì vậy trước khi tới monitor, hình có thể trông đại loại như thế này:
┌───────────────────────────────────┐ │ BLACK / UNUSED AREA │ │ ┌───────────────────────────┐ │ │ │ │ │ │ │ 3:2 SQUEEZED IMAGE │ │ │ │ │ │ │ └───────────────────────────┘ │ │ BLACK / UNUSED AREA │ └───────────────────────────────────┘
Nếu monitor hiểu đâu là vùng hình thật và chỉ desqueeze 3:2 Active Image, mọi thứ sẽ ổn. Nhưng trong trường hợp mình gặp, monitor lại nhìn thấy đơn giản là: “Ồ, 1 signal 16:9. Bạn muốn 1.5x à? Okay.” Và nó kéo giãn toàn bộ khung 16:9, bao gồm luôn cả phần black bar. Thế là:
Đây là chỗ lúc đầu khá dễ nhầm, bởi vì lens vẫn là 1.5x, phép tính 3:2 × 1.5 = 2.25:1 vẫn đúng. Vấn đề là 2.25:1 đó đang nằm ở đâu trên màn hình sau tất cả các bước scaling. Ví dụ, nếu camera tự desqueeze 3:2 × 1.5 trước rồi fit hình 2.25:1 vào signal 16:9, Active Image sẽ gần như dùng toàn bộ chiều ngang monitor và chiếm khoảng 79% chiều cao. Nhưng nếu monitor lấy cả signal 16:9 chứa hình 3:2 + black bars rồi mới desqueeze toàn bộ 1.5x, vùng hình thật cuối cùng có thể chỉ còn khoảng 84% chiều ngang và 67% chiều cao màn hình.
Vẫn là footage đó. Vẫn là lens 1.5x. Nhưng vị trí của hình thật trên monitor đã khác hẳn. Và nếu mình đặt một Frame Guide 3.14:1 dựa trên toàn bộ màn hình lúc này, guide nhìn có vẻ rất chuyên nghiệp… nhưng thực tế lại chẳng nói đúng mình đang quay cái gì.
Có hai cách xử lý
Cách sạch nhất, nếu workflow của bạn cho phép, là desqueeze ngay trên camera. Camera xử lý hình anamorphic trước, sau đó gửi một hình đã đúng tỷ lệ sang monitor. Lúc này monitor không cần desqueeze nữa, nó chỉ việc hiển thị signal mà camera gửi tới. Frame Guide và overlay cũng dễ quản lý hơn rất nhiều vì hình bạn nhìn thấy đã là hình sau desqueeze.
Trong trường hợp của mình thì cách này lại đụng vào setup autofocus, nên mình cần phương án thứ hai. Nếu muốn desqueeze trên monitor, cách lý tưởng là monitor phải xử lý đúng Active Image trước. Tức là crop, zoom hoặc scale để bỏ vùng black bar / padding mà camera đã thêm vào signal, rồi mới áp dụng 1.5x, 1.8x hay 2x desqueeze. Theo thứ tự: 16:9 Signal → tìm đúng Active Image → crop/fit → desqueeze → Frame Guide
Thay vì: 16:9 Signal + black bars → desqueeze tất cả → hy vọng mọi thứ vẫn đúng
Vấn đề là mỗi monitor xử lý phần này hơi khác nhau, và không phải lúc nào mình cũng có đúng option crop/scale mình muốn. Và đây là lý do phần Anamorphic / Desqueeze trong tool này bắt đầu trở nên thú vị.
Không sửa được monitor? Vậy ít nhất hãy tính đúng thứ monitor đang làm
Monitor — Full Signal (includes bars): Mode này mô phỏng đúng chuỗi đang xảy ra ngoài đời:
Open Gate source → pack vào signal 16:9 → monitor desqueeze toàn bộ signal → fit lại lên màn hình → tìm vùng Active Image cuối cùng → đặt Frame Guide vào đó
Nói cách khác, tool không giả vờ rằng monitor đang xử lý hình “đúng chuẩn”. Nó tính luôn cả cách xử lý hơi awkward mà monitor đang thực sự làm. Với setup kiểu:
- Reference Frame: 3:2 Open Gate
- Squeeze: 1.5x
- Monitor Signal: 16:9
- Workflow: Monitor — Full Signal
- Guide Space: Final Active Image
Tool sẽ tính vị trí thật của vùng hình sau khi signal 16:9 cùng black bars đã bị desqueeze. Sau đó mình có thể đặt: 3.14:1, 16:9, 9:16 hoặc bất kỳ Frame Guide nào cần dùng vào đúng vùng hình đó, rồi export thành transparent PNG overlay. Và đó mới là phần mình thực sự cần trên set: không phải một khung guide “đúng trên lý thuyết”, mà là một guide khớp với thứ mình đang nhìn thấy trên monitor.
2. Bitrate ↔ File Size Calculator & DOP / DIT Video Data Rate Reference
Framing trả lời câu hỏi: “Trong hình sẽ có những gì?” Data planning trả lời: “Chúng ta có đủ chỗ để quay hết những thứ đó không?”
Camera có thể tạo ra lượng data rất lớn trong thời gian rất ngắn. ARRIRAW, X-OCN, BRAW, N-RAW, Cinema RAW Light hay ProRes chất lượng cao có thể biến vài giờ shooting thành hàng trăm GB hoặc vài TB. Phần này kết hợp hai tool liên quan với nhau. Một là Bitrate ↔ File Size Calculator đơn giản. Hai là DOP / DIT Video Data Rate Reference chi tiết hơn nhiều.
BITRATE CALCULATOR
Lock one value, then change either of the other two. The calculator will solve the remaining value.
DOP / DIT Video Data Rate Reference
Choose the camera, sensor/scan mode, codec, recording raster and frame rate. The tool then calculates the practical storage load instead of forcing you to scan a giant table.
Comparison tray
Add several camera configurations to compare real storage impact.
Một lưu ý về Bitrates
Không phải recording format nào cũng hoạt động giống nhau. Có format có Data Rate khá ổn định hoặc cố định. Có format dùng VBR hoặc Constant Quality compression, nghĩa là actual file size thay đổi tùy nội dung hình ảnh. Vì vậy reference phân biệt giữa số liệu hãng công bố trực tiếp và số liệu được tính minh bạch từ recording time, MB/s hoặc per-frame information chính thức. Với H.264 và H.265 cũng không tồn tại một con số kiểu “H.265 = X Mbps” áp dụng cho mọi camera. Bitrate thực tế phụ thuộc vào recording preset của từng hãng. Hãy xem những con số trong tool như một planning reference, và với những production có recording limit quan trọng, vẫn nên kiểm tra lại documentation mới nhất của camera.
A Storage Math
Với Constant Bitrate, có thể ước tính nhanh theo decimal storage:
File Size (GB) ≈ Bitrate (Mbps) × Duration (seconds) ÷ 8000
Ví dụ:
Camera quay 240 Mbps trong 1 giờ: 240 × 3600 ÷ 8000 ≈ 108 GB
Đó là phần data lý thuyết. Trong thực tế, nên luôn chừa thêm dung lượng cho filesystem overhead, take phát sinh, audio, proxy và một sự thật khá quen thuộc trên set: Camera gần như lúc nào cũng chạy lâu hơn dự định. Với DIT, “vừa đủ storage” thường đồng nghĩa với không đủ storage.
GB và GiB - nhìn giống nhau, nhưng không phải một
Đây là một chỗ khá dễ gây nhầm khi tính data trên set: GB và GiB thường bị dùng lẫn với nhau, dù thực ra chúng không giống nhau hoàn toàn.
GB là cách tính theo hệ thập phân: 1 GB = 1,000 MB = 1,000,000,000 bytes
Còn GiB là cách tính theo hệ nhị phân: 1 GiB = 1,024 MiB = 1,073,741,824 bytes
Khác biệt nghe có vẻ nhỏ, nhưng khi data bắt đầu lên vài trăm GB hoặc vài chục TB thì con số lệch cũng bắt đầu đáng kể.
Ví dụ, giả sử mình quay ở 100 Mbps trong 1 giờ. Nếu tính theo GB: 100 × 3,600 ÷ 8 ÷ 1,000 = 45 GB. Nhưng nếu tính theo GiB: 100 × 3,600 ÷ 8 ÷ 1,024 ≈ 43.95 GiB
Cùng một lượng data, nhưng một bên hiển thị khoảng 45 GB, bên kia khoảng 43.95 GiB. Không có bên nào “sai”. Chỉ là đang dùng hai cách đếm khác nhau.
Tại sao lại có chuyện này?
Đơn giản vì ngành storage và máy tính lớn lên từ hai thế giới khác nhau. Các hãng ổ cứng, SSD và thẻ nhớ thường dùng decimal GB, vì cách này dễ tiêu chuẩn hóa và cũng là cách dung lượng sản phẩm thường được công bố. Trong khi đó, hệ điều hành và một số phần mềm lại quen tính theo các lũy thừa của 2, tức kiểu 1024, nên lâu nay rất nhiều người gọi luôn con số đó là “GB”, dù về mặt kỹ thuật nó gần với GiB hơn. Đó là lý do bạn có thể mua một ổ “1 TB”, nhưng khi cắm vào máy lại thấy dung lượng hiển thị thấp hơn con số trên.
Nếu mục tiêu là planning data trên set, mình recommend dùng GB theo hệ decimal.
Lý do là vì:
- SSD, thẻ nhớ, media và ổ cứng thường được bán theo GB/TB decimal
- tài liệu camera và media capacity thường dễ so sánh hơn theo cách này
- producer và production cũng quen với các con số kiểu 500 GB, 1 TB, 2 TB
- khi tính nhanh card runtime, daily data hoặc storage requirement, decimal GB trực quan hơn
Vì vậy trong tool này, mình dùng: File Size (GB) = Bitrate (Mbps) × Duration (seconds) ÷ 8000
Ví dụ: 500 Mbps × 1 giờ ≈ 225 GB
Đây là con số mình sẽ dùng để planning thẻ nhớ, SSD và tổng data một ngày quay. Còn GiB vẫn hữu ích nếu bạn đang kiểm tra dung lượng chính xác trong hệ điều hành, filesystem hoặc muốn đối chiếu với một phần mềm đang hiển thị theo hệ nhị phân.
Một cách nhớ đơn giản
GB = dùng để planning production
GiB = dùng khi muốn hiểu chính xác máy tính đang báo gì
Với DIT, mình thường ưu tiên GB/TB decimal cho workflow và storage planning, sau đó nếu cần mới convert sang GiB để đối chiếu với hệ thống thực tế. Điều quan trọng nhất không phải là chọn “phe” GB hay GiB, mà là đừng trộn hai cách tính trong cùng một bảng. Nếu calculator ghi GB, công thức cũng nên dùng decimal GB. Nếu đang hiển thị GiB, hãy ghi rõ là GiB. Đó cũng là lý do Bitrate Calculator của mình dùng GB decimal, để con số sát hơn với cách media và storage được ghi ngoài đời.