doubt that. try(If you have a large monitor set at a high resolution) popping open Photoshop and do a large, simple gradient. notice the slight striation and dithering?
</strong><hr></blockquote>
Well, this is exactly the kind of thing I was mentioning later on in the paragraph about 8 bits per channel and mainly monochromatic images. If you've only got 256 shades of, say, blue and do a blue gradient across the screen, you'll of course notice the steps.
[quote]<strong>
Really? have you checked out your PowerMac? how about your DVD player? looked into your DV camcorder? I'd be willing to bet that the formermost has a 16-bit audio I/O set-up. while the latter two both bear mere 10-bit audio hardware.
</strong><hr></blockquote>
Hehe, got me wrong there. Of course I was not trying to say that the majority of ADCs and DACs are 24/96 today, but rather that the majority of the ones that technically are, most don't manage to actually come close to the SNR theoretically possible at that bit depth.
(Besides, I don't really think any non-computer DVD-player that costs more than $20 comes with 10 bit DACs...)
[quote]<strong>
Emphasis on the "Current". try hooking an older analog LCD to a good SGI/HP/Compaq/IBM etc. machine. this is why I think digital I/O components(Read: those stupid USB speakers and ADC monitors Apple makes) are a bad idea.
</strong><hr></blockquote>
Well, the "analog" LCDs have their ADCs built-in, and I doubt they put completely "oversized" ones in there upon assembly. So unless you replace them, the situation is no better than with digital LCDs.
[quote]<strong>
Yup. whereas 24-bit only has around sixteen million(16,777,216) colors, 32-bit can theoretically do four billion(4,294,967,296). 48-bit can do up to two hundred and eighty one trillion(281,474,976,710,656). and full 64-bit can do over a whopping three hundred and forty duodecillion(340,282,366,920,938,463,463,374,607,4 31,768,211,000)!
</strong><hr></blockquote>
Um, AFAIK 32bit colors are really only 24bit colors, plus 8 bits alpha channel. The same would probably be true for 64bit (3x16 color + 1x16 alpha).
[quote]<strong>
and the power of high bit depth AD/DA circuitry could be tapped in a less CPU taxing fashion with palettes(Remember how a lot of games could get WAY more than 256 colors on early Macs? they did this by selecting 256 individual colors out of a static 16M color palette).
</strong><hr></blockquote>
I don't think palettized display modes and CLUTs will return any time soon.
While it let's you do nice palette cycling effects and stuff on output, and saves VRAM, it get's really complicated when you go the other way around (capturing video to palettized colors, e.g.).
[quote]<strong>
Using AltiVec that is. can you say "2x integer speed penalty"? like I said before. you need AT LEAST 64 bits throughout ALL of the CPU for maximum speed.
</strong><hr></blockquote>
What penalty are you talking about?
Also, how useful is it to perform integer ops on 64 bit numbers as long as you don't have 64 bits per color channel? I mean, how often do you really want to add two (RGBA) pixels with carries across color channels, or multiply (RGBA) by (RGBA)?
[quote]<strong>
That's what they said about 16-bit CDs. compare a 32-bit signal to an analog(A good one) signal on an oscilloscope. you'll notice tiny plateau-like steps in the digital signal. 32-bit is good. but 48-bit. or better yet. 64-bit audio is quite a bit better.
</strong><hr></blockquote>
More resolution of course always leads to a more realistic digitized representation, but there's a point of diminishing returns, and beyond that, it's just not worth the effort. What good is 64bit audio if you can only tell the difference to 32bit with some audio equivalent of a raster electron microsocope?
I'm glad you've found the smilies. Add enough smilies and other childish and ridiculous stuff to your post and distract from what it is all about and you'll win, even though your arguments (funnels) were proved wrong a long time ago (in theory).
(((Oh, and by the way: I've set up a few posix threads and concurrently read a directory containing 5000 files (each file's name, size and modification date, name alone wouldn't require individual inode reading in UFS). No thread locking occures on my SP Mac (both HFS+ and UFS) (which is of course what everybody except you was expecting), so I think even you should realize by now, that funnels aren't responsible for the finder blocking, as we have now an empirical proof too.)))
As for the 64 bit bus discussion and my posts ("...they would be accepted at face value"): Programmer has never been talking about byte reading but rather about bus traffic increase in general. I think his point indeed is valid, but so is mine. The problem is that we were quoting and arguing each other's posts several times although we were talking about very different things. So what's the point of continuing the discussion if we basically agree but discuss for the discussion's sake? Well, that's my take of it.
Now if you want to say something, read my first post in this thread where I was talking about Amorph's statement and tell me what's wrong about it. Alternatively, just post some smilies (may be worth more than 1000 words in your case).
<strong>As for the 64 bit bus discussion and my posts ("...they would be accepted at face value"): Programmer has never been talking about byte reading but rather about bus traffic increase in general. I think his point indeed is valid, but so is mine. The problem is that we were quoting and arguing each other's posts several times although we were talking about very different things. So what's the point of continuing the discussion if we basically agree but discuss for the discussion's sake? Well, that's my take of it.
</strong><hr></blockquote>
Exactly. Multiple discussions in the same thread got mixed up. Apologies for any confusion.
Someone said (to lazy to check) that if Moto build a memory controller into the G5 it had better be really forward-looking. Sounds fair enough, but couldn't this part be flash-programmable? I thought that Nvidia do this kind of thing already, though I don't know the specifics.
Flash programmable would end up being far to slow for the kind of bandwidth the G5 needs. You can't expect the G5 to last forever as a high end CPU, so i would suggest a memory technology that is suited at the time. DDR333 should be fine for the life of the G5. Is the DDR-II spec finished though?
<strong>Flash programmable would end up being far to slow for the kind of bandwidth the G5 needs. You can't expect the G5 to last forever as a high end CPU, so i would suggest a memory technology that is suited at the time. DDR333 should be fine for the life of the G5. Is the DDR-II spec finished though?</strong><hr></blockquote>
Considering the amount of time between the G4 and G5, I should hope that they either immediately support better than DDR333 or their memory controller design is flexible and can be easily enhanced in future revisions. Better yet, if it is a modular chip and Apple provides that module -- Motorola's current showing in the chipset department is rather lame!
<strong>What you say is true in the absolute, but there is no need of a 24 bit audio if the analogic conversion , amplification , and the HP are lame.
I doubt that we can see a difference when we ear a 16 bit audio signal compared to even a 64 bit signal on a basic HP (like the lame built-in HP of the tower). The problem is not coming from an huge prize difference between a 24 bits audio chipset and a 16 bit one, but from the huge difference of prize, between a standart qualities of amplifications and HP, and a very good one.
This is the mean reason why in the domain of HI-FI there is so huge difference of prizes. If you don't believe me just go in an auditorium and just try some different stuffs (if you are an audio pro, i don't need to convice you on that particular subject)</strong><hr></blockquote>
That could easily be solved by a little EM/RF insulation. as seen on <a href="http://www.orcawerks.com/sgi/o2/page3.html"; target="_blank">higher</a> end pieces of audio equipment.
<strong>Well, this is exactly the kind of thing I was mentioning later on in the paragraph about 8 bits per channel and mainly monochromatic images. If you've only got 256 shades of, say, blue and do a blue gradient across the screen, you'll of course notice the steps.</strong><hr></blockquote>
Precisely. and the only way to solve it is to bump up the bit depth.
[quote]Originally posted by RazzFazz:
<strong>Hehe, got me wrong there. Of course I was not trying to say that the majority of ADCs and DACs are 24/96 today, but rather that the majority of the ones that technically are, most don't manage to actually come close to the SNR theoretically possible at that bit depth.</strong><hr></blockquote>
That could easily be solved by a little EM/RF insulation. as seen on <a href="http://www.orcawerks.com/sgi/o2/page3.html"; target="_blank">higher</a> end pieces of audio equipment[/url].
[quote]Originally posted by RazzFazz:
<strong>(Besides, I don't really think any non-computer DVD-player that costs more than $20 comes with 10 bit DACs...)</strong><hr></blockquote>
<strong>Well, the "analog" LCDs have their ADCs built-in, and I doubt they put completely "oversized" ones in there upon assembly. So unless you replace them, the situation is no better than with digital LCDs.</strong><hr></blockquote>
Hmmm? you might actually be right on that count. but the LCD's shutters and backlights are fully analog. so you would at most only need to replace the controller subsystems.
[quote]Originally posted by RazzFazz:
<strong>Um, AFAIK 32bit colors are really only 24bit colors, plus 8 bits alpha channel. The same would probably be true for 64bit (3x16 color + 1x16 alpha).</strong><hr></blockquote>
You've just touched on one of my pet peeves. with many programs including multiple alpha channels(Photoshop), specialized maps like Z, bump and glow(Games and 3D modelers) as well as multiple internal color channels(Weather, solid and fluid physics apps). combined with the fact of that NONE of this ever leaves the computer. chopping off bits from each byte purely for the storage of just _one_ extra channel of data is stupid. I honestly can't think of one good reason to do this.
[quote]Originally posted by RazzFazz:
<strong>I don't think palettized display modes and CLUTs will return any time soon.
While it let's you do nice palette cycling effects and stuff on output, and saves VRAM, it get's really complicated when you go the other way around (capturing video to palettized colors, e.g.).</strong><hr></blockquote>
But think of the GAMMEZZZ .
[quote]Originally posted by RazzFazz:
<strong>What penalty are you talking about?</strong><hr></blockquote>
The one where you try to squeeze a 64-bit byte through a 32-bit processing unit. and have to do it in two clock cycles instead of one as a result.
[quote]Originally posted by RazzFazz:
<strong>Also, how useful is it to perform integer ops on 64 bit numbers as long as you don't have 64 bits per color channel? I mean, how often do you really want to add two (RGBA) pixels with carries across color channels, or multiply (RGBA) by (RGBA)?</strong><hr></blockquote>
It's useful. FPUs and VPUs are hot stuff. but the humble IPU still has it's place.
[quote]Originally posted by RazzFazz:
<strong>More resolution of course always leads to a more realistic digitized representation, but there's a point of diminishing returns, and beyond that, it's just not worth the effort. What good is 64bit audio if you can only tell the difference to 32bit with some audio equivalent of a raster electron microsocope?</strong><hr></blockquote>
Well _I_ can hear it :cool: . and besides. this would allow you to do MUCH more processing on a piece of audio before the resulting degradation became noticable on the final result(Kind of like the reason audio professionals today use 24/96 and 32/192 mixing on a product that they _know_ will be downsampled to 16/48 for CDs).
You've just touched on one of my pet peeves. with many programs including multiple alpha channels(Photoshop), specialized maps like Z, bump and glow(Games and 3D modelers) as well as multiple internal color channels(Weather, solid and fluid physics apps). combined with the fact of that NONE of this ever leaves the computer. chopping off bits from each byte purely for the storage of just _one_ extra channel of data is stupid. I honestly can't think of one good reason to do this.
</strong><hr></blockquote>
The alpha channel in the frame buffer is often used for the stencil or alpha buffer. As graphics effects get more complex the use of the destination alpha gets heavier and heavier. Storing it as part of the primary frame buffer saves quite a bit of bandwidth.
<strong>The alpha channel in the frame buffer is often used for the stencil or alpha buffer. As graphics effects get more complex the use of the destination alpha gets heavier and heavier. Storing it as part of the primary frame buffer saves quite a bit of bandwidth.</strong><hr></blockquote>
But not enough to justify slicing off 1/4 each byte. what I was saying is that. while single alternate maps/channels are still used in a few things. like OS X's Aqua. the vast majority of alternate map/channel using applications tend to employ _MULTIPLE_ alternate maps/channels.
With all these Z-maps, bump maps, multiple alpha and color channels, luminosity maps, reflection maps....... on and on to infinity. floating around. having one more alternate map/channel hooked on seperately instead of taking up valuable byte word space wouldn't make _that much_ of a difference. and it would certainly make everything look/sound a LOT nicer.
<strong>But not enough to justify slicing off 1/4 each byte. what I was saying is that. while single alternate maps/channels are still used in a few things. like OS X's Aqua. the vast majority of alternate map/channel using applications tend to employ _MULTIPLE_ alternate maps/channels.
With all these Z-maps, bump maps, multiple alpha and color channels, luminosity maps, reflection maps....... on and on to infinity. floating around. having one more alternate map/channel hooked on seperately instead of taking up valuable byte word space wouldn't make _that much_ of a difference. and it would certainly make everything look/sound a LOT nicer.</strong><hr></blockquote>
In 3D graphics bandwidth is very precious. A lot of effects just need one extra channel, and thus can play in a 32-bit frame buffer with no performance hit. Going beyond that the additional channels are either packed together, in which case you get 4 at the same cost as one... or they are seperate and you have to rely on locality of reference to be efficient. In the packed case we'd normally pile on the effects to use all 4 extra channels, i the seperate case we'd want to minimize them and thus the one freebie is valuable.
This is short term, however. Over the next few years performance and memory will increase enough that I agree with you that the bit depth of the frame buffer (and textures) will increase. 11/11/10 is an obvious first step, but it'll probably grow to a full 16-bits/channel. There may even be cases where a full 32-bit float per channel is desirable.
<strong>In 3D graphics bandwidth is very precious. A lot of effects just need one extra channel, and thus can play in a 32-bit frame buffer with no performance hit. Going beyond that the additional channels are either packed together, in which case you get 4 at the same cost as one... or they are seperate and you have to rely on locality of reference to be efficient. In the packed case we'd normally pile on the effects to use all 4 extra channels, i the seperate case we'd want to minimize them and thus the one freebie is valuable.</strong><hr></blockquote>
I still think this sort of thing was _never_ really justified. and using 3D accelerators as an example is a bad idea. as 3D games(The main users of such things) tend to be amongst the most alternate map/channel hungry applications out there. and we got along fine on full 8 and 16 bit bytes for years. only switching to the icky 1/4 byte word with 32-bit(24-bit video). if a IIci and a Quadra 660av got along without 1/4 byte words. I think a quad 1.5Ghz PPC 8xx0 could too.
[quote]Originally posted by Programmer:
<strong>This is short term, however. Over the next few years performance and memory will increase enough that I agree with you that the bit depth of the frame buffer (and textures) will increase.</strong><hr></blockquote>
Right on.
[quote]Originally posted by Programmer:
<strong>11/11/10 is an obvious first step, but it'll probably grow to a full 16-bits/channel. There may even be cases where a full 32-bit float per channel is desirable.</strong><hr></blockquote>
Hmmm... after a few calculations. I don't think it works this way. cause see:
One third of 24-bit=256 different numbers.
Three thirds of 24-bit stacked atop each other=1024 different numbers.
Full 24-bit=16,777,216 different numbers.
That means that if they really did split up the byte of each pixel into phosphors. then trucolor would only consist of 1024 colors! I guess they just use the 24-bit number value of a pixel's byte to look up a color out of a single large palette. in which each individual color and shade of gray is assigned a catologue-like binary number.
Hmmm... after a few calculations. I don't think it works this way. cause see:
One third of 24-bit=256 different numbers.
Three thirds of 24-bit stacked atop each other=1024 different numbers.
Full 24-bit=16,777,216 different numbers.
That means that if they really did split up the byte of each pixel into phosphors. then trucolor would only consist of 1024 colors! I guess they just use the 24-bit number value of a pixel's byte to look up a color out of a single large palette. in which each individual color and shade of gray is assigned a catologue-like binary number.</strong><hr></blockquote>
I really don't follow your logic here. Current 24-bit frame buffers (irrespective of the presense of the 8-bit alpha) send the 3 8-bit RGB values to 3 seperate 8-bit DACs. In the future the frame buffer channels will grow -- 11/11/10 is the largest that can fit in 32-bits and will probably be supported by 10-bit DACs. Beyond that 16-bit channels (48-bit pixels) are the next obvious step, but the DACs may still only be 10 or 12 bits except, perhaps, at the high end of the market.
Floating point channels may eventually be possible, but they are mainly a convenience, eliminating the need to convert to/from floating point and the resulting loss in precision (most new graphics engines operate in floating point internally, converting to integer only when writing to memory). If frame buffers are stored in this format, it'll probably only be for intermediate buffers -- the output buffer will likely remain integers.
Regarding the use of 32-bit vs 24-bit: The original reason this was done was for memory alignment issues. Processors fetch and store word aligned values more efficiently, and 24-bit values aren't word aligned. Padding it out to 32-bits allowed pixels to be addressed and manipulated more quickly and easily (consider that computing the byte address of a 24-bit pixel requires a multiply by 3, whereas computing the address of a 32-bit pixel can be done with a shift-by-two). This remains true for 3D accelerators, which now have the capability to actually use the extra 8-bits for something useful. Back in the days of the Quadra when memory was expensive, Apple actually didn't physically provide the extra 8-bit but their pixels were still 32-bits from an addressing point of view -- you just always got a zero alpha on every read.
That could easily be solved by a little EM/RF insulation. as seen on higher end pieces of audio equipment</strong><hr></blockquote>
I don't see any tech specs on the page linked to...
[quote]<strong>
I do. even many high-end DV and DVD products have only 10-bit A/D(Ok. I was off by two bits. the DVD player has a 12-bit DAC ). barf.
</strong><hr></blockquote>
Oh, I thought you were referring to the audio DAC (which is 24/96 on that DVD deck).
EDIT: Re-reading your original post, you were in fact referring to the audio DAC, and you were mistaken at least in this particular case.
[quote]<strong>
You've just touched on one of my pet peeves. with many programs including multiple alpha channels(Photoshop), specialized maps like Z, bump and glow(Games and 3D modelers) as well as multiple internal color channels(Weather, solid and fluid physics apps). combined with the fact of that NONE of this ever leaves the computer. chopping off bits from each byte purely for the storage of just _one_ extra channel of data is stupid. I honestly can't think of one good reason to do this.
</strong><hr></blockquote>
In fact, this works the other way round. It's not like they had 32bit for the color channels initially, and then thought "oh, damn, need to stick an alpha channel in there too, let's just trim the colors", but rather 24bit colors were the starting point. Now, unfortunately, handling 32bit data chunks is much easier and faster than handling 24bit ones (or any none-power-of-two ones for that matter), so graphics cards stored the 24 bits of color information in one doubleword (32bit) each. So when they had to add alpha information to textures with the advent of 3D acceleration, they just used the remaining, formerly unused 8 bits. But this really only applies to graphics data as stored in VRAM and rather simple formats. It does especially not apply to complex multilayered formats like PSD (which uses 32bit FP per color channel, IIRC).
[quote]<strong>
The one where you try to squeeze a 64-bit byte through a 32-bit processing unit. and have to do it in two clock cycles instead of one as a result.
</strong><hr></blockquote>
My point was that this doesn't apply at all here.
A 32bit color value is not really a continuous 32bit value, but rather 3 (4 with alpha) 8-bit-values grouped together. The same for your 64bit colors: Ech 64bit pixel is made up from 3 16bit color values, and possibly one 16bit alpha value. Because the individual channels are not inter-related, AltiVec can process two such pixels (4 for 32bits) in one operation.
[quote]<strong>
It's useful. FPUs and VPUs are hot stuff. but the humble IPU still has it's place.
</strong><hr></blockquote>
It of course does, but that place is not as related to 64bit colors as you seem to think.
[quote]<strong>
Well _I_ can hear it.
</strong><hr></blockquote>
With all due respect, but I'm 100% positive you could not tell 64bit FP audio from 32bit one with your bare ears.
[quote]<strong>
and besides. this would allow you to do MUCH more processing on a piece of audio before the resulting degradation became noticable on the final result(Kind of like the reason audio professionals today use 24/96 and 32/192 mixing on a product that they _know_ will be downsampled to 16/48 for CDs).
</strong><hr></blockquote>
This is technically true, and as you say it makes quite a lot of sense to use 24/96 when you downsample to 16/48, but you have to keep in mind that the effect is exponential. 48bits of headroom when producing a 16bit CD are nothing short of insane.
<strong>I really don't follow your logic here. Current 24-bit frame buffers (irrespective of the presense of the 8-bit alpha) send the 3 8-bit RGB values to 3 seperate 8-bit DACs. In the future the frame buffer channels will grow -- 11/11/10 is the largest that can fit in 32-bits and will probably be supported by 10-bit DACs. Beyond that 16-bit channels (48-bit pixels) are the next obvious step, but the DACs may still only be 10 or 12 bits except, perhaps, at the high end of the market.</strong><hr></blockquote>
Ah. I can see what you were trying to say. but I was noting that it's fundamentally flawed.
If only 8-bits(Binary digits) were being used to tell each phosphor(Or whatever you call it on LCD and plasma displays ) what to do. the laws of base two mathematics would kick in. and each phosphor on the monitor would only be capable of 256 different levels of brightness. as individual colors as a whole are made up of combinations of these things. such a system would have limited the palette range of the computer to a dramatically smaller number than sixteen million. this clearly illustrates my point that colors are defined as a single large binary number. instead of a stack of three smaller ones.
[quote]Originally posted by Programmer:
<strong>Floating point channels may eventually be possible, but they are mainly a convenience, eliminating the need to convert to/from floating point and the resulting loss in precision (most new graphics engines operate in floating point internally, converting to integer only when writing to memory). If frame buffers are stored in this format, it'll probably only be for intermediate buffers -- the output buffer will likely remain integers.</strong><hr></blockquote>
[quote]Originally posted by Programmer:
<strong>Regarding the use of 32-bit vs 24-bit: The original reason this was done was for memory alignment issues. Processors fetch and store word aligned values more efficiently, and 24-bit values aren't word aligned. Padding it out to 32-bits allowed pixels to be addressed and manipulated more quickly and easily (consider that computing the byte address of a 24-bit pixel requires a multiply by 3, whereas computing the address of a 32-bit pixel can be done with a shift-by-two). This remains true for 3D accelerators, which now have the capability to actually use the extra 8-bits for something useful. Back in the days of the Quadra when memory was expensive, Apple actually didn't physically provide the extra 8-bit but their pixels were still 32-bits from an addressing point of view -- you just always got a zero alpha on every read.</strong><hr></blockquote>
Same goes for 16-bit. which was also done in full. and like I was saying. the alpha(And everything else other than actual colors) should be hooked on in a later transmission. as there are nearly always yet even more alternate channels/maps tagging along too nowadays. and full 32-bit audio support in current Macs(Aside from the old ASIO implementation. it's even supported in OS 10.1's Core Audio ) further validates my point.
Ah. I can see what you were trying to say. but I was noting that it's fundamentally flawed.
</strong><hr></blockquote>
Actually, it's not flawed, it reality.
[quote]<strong>
If only 8-bits(Binary digits) were being used to tell each phosphor(Or whatever you call it on LCD and plasma displays ) what to do. the laws of base two mathematics would kick in. and each phosphor on the monitor would only be capable of 256 different levels of brightness. as individual colors as a whole are made up of combinations of these things. such a system would have limited the palette range of the computer to a dramatically smaller number than sixteen million. this clearly illustrates my point that colors are defined as a single large binary number. instead of a stack of three smaller ones.
</strong><hr></blockquote>
Absolutely not.
Each pixel on screen is made out of 3 sub-pixels (i.e. three phosphors), each one of which emits color at a different wavelength (red, green and blue, thus "RGB") when hit by the ion beam.
Thus, each pixel can be any combination of the 256 levels of color per sub-pixel. This makes for 256(R)*256(G)*256(B) colors, which (surprise, surprise) equals 16777216 or 2^24 possible colors.
<strong>I don't see any tech specs on the page linked to...</strong><hr></blockquote>
I wasn't looking for tech specs. just a picture of a heavily suited-up sound board to show what I meant by "EM/RF insulation".
[quote]Originally posted by RazzFazz:
<strong>Oh, I thought you were referring to the audio DAC (which is 24/96 on that DVD deck).
EDIT: Re-reading your original post, you were in fact referring to the audio DAC, and you were mistaken at least in this particular case.</strong><hr></blockquote>
Oops. we can't all all be perfect can we .
[quote]Originally posted by RazzFazz:
<strong>In fact, this works the other way round. It's not like they had 32bit for the color channels initially, and then thought "oh, damn, need to stick an alpha channel in there too, let's just trim the colors", but rather 24bit colors were the starting point. Now, unfortunately, handling 32bit data chunks is much easier and faster than handling 24bit ones (or any none-power-of-two ones for that matter), so graphics cards stored the 24 bits of color information in one doubleword (32bit) each. So when they had to add alpha information to textures with the advent of 3D acceleration, they just used the remaining, formerly unused 8 bits. But this really only applies to graphics data as stored in VRAM and rather simple formats. It does especially not apply to complex multilayered formats like PSD (which uses 32bit FP per color channel, IIRC).</strong><hr></blockquote>
No they didn't! they started off with 1-bit(Monochrome), 2-bit(4 colors), 4-bit(16 colors), 8-bit(256 colors) and (later)16-bit(Thousands of colors). _all of which_ divided evenly by 32(And by 16 too. the bit depth of <a href="http://www.everymac.com/systems/apple/mac_classic/stats/mac_128k.html"; target="_blank">The Original Macintosh's data path</a>). I have no idea of why they decided to reserve the last quarter of the byte for alternate channels/maps. probably to go along with the money grubbing synthesizer/digitizer manufacturers.
[quote]Originally posted by RazzFazz:
<strong>My point was that this doesn't apply at all here.
A 32bit color value is not really a continuous 32bit value, but rather 3 (4 with alpha) 8-bit-values grouped together. The same for your 64bit colors: Ech 64bit pixel is made up from 3 16bit color values, and possibly one 16bit alpha value. Because the individual channels are not inter-related, AltiVec can process two such pixels (4 for 32bits) in one operation.</strong><hr></blockquote>
Refer to prior comments to Programmer regarding the likelihood of a pixel's byte being quartered and drawn.
[quote]Originally posted by RazzFazz:
<strong>With all due respect, but I'm 100% positive you could not tell 64bit FP audio from 32bit one with your bare ears.</strong><hr></blockquote>
Pull out a good, analog laserdisc, hook up the player and your computer to your headphones through a good audio switcher and try it yourself(and make sure the analog stuff is top notch. bad analog sounds MUCH worse than bad digital. but good analog sounds quite a bit better than any digital audio does, has or ever will).
[quote]Originally posted by RazzFazz:
<strong>This is technically true, and as you say it makes quite a lot of sense to use 24/96 when you downsample to 16/48, but you have to keep in mind that the effect is exponential. 48bits of headroom when producing a 16bit CD are nothing short of insane.</strong><hr></blockquote>
Don't forget the future. 24/192/8.2 DVD-Audio discs are the end-format of the future. and it never hurts to be prepared .
<strong>Actually, it's not flawed, it reality.</strong><hr></blockquote>
We'll see?
[quote]Originally posted by RazzFazz:
<strong>Absolutely not.
Each pixel on screen is made out of 3 sub-pixels (i.e. three phosphors), each one of which emits color at a different wavelength (red, green and blue, thus "RGB") when hit by the ion beam.
Thus, each pixel can be any combination of the 256 levels of color per sub-pixel. This makes for 256(R)*256(G)*256(B) colors, which (surprise, surprise) equals 16777216 or 2^24 possible colors.</strong><hr></blockquote>
Hmm... your math is correct. but you're forgetting something. Macs originally used whole word sizes indivisable by three. such as eight and sixteen. to represent color. suddenly switching to a quartered byte to represent color would have proven practically impossible. as well as crippling either the new colors or the old ones.
Comments
<strong>
doubt that. try(If you have a large monitor set at a high resolution) popping open Photoshop and do a large, simple gradient. notice the slight striation and dithering?
</strong><hr></blockquote>
Well, this is exactly the kind of thing I was mentioning later on in the paragraph about 8 bits per channel and mainly monochromatic images. If you've only got 256 shades of, say, blue and do a blue gradient across the screen, you'll of course notice the steps.
[quote]<strong>
Really? have you checked out your PowerMac? how about your DVD player? looked into your DV camcorder? I'd be willing to bet that the formermost has a 16-bit audio I/O set-up. while the latter two both bear mere 10-bit audio hardware.
</strong><hr></blockquote>
Hehe, got me wrong there. Of course I was not trying to say that the majority of ADCs and DACs are 24/96 today, but rather that the majority of the ones that technically are, most don't manage to actually come close to the SNR theoretically possible at that bit depth.
(Besides, I don't really think any non-computer DVD-player that costs more than $20 comes with 10 bit DACs...)
[quote]<strong>
Emphasis on the "Current". try hooking an older analog LCD to a good SGI/HP/Compaq/IBM etc. machine. this is why I think digital I/O components(Read: those stupid USB speakers and ADC monitors Apple makes) are a bad idea.
</strong><hr></blockquote>
Well, the "analog" LCDs have their ADCs built-in, and I doubt they put completely "oversized" ones in there upon assembly. So unless you replace them, the situation is no better than with digital LCDs.
[quote]<strong>
Yup. whereas 24-bit only has around sixteen million(16,777,216) colors, 32-bit can theoretically do four billion(4,294,967,296). 48-bit can do up to two hundred and eighty one trillion(281,474,976,710,656). and full 64-bit can do over a whopping three hundred and forty duodecillion(340,282,366,920,938,463,463,374,607,4 31,768,211,000)!
</strong><hr></blockquote>
Um, AFAIK 32bit colors are really only 24bit colors, plus 8 bits alpha channel. The same would probably be true for 64bit (3x16 color + 1x16 alpha).
[quote]<strong>
and the power of high bit depth AD/DA circuitry could be tapped in a less CPU taxing fashion with palettes(Remember how a lot of games could get WAY more than 256 colors on early Macs? they did this by selecting 256 individual colors out of a static 16M color palette).
</strong><hr></blockquote>
I don't think palettized display modes and CLUTs will return any time soon.
While it let's you do nice palette cycling effects and stuff on output, and saves VRAM, it get's really complicated when you go the other way around (capturing video to palettized colors, e.g.).
[quote]<strong>
Using AltiVec that is. can you say "2x integer speed penalty"? like I said before. you need AT LEAST 64 bits throughout ALL of the CPU for maximum speed.
</strong><hr></blockquote>
What penalty are you talking about?
Also, how useful is it to perform integer ops on 64 bit numbers as long as you don't have 64 bits per color channel? I mean, how often do you really want to add two (RGBA) pixels with carries across color channels, or multiply (RGBA) by (RGBA)?
[quote]<strong>
That's what they said about 16-bit CDs. compare a 32-bit signal to an analog(A good one) signal on an oscilloscope. you'll notice tiny plateau-like steps in the digital signal. 32-bit is good. but 48-bit. or better yet. 64-bit audio is quite a bit better.
</strong><hr></blockquote>
More resolution of course always leads to a more realistic digitized representation, but there's a point of diminishing returns, and beyond that, it's just not worth the effort. What good is 64bit audio if you can only tell the difference to 32bit with some audio equivalent of a raster electron microsocope?
Bye,
RazzFazz
[ 04-09-2002: Message edited by: RazzFazz ]</p>
I'm glad you've found the smilies. Add enough smilies and other childish and ridiculous stuff to your post and distract from what it is all about and you'll win, even though your arguments (funnels) were proved wrong a long time ago (in theory).
(((Oh, and by the way: I've set up a few posix threads and concurrently read a directory containing 5000 files (each file's name, size and modification date, name alone wouldn't require individual inode reading in UFS). No thread locking occures on my SP Mac (both HFS+ and UFS) (which is of course what everybody except you was expecting), so I think even you should realize by now, that funnels aren't responsible for the finder blocking, as we have now an empirical proof too.)))
As for the 64 bit bus discussion and my posts ("...they would be accepted at face value"): Programmer has never been talking about byte reading but rather about bus traffic increase in general. I think his point indeed is valid, but so is mine. The problem is that we were quoting and arguing each other's posts several times although we were talking about very different things. So what's the point of continuing the discussion if we basically agree but discuss for the discussion's sake? Well, that's my take of it.
Now if you want to say something, read my first post in this thread where I was talking about Amorph's statement and tell me what's wrong about it. Alternatively, just post some smilies (may be worth more than 1000 words in your case).
[ 04-09-2002: Message edited by: 123 ]</p>
This is an informative thread. Let's keep it that way.
<strong>As for the 64 bit bus discussion and my posts ("...they would be accepted at face value"): Programmer has never been talking about byte reading but rather about bus traffic increase in general. I think his point indeed is valid, but so is mine. The problem is that we were quoting and arguing each other's posts several times although we were talking about very different things. So what's the point of continuing the discussion if we basically agree but discuss for the discussion's sake? Well, that's my take of it.
</strong><hr></blockquote>
Exactly. Multiple discussions in the same thread got mixed up. Apologies for any confusion.
Someone said (to lazy to check) that if Moto build a memory controller into the G5 it had better be really forward-looking. Sounds fair enough, but couldn't this part be flash-programmable? I thought that Nvidia do this kind of thing already, though I don't know the specifics.
<strong>Flash programmable would end up being far to slow for the kind of bandwidth the G5 needs. You can't expect the G5 to last forever as a high end CPU, so i would suggest a memory technology that is suited at the time. DDR333 should be fine for the life of the G5. Is the DDR-II spec finished though?</strong><hr></blockquote>
Considering the amount of time between the G4 and G5, I should hope that they either immediately support better than DDR333 or their memory controller design is flexible and can be easily enhanced in future revisions. Better yet, if it is a modular chip and Apple provides that module -- Motorola's current showing in the chipset department is rather lame!
<strong>What you say is true in the absolute, but there is no need of a 24 bit audio if the analogic conversion , amplification , and the HP are lame.
I doubt that we can see a difference when we ear a 16 bit audio signal compared to even a 64 bit signal on a basic HP (like the lame built-in HP of the tower). The problem is not coming from an huge prize difference between a 24 bits audio chipset and a 16 bit one, but from the huge difference of prize, between a standart qualities of amplifications and HP, and a very good one.
This is the mean reason why in the domain of HI-FI there is so huge difference of prizes. If you don't believe me just go in an auditorium and just try some different stuffs (if you are an audio pro, i don't need to convice you on that particular subject)</strong><hr></blockquote>
That could easily be solved by a little EM/RF insulation. as seen on <a href="http://www.orcawerks.com/sgi/o2/page3.html"; target="_blank">higher</a> end pieces of audio equipment.
Eric,
[ 04-10-2002: Message edited by: Eric D.V.H ]
[ 04-10-2002: Message edited by: Eric D.V.H ]</p>
<strong>Well, this is exactly the kind of thing I was mentioning later on in the paragraph about 8 bits per channel and mainly monochromatic images. If you've only got 256 shades of, say, blue and do a blue gradient across the screen, you'll of course notice the steps.</strong><hr></blockquote>
Precisely. and the only way to solve it is to bump up the bit depth.
[quote]Originally posted by RazzFazz:
<strong>Hehe, got me wrong there. Of course I was not trying to say that the majority of ADCs and DACs are 24/96 today, but rather that the majority of the ones that technically are, most don't manage to actually come close to the SNR theoretically possible at that bit depth.</strong><hr></blockquote>
That could easily be solved by a little EM/RF insulation. as seen on <a href="http://www.orcawerks.com/sgi/o2/page3.html"; target="_blank">higher</a> end pieces of audio equipment[/url].
[quote]Originally posted by RazzFazz:
<strong>(Besides, I don't really think any non-computer DVD-player that costs more than $20 comes with 10 bit DACs...)</strong><hr></blockquote>
I do. even many high-end <a href="http://www.panasonic.com/PBDS/subcat/Products/cams_ccorders/f_aj-d410a.html"; target="_blank">DV</a> and <a href="http://www.sel.sony.com/SEL/consumer/ss5/home/dvd/dvdplayers/dvp-s9000es_specs.shtml"; target="_blank">DVD</a> products have only 10-bit A/D(Ok. I was off by two bits. the DVD player has a 12-bit DAC
[quote]Originally posted by RazzFazz:
<strong>Well, the "analog" LCDs have their ADCs built-in, and I doubt they put completely "oversized" ones in there upon assembly. So unless you replace them, the situation is no better than with digital LCDs.</strong><hr></blockquote>
Hmmm? you might actually be right on that count. but the LCD's shutters and backlights are fully analog. so you would at most only need to replace the controller subsystems.
[quote]Originally posted by RazzFazz:
<strong>Um, AFAIK 32bit colors are really only 24bit colors, plus 8 bits alpha channel. The same would probably be true for 64bit (3x16 color + 1x16 alpha).</strong><hr></blockquote>
You've just touched on one of my pet peeves. with many programs including multiple alpha channels(Photoshop), specialized maps like Z, bump and glow(Games and 3D modelers) as well as multiple internal color channels(Weather, solid and fluid physics apps). combined with the fact of that NONE of this ever leaves the computer. chopping off bits from each byte purely for the storage of just _one_ extra channel of data is stupid. I honestly can't think of one good reason to do this.
[quote]Originally posted by RazzFazz:
<strong>I don't think palettized display modes and CLUTs will return any time soon.
While it let's you do nice palette cycling effects and stuff on output, and saves VRAM, it get's really complicated when you go the other way around (capturing video to palettized colors, e.g.).</strong><hr></blockquote>
But think of the GAMMEZZZ
[quote]Originally posted by RazzFazz:
<strong>What penalty are you talking about?</strong><hr></blockquote>
The one where you try to squeeze a 64-bit byte through a 32-bit processing unit. and have to do it in two clock cycles instead of one as a result.
[quote]Originally posted by RazzFazz:
<strong>Also, how useful is it to perform integer ops on 64 bit numbers as long as you don't have 64 bits per color channel? I mean, how often do you really want to add two (RGBA) pixels with carries across color channels, or multiply (RGBA) by (RGBA)?</strong><hr></blockquote>
It's useful. FPUs and VPUs are hot stuff. but the humble IPU still has it's place.
[quote]Originally posted by RazzFazz:
<strong>More resolution of course always leads to a more realistic digitized representation, but there's a point of diminishing returns, and beyond that, it's just not worth the effort. What good is 64bit audio if you can only tell the difference to 32bit with some audio equivalent of a raster electron microsocope?</strong><hr></blockquote>
Well _I_ can hear it :cool: . and besides. this would allow you to do MUCH more processing on a piece of audio before the resulting degradation became noticable on the final result(Kind of like the reason audio professionals today use 24/96 and 32/192 mixing on a product that they _know_ will be downsampled to 16/48 for CDs).
Eric,
[ 04-10-2002: Message edited by: Eric D.V.H ]</p>
You've just touched on one of my pet peeves. with many programs including multiple alpha channels(Photoshop), specialized maps like Z, bump and glow(Games and 3D modelers) as well as multiple internal color channels(Weather, solid and fluid physics apps). combined with the fact of that NONE of this ever leaves the computer. chopping off bits from each byte purely for the storage of just _one_ extra channel of data is stupid. I honestly can't think of one good reason to do this.
</strong><hr></blockquote>
The alpha channel in the frame buffer is often used for the stencil or alpha buffer. As graphics effects get more complex the use of the destination alpha gets heavier and heavier. Storing it as part of the primary frame buffer saves quite a bit of bandwidth.
<strong>The alpha channel in the frame buffer is often used for the stencil or alpha buffer. As graphics effects get more complex the use of the destination alpha gets heavier and heavier. Storing it as part of the primary frame buffer saves quite a bit of bandwidth.</strong><hr></blockquote>
But not enough to justify slicing off 1/4 each byte. what I was saying is that. while single alternate maps/channels are still used in a few things. like OS X's Aqua. the vast majority of alternate map/channel using applications tend to employ _MULTIPLE_ alternate maps/channels.
With all these Z-maps, bump maps, multiple alpha and color channels, luminosity maps, reflection maps....... on and on to infinity. floating around. having one more alternate map/channel hooked on seperately instead of taking up valuable byte word space wouldn't make _that much_ of a difference. and it would certainly make everything look/sound a LOT nicer.
Eric,
[ 04-10-2002: Message edited by: Eric D.V.H ]</p>
<strong>But not enough to justify slicing off 1/4 each byte. what I was saying is that. while single alternate maps/channels are still used in a few things. like OS X's Aqua. the vast majority of alternate map/channel using applications tend to employ _MULTIPLE_ alternate maps/channels.
With all these Z-maps, bump maps, multiple alpha and color channels, luminosity maps, reflection maps....... on and on to infinity. floating around. having one more alternate map/channel hooked on seperately instead of taking up valuable byte word space wouldn't make _that much_ of a difference. and it would certainly make everything look/sound a LOT nicer.</strong><hr></blockquote>
In 3D graphics bandwidth is very precious. A lot of effects just need one extra channel, and thus can play in a 32-bit frame buffer with no performance hit. Going beyond that the additional channels are either packed together, in which case you get 4 at the same cost as one... or they are seperate and you have to rely on locality of reference to be efficient. In the packed case we'd normally pile on the effects to use all 4 extra channels, i the seperate case we'd want to minimize them and thus the one freebie is valuable.
This is short term, however. Over the next few years performance and memory will increase enough that I agree with you that the bit depth of the frame buffer (and textures) will increase. 11/11/10 is an obvious first step, but it'll probably grow to a full 16-bits/channel. There may even be cases where a full 32-bit float per channel is desirable.
<strong>In 3D graphics bandwidth is very precious. A lot of effects just need one extra channel, and thus can play in a 32-bit frame buffer with no performance hit. Going beyond that the additional channels are either packed together, in which case you get 4 at the same cost as one... or they are seperate and you have to rely on locality of reference to be efficient. In the packed case we'd normally pile on the effects to use all 4 extra channels, i the seperate case we'd want to minimize them and thus the one freebie is valuable.</strong><hr></blockquote>
I still think this sort of thing was _never_ really justified. and using 3D accelerators as an example is a bad idea. as 3D games(The main users of such things) tend to be amongst the most alternate map/channel hungry applications out there. and we got along fine on full 8 and 16 bit bytes for years. only switching to the icky 1/4 byte word with 32-bit(24-bit video). if a IIci and a Quadra 660av got along without 1/4 byte words. I think a quad 1.5Ghz PPC 8xx0 could too.
[quote]Originally posted by Programmer:
<strong>This is short term, however. Over the next few years performance and memory will increase enough that I agree with you that the bit depth of the frame buffer (and textures) will increase.</strong><hr></blockquote>
Right on.
[quote]Originally posted by Programmer:
<strong>11/11/10 is an obvious first step, but it'll probably grow to a full 16-bits/channel. There may even be cases where a full 32-bit float per channel is desirable.</strong><hr></blockquote>
Hmmm... after a few calculations. I don't think it works this way. cause see:
- One third of 24-bit=256 different numbers.
- Three thirds of 24-bit stacked atop each other=1024 different numbers.
- Full 24-bit=16,777,216 different numbers.
That means that if they really did split up the byte of each pixel into phosphors. then trucolor would only consist of 1024 colors! I guess they just use the 24-bit number value of a pixel's byte to look up a color out of a single large palette. in which each individual color and shade of gray is assigned a catologue-like binary number.Eric,
[ 04-10-2002: Message edited by: Eric D.V.H ]</p>
<strong>
Hmmm... after a few calculations. I don't think it works this way. cause see:
- One third of 24-bit=256 different numbers.
- Three thirds of 24-bit stacked atop each other=1024 different numbers.
- Full 24-bit=16,777,216 different numbers.
That means that if they really did split up the byte of each pixel into phosphors. then trucolor would only consist of 1024 colors! I guess they just use the 24-bit number value of a pixel's byte to look up a color out of a single large palette. in which each individual color and shade of gray is assigned a catologue-like binary number.</strong><hr></blockquote>I really don't follow your logic here. Current 24-bit frame buffers (irrespective of the presense of the 8-bit alpha) send the 3 8-bit RGB values to 3 seperate 8-bit DACs. In the future the frame buffer channels will grow -- 11/11/10 is the largest that can fit in 32-bits and will probably be supported by 10-bit DACs. Beyond that 16-bit channels (48-bit pixels) are the next obvious step, but the DACs may still only be 10 or 12 bits except, perhaps, at the high end of the market.
Floating point channels may eventually be possible, but they are mainly a convenience, eliminating the need to convert to/from floating point and the resulting loss in precision (most new graphics engines operate in floating point internally, converting to integer only when writing to memory). If frame buffers are stored in this format, it'll probably only be for intermediate buffers -- the output buffer will likely remain integers.
Regarding the use of 32-bit vs 24-bit: The original reason this was done was for memory alignment issues. Processors fetch and store word aligned values more efficiently, and 24-bit values aren't word aligned. Padding it out to 32-bits allowed pixels to be addressed and manipulated more quickly and easily (consider that computing the byte address of a 24-bit pixel requires a multiply by 3, whereas computing the address of a 32-bit pixel can be done with a shift-by-two). This remains true for 3D accelerators, which now have the capability to actually use the extra 8-bits for something useful. Back in the days of the Quadra when memory was expensive, Apple actually didn't physically provide the extra 8-bit but their pixels were still 32-bits from an addressing point of view -- you just always got a zero alpha on every read.
<strong>
That could easily be solved by a little EM/RF insulation. as seen on higher end pieces of audio equipment</strong><hr></blockquote>
I don't see any tech specs on the page linked to...
[quote]<strong>
I do. even many high-end DV and DVD products have only 10-bit A/D(Ok. I was off by two bits. the DVD player has a 12-bit DAC ). barf.
</strong><hr></blockquote>
Oh, I thought you were referring to the audio DAC (which is 24/96 on that DVD deck).
EDIT: Re-reading your original post, you were in fact referring to the audio DAC, and you were mistaken at least in this particular case.
[quote]<strong>
You've just touched on one of my pet peeves. with many programs including multiple alpha channels(Photoshop), specialized maps like Z, bump and glow(Games and 3D modelers) as well as multiple internal color channels(Weather, solid and fluid physics apps). combined with the fact of that NONE of this ever leaves the computer. chopping off bits from each byte purely for the storage of just _one_ extra channel of data is stupid. I honestly can't think of one good reason to do this.
</strong><hr></blockquote>
In fact, this works the other way round. It's not like they had 32bit for the color channels initially, and then thought "oh, damn, need to stick an alpha channel in there too, let's just trim the colors", but rather 24bit colors were the starting point. Now, unfortunately, handling 32bit data chunks is much easier and faster than handling 24bit ones (or any none-power-of-two ones for that matter), so graphics cards stored the 24 bits of color information in one doubleword (32bit) each. So when they had to add alpha information to textures with the advent of 3D acceleration, they just used the remaining, formerly unused 8 bits. But this really only applies to graphics data as stored in VRAM and rather simple formats. It does especially not apply to complex multilayered formats like PSD (which uses 32bit FP per color channel, IIRC).
[quote]<strong>
The one where you try to squeeze a 64-bit byte through a 32-bit processing unit. and have to do it in two clock cycles instead of one as a result.
</strong><hr></blockquote>
My point was that this doesn't apply at all here.
A 32bit color value is not really a continuous 32bit value, but rather 3 (4 with alpha) 8-bit-values grouped together. The same for your 64bit colors: Ech 64bit pixel is made up from 3 16bit color values, and possibly one 16bit alpha value. Because the individual channels are not inter-related, AltiVec can process two such pixels (4 for 32bits) in one operation.
[quote]<strong>
It's useful. FPUs and VPUs are hot stuff. but the humble IPU still has it's place.
</strong><hr></blockquote>
It of course does, but that place is not as related to 64bit colors as you seem to think.
[quote]<strong>
Well _I_ can hear it.
</strong><hr></blockquote>
With all due respect, but I'm 100% positive you could not tell 64bit FP audio from 32bit one with your bare ears.
[quote]<strong>
and besides. this would allow you to do MUCH more processing on a piece of audio before the resulting degradation became noticable on the final result(Kind of like the reason audio professionals today use 24/96 and 32/192 mixing on a product that they _know_ will be downsampled to 16/48 for CDs).
</strong><hr></blockquote>
This is technically true, and as you say it makes quite a lot of sense to use 24/96 when you downsample to 16/48, but you have to keep in mind that the effect is exponential. 48bits of headroom when producing a 16bit CD are nothing short of insane.
Bye,
RazzFazz
[ 04-11-2002: Message edited by: RazzFazz ]</p>
<strong>I really don't follow your logic here. Current 24-bit frame buffers (irrespective of the presense of the 8-bit alpha) send the 3 8-bit RGB values to 3 seperate 8-bit DACs. In the future the frame buffer channels will grow -- 11/11/10 is the largest that can fit in 32-bits and will probably be supported by 10-bit DACs. Beyond that 16-bit channels (48-bit pixels) are the next obvious step, but the DACs may still only be 10 or 12 bits except, perhaps, at the high end of the market.</strong><hr></blockquote>
Ah. I can see what you were trying to say. but I was noting that it's fundamentally flawed.
If only 8-bits(Binary digits) were being used to tell each phosphor(Or whatever you call it on LCD and plasma displays
[quote]Originally posted by Programmer:
<strong>Floating point channels may eventually be possible, but they are mainly a convenience, eliminating the need to convert to/from floating point and the resulting loss in precision (most new graphics engines operate in floating point internally, converting to integer only when writing to memory). If frame buffers are stored in this format, it'll probably only be for intermediate buffers -- the output buffer will likely remain integers.</strong><hr></blockquote>
[quote]Originally posted by Programmer:
<strong>Regarding the use of 32-bit vs 24-bit: The original reason this was done was for memory alignment issues. Processors fetch and store word aligned values more efficiently, and 24-bit values aren't word aligned. Padding it out to 32-bits allowed pixels to be addressed and manipulated more quickly and easily (consider that computing the byte address of a 24-bit pixel requires a multiply by 3, whereas computing the address of a 32-bit pixel can be done with a shift-by-two). This remains true for 3D accelerators, which now have the capability to actually use the extra 8-bits for something useful. Back in the days of the Quadra when memory was expensive, Apple actually didn't physically provide the extra 8-bit but their pixels were still 32-bits from an addressing point of view -- you just always got a zero alpha on every read.</strong><hr></blockquote>
Same goes for 16-bit. which was also done in full. and like I was saying. the alpha(And everything else other than actual colors) should be hooked on in a later transmission. as there are nearly always yet even more alternate channels/maps tagging along too nowadays. and full 32-bit audio support in current Macs(Aside from the old ASIO implementation. it's even supported in OS 10.1's Core Audio
Eric,
<strong>
Ah. I can see what you were trying to say. but I was noting that it's fundamentally flawed.
</strong><hr></blockquote>
Actually, it's not flawed, it reality.
[quote]<strong>
If only 8-bits(Binary digits) were being used to tell each phosphor(Or whatever you call it on LCD and plasma displays ) what to do. the laws of base two mathematics would kick in. and each phosphor on the monitor would only be capable of 256 different levels of brightness. as individual colors as a whole are made up of combinations of these things. such a system would have limited the palette range of the computer to a dramatically smaller number than sixteen million. this clearly illustrates my point that colors are defined as a single large binary number. instead of a stack of three smaller ones.
</strong><hr></blockquote>
Absolutely not.
Each pixel on screen is made out of 3 sub-pixels (i.e. three phosphors), each one of which emits color at a different wavelength (red, green and blue, thus "RGB") when hit by the ion beam.
Thus, each pixel can be any combination of the 256 levels of color per sub-pixel. This makes for 256(R)*256(G)*256(B) colors, which (surprise, surprise) equals 16777216 or 2^24 possible colors.
Bye,
RazzFazz
<strong>I don't see any tech specs on the page linked to...</strong><hr></blockquote>
I wasn't looking for tech specs. just a picture of a heavily suited-up sound board to show what I meant by "EM/RF insulation".
[quote]Originally posted by RazzFazz:
<strong>Oh, I thought you were referring to the audio DAC (which is 24/96 on that DVD deck).
EDIT: Re-reading your original post, you were in fact referring to the audio DAC, and you were mistaken at least in this particular case.</strong><hr></blockquote>
Oops. we can't all all be perfect can we
[quote]Originally posted by RazzFazz:
<strong>In fact, this works the other way round. It's not like they had 32bit for the color channels initially, and then thought "oh, damn, need to stick an alpha channel in there too, let's just trim the colors", but rather 24bit colors were the starting point. Now, unfortunately, handling 32bit data chunks is much easier and faster than handling 24bit ones (or any none-power-of-two ones for that matter), so graphics cards stored the 24 bits of color information in one doubleword (32bit) each. So when they had to add alpha information to textures with the advent of 3D acceleration, they just used the remaining, formerly unused 8 bits. But this really only applies to graphics data as stored in VRAM and rather simple formats. It does especially not apply to complex multilayered formats like PSD (which uses 32bit FP per color channel, IIRC).</strong><hr></blockquote>
No they didn't! they started off with 1-bit(Monochrome), 2-bit(4 colors), 4-bit(16 colors), 8-bit(256 colors) and (later)16-bit(Thousands of colors). _all of which_ divided evenly by 32(And by 16 too. the bit depth of <a href="http://www.everymac.com/systems/apple/mac_classic/stats/mac_128k.html"; target="_blank">The Original Macintosh's data path</a>). I have no idea of why they decided to reserve the last quarter of the byte for alternate channels/maps. probably to go along with the money grubbing synthesizer/digitizer manufacturers.
[quote]Originally posted by RazzFazz:
<strong>My point was that this doesn't apply at all here.
A 32bit color value is not really a continuous 32bit value, but rather 3 (4 with alpha) 8-bit-values grouped together. The same for your 64bit colors: Ech 64bit pixel is made up from 3 16bit color values, and possibly one 16bit alpha value. Because the individual channels are not inter-related, AltiVec can process two such pixels (4 for 32bits) in one operation.</strong><hr></blockquote>
Refer to prior comments to Programmer regarding the likelihood of a pixel's byte being quartered and drawn.
[quote]Originally posted by RazzFazz:
<strong>With all due respect, but I'm 100% positive you could not tell 64bit FP audio from 32bit one with your bare ears.</strong><hr></blockquote>
Pull out a good, analog laserdisc, hook up the player and your computer to your headphones through a good audio switcher and try it yourself(and make sure the analog stuff is top notch. bad analog sounds MUCH worse than bad digital. but good analog sounds quite a bit better than any digital audio does, has or ever will).
[quote]Originally posted by RazzFazz:
<strong>This is technically true, and as you say it makes quite a lot of sense to use 24/96 when you downsample to 16/48, but you have to keep in mind that the effect is exponential. 48bits of headroom when producing a 16bit CD are nothing short of insane.</strong><hr></blockquote>
Don't forget the future. 24/192/8.2 DVD-Audio discs are the end-format of the future. and it never hurts to be prepared
Eric.
[ 04-12-2002: Message edited by: Eric D.V.H ]
[ 04-12-2002: Message edited by: Eric D.V.H ]</p>
<strong>Actually, it's not flawed, it reality.</strong><hr></blockquote>
We'll see?
[quote]Originally posted by RazzFazz:
<strong>Absolutely not.
Each pixel on screen is made out of 3 sub-pixels (i.e. three phosphors), each one of which emits color at a different wavelength (red, green and blue, thus "RGB") when hit by the ion beam.
Thus, each pixel can be any combination of the 256 levels of color per sub-pixel. This makes for 256(R)*256(G)*256(B) colors, which (surprise, surprise) equals 16777216 or 2^24 possible colors.</strong><hr></blockquote>
Hmm... your math is correct. but you're forgetting something. Macs originally used whole word sizes indivisable by three. such as eight and sixteen. to represent color. suddenly switching to a quartered byte to represent color would have proven practically impossible. as well as crippling either the new colors or the old ones.
Eric,