8 ms·
Well, obviously it would have delayed the transition. However you can only go so far with 4Go-limited memory. And do you have examples of still widely used 8-b
by BlueTemplar 6y ago
Well, obviously it would have delayed the transition. However you can only go so far with 4Go-limited memory.
And do you have examples of still widely used 8-bit sized data formats ?
- jart 6y agoRGB and Y′CbCr
- BlueTemplar 6y agoTo start with, RGB (and I assume Y′CbCr ?) can be encoded in many different ways. The most common one today (still) uses 8 bits per channel, meaning that a separated 1-octet value can only define monochrome. Therefore 8-bpc RGB is a 24-bit sized format, not a 8-bit sized data one. And, by an interesting coincidence, with the arrival of "HDR", 8-bit per channel is slowly becoming obsolete (because insufficient). The next "step" is 10-bit per channel with 3 channels (hence "HDR10(+)"), and so should fit quite well in 32 bits ? (However, it would seem that even Dolby's Perceptual Quantizer transfer function might need 12 bits per channel to avoid banding over the "HDR" Rec.2020/2100-sized color gamut..?)
- jart 6y agoWe're debating semantics, but if I reshaped an RGB image into component arrays i.e. u8[yn][xn][3] → u8[3][yn][xn] then would you still view that as a 24-bit format? What if those 24-bit values were huffman or run-length encoded would it be an n-bit format? If your Y′CbCr luminance plane has a legal range of 16..235 and the chrominance planes are 16..240, then would it be a 23.40892 bit format?
- BlueTemplar 6y agoI'm arguing about non-compressed, eventually padded data types that make learning Unicode (or any other applicable data format) easier because of the equivalence : 1 atomic unit ("character", pixel) = 1 smallest addressable unit of memory (byte). This involves byte size being at least as large as atom size. And it's particularly important to have this property for text, because not only data is overwhelmingly stored as text (in importance, not by "weight"), but because computer programs themselves are written using text.
- jart 6y agoCan you recommend me a good PC computer display at any cost that has an objectively good gamut so I can see what you see?
- BlueTemplar 6y agoI'm sorry, I'm not sure that I understand ?
- jart 6y agoWell I figured since you feel strongly about using a type wider than 8-bits for RGB you must have a really good display that actually lets you perceive the colors that enables you to encode. Most PC displays are garbage including the expensive ones because first, sRGB only specifies a very small portion of light that's perceivable and secondly, any display maker who builds something better is going to run into complaints about how terrible netflix looks, because it reveals things like banding (which you mentioned) that otherwise wouldn't be perceivable. So I was hoping you could recommend me a better monitor, so I can get into >8 bit RGB, because I've found it exceedingly difficult to shop around for this kind of thing.
- BlueTemplar 6y agoOk, so you weren't sarcastic and/or misunderstanding my use of "atomic". Sadly, I kind of gave up on getting a "HDR" display, at least for now, because : - AFAIK neither Linux nor Windows have good enough "HDR" support yet. (MacOS supposedly does, but I'm not interested.) - I'm happy enough with my HP LP2475w which I got for dirt cheap just before "HDR" became a thing. I consider the 1920x1200 resolution to be perfect for now (as a bonus I can manually scale various old resolutions like 800x600 to be pixel-perfect) - too many programs/OSes still have issues with auto-scaling programs on higher resolution screens (which would come with "HDR"). I'm also particularly fond of the 16:10 ratio, which seems to have gone extinct. - Maybe I'll be able to run this monitor properly in wide gamuts (though with banding), or maybe even in some kind of ""HDR" compatibility mode", though it would seem that the current sellers of "HDR" screens aren't going to make that easy. I might be able to get a colorimeter soon to properly calibrate it.
- owl57 6y agoI assume you wrote this comment in UTF-8 over HTTP (ASCII-based) and TLS (lots of uint8 fields).
- BlueTemplar 6y agoTo clarify : I'm more concerned about "final" data formats, less about "transport" ones, which need much longer legacy support.
- Narishma 6y agoYou can go very far with just 4GB of memory, especially when not using wasteful software.
- spacechild1 6y agoMIDI (8 bit), 16 bit PCM, 24 PCM and basically any compressed data format (which is always byte based, because the idea is to save memory). You obviously don't care about memory, but many people do!
- BlueTemplar 6y agoBut compressed data formats aren't going to care about byte size for this very reason...
- spacechild1 6y agoOk, bad example. But still, 'byte' refers to the smallest addressable unit of memory. There's just no point in arguing over its size...