|
| Author | Thread |
|
|
02/05/2007 11:29:44 PM · #1 |
I created a new page in cs2 tonight, and I started with 11x14 size, 16 bit, and I think resolution at about 200/250 (I forget). anyway, it ends up being a 195 mb tiff file.
Is it worth it?
Also, is there a quick way to convert back to 8 bit so it isn't so stinkin big? |
|
|
|
02/05/2007 11:32:30 PM · #2 |
| Image > Mode > 8 Bits/Channel |
|
|
|
02/05/2007 11:37:12 PM · #3 |
If you are creating a new image in photoshop (i.e. not opening a photo to edit) I would just work in 8 bit from the get go.
|
|
|
|
02/07/2007 03:58:52 PM · #4 |
If your image was a 16 bit to start with (i.e. RAW processed to 16 bit tiff) then it is worth working on it as a 16 bit for color, curves and so forth. The 16 bit file gives you a lot more to work with. One example is levles. Open an image that is 8 bit and go to levles and look at the histogram. Then go to curves and do a drastic adjustment then go to levles and look at the jagged lines with sepperation between them (areas with no info). Do the same with a version of the same image processed in 16 bit. You have info where the 8 bit did not.
This is one example. I process as 16 bit, work with colors, curves anso forth. I save a copy that way. Then I make an 8 bit (Image>Mode>8 Bit/Channel) and use the filters or what ever I need that I do not have in 16 Bit. Save that as an 8 Bit.
|
|
|
|
02/07/2007 04:30:28 PM · #5 |
Aren't most cameras 12bit to begin with? 2^12 = 4096. When saving as 16 bit, where do those extra 61,000 some odd levels come from?
BTW, the difference between 8 bit and 16 bit is not just half. 2^8 = 256 while 2^16 = 65,536
|
|
|
|
02/07/2007 04:37:23 PM · #6 |
Originally posted by Spazmo99:
Aren't most cameras 12bit to begin with? 2^12 = 4096. When saving as 16 bit, where do those extra 61,000 some odd levels come from?
BTW, the difference between 8 bit and 16 bit is not just half. 2^8 = 256 while 2^16 = 65,536 |
Spazmo thats the same as WHile a 3 Dial Brief Case Lock has 25% less dials then a 4 Dial Breifcase lock. The number of combinations is not 25% more its more around 10x. 3 dials can have a number up to 1000 000 to 999 and a 4 dial lock has 10000 combinations 0000-9999.
Im just saying anyoen that understands how that works understands why 16 bit provides more then just twice as many values. |
|
|
|
02/07/2007 04:47:48 PM · #7 |
Originally posted by Spazmo99:
Aren't most cameras 12bit to begin with? 2^12 = 4096. When saving as 16 bit, where do those extra 61,000 some odd levels come from?
BTW, the difference between 8 bit and 16 bit is not just half. 2^8 = 256 while 2^16 = 65,536 |
Most cams are 12-bit, at least in the DSLR world. Since it's by far easier for the camera to deal with even multiples of bytes (8 bits), at least two bytes (16 bits) are required to store the information for each channel. In practice, that means that the 12-bit data is mapped to a 16-bit space. 0=0, and 4096=65536, and everything in between is proportional. Obviously, there will be some empty values in the 16-bit space, but that's really of no consequence.
The nice thing about this scenario is that, as dynamic range of cameras improves, and we need higher bit depth, we have it available. Current DSLRs have at least 8 to 8.5 stops of DR, which is still less than the 12-bit DAC can accommodate, and certainly less than the 16-bit output space. Room to grow.
Message edited by author 2007-02-07 16:48:59. |
|
|
|
02/07/2007 04:51:12 PM · #8 |
Originally posted by Spazmo99:
Aren't most cameras 12bit to begin with? 2^12 = 4096. When saving as 16 bit, where do those extra 61,000 some odd levels come from?
BTW, the difference between 8 bit and 16 bit is not just half. 2^8 = 256 while 2^16 = 65,536 |
Most/many cameras have either 10 bit or 12 bit sensors.
The easiest way to think about it is as similar to decimal fractions.
Suppose you could go from 0 to 10
In the 8 bit case, that would be
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
Now, if you add more bits, you add more potential levels, but the range doesn't change. So for example 12 bit could add one decimal place.
Then you still go from 0 to 10, so
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 and so on
You can convert from one to the other, particularly going from 8 to 12 bit, without any problems. Those levels are all there. Going the other way requires rounding up or down.
16 bit would then be equivalent to adding even more levels in between
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 ... 10.0
Again you can see that going from the 12 bit file that had a value at level 0.5 to a 16 bit file would map straight to the 0.5
There's more precision added in, not any more data.
Where this becomes useful is if you make lots of small adjustments, where errors could accumulate in 8 bit, but in 16 bit there's more space to shuffle around without being forced to make large jumps, that introduce posterisation.
|
|
|
|
02/07/2007 05:03:33 PM · #9 |
Originally posted by Gordon:
Originally posted by Spazmo99:
Aren't most cameras 12bit to begin with? 2^12 = 4096. When saving as 16 bit, where do those extra 61,000 some odd levels come from?
BTW, the difference between 8 bit and 16 bit is not just half. 2^8 = 256 while 2^16 = 65,536 |
Most/many cameras have either 10 bit or 12 bit sensors.
The easiest way to think about it is as similar to decimal fractions.
Suppose you could go from 0 to 10
In the 8 bit case, that would be
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10
Now, if you add more bits, you add more potential levels, but the range doesn't change. So for example 12 bit could add one decimal place.
Then you still go from 0 to 10, so
0 0.5 1 1.5 2 2.5 3 3.5 4 4.5 and so on
You can convert from one to the other, particularly going from 8 to 12 bit, without any problems. Those levels are all there. Going the other way requires rounding up or down.
16 bit would then be equivalent to adding even more levels in between
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0 ... 10.0
Again you can see that going from the 12 bit file that had a value at level 0.5 to a 16 bit file would map straight to the 0.5
There's more precision added in, not any more data.
Where this becomes useful is if you make lots of small adjustments, where errors could accumulate in 8 bit, but in 16 bit there's more space to shuffle around without being forced to make large jumps, that introduce posterisation. |
Ok, that makes perfect sense. Thanks.
So, if you have level 0.6 in 16 bit, then it will be moved to 1 when converted to 8 bit along with anything that is in levels 0.5 to 1.4, right?
|
|
|
|
02/07/2007 05:09:25 PM · #10 |
Originally posted by Spazmo99:
So, if you have level 0.6 in 16 bit, then it will be moved to 1 when converted to 8 bit along with anything that is in levels 0.5 to 1.4, right? |
In the most trivial way of converting yes. Though that tends to cause nasty banding [ banding being the case where a smoothly increasing tone changes to one with a step-change across the tonal range - e.g., a smooth linear ramp rounded down and then up, looks like a step change - which spatially looks like banding). Dithering gets used to somewhat pertubate that, so that you don't tend to notice the banding so much. Don't have the specifics of a dithering algorithm here, but you could for example round up or down as you go through, rather than always round down, or randomly round up or down, or spatially randomly round up or down.
The point being that you don't force areas of close to constant tone all in one direction, then have a big 'switch' at 1.4 where everything jumps up in a smooth region. If you randomise that slightly, you'll tend to visually see a smoother transition, even though the absolute levels are still the same.
Message edited by author 2007-02-07 17:10:28.
|
|
|
|
02/07/2007 05:27:06 PM · #11 |
Gordon's illustration is informative; remember, though, that the levels are always integers. So, 12-bit data mapped linearly to a 16-bit space looks like this:
0 = 0
1 = 16
2 = 32
3 = 48
.
.
.
4096=65536
The left value is the 12-bit value, the right value is the 16-bit value. There will be no data at all initially mapped to 16-bit values of 1-15, for example. Once you start to edit, however, that can and will change. It's never problematic to have more levels available than required, but can be very problematic to have too few. As an example, here's what a linear mapping of a 16-bit space to an 8-bit space looks like:
000 to 255 = 0
256 to 511 = 1
512 to 767 = 2
.
.
.
65281 to 65535 = 255
Notice that all values from 0 to 255 in the 16-bit space become the same value, zero, in the 8-bit space. This is only true for linear mappings, but it is illustrative of just how much different the two are. |
|
|
|
02/07/2007 05:31:23 PM · #12 |
Originally posted by kirbic:
Gordon's illustration is informative; remember, though, that the levels are always integers. |
Though, just to confuse things a bit more, they aren't always treated that way. For example. photoshop treats 16 bit data as fractional for a lot of its dialog boxes (e.g., levels in 16 bit still uses 0 & 255 as the ends of the scale) and histograms are similarly translated.
All you really do there is lop off the least significant bits, which is why the fractional analogy works so well.
That's ignoring the fun of 32 bit floating point formats as well ;)
|
|
|
|
02/07/2007 05:36:21 PM · #13 |
Originally posted by Gordon:
All you really do there is lop off the least significant bits, which is why the fractional analogy works so well. |
True, dat.
Besides, very few Photoshop users are versed in binary math, and they are simply used to levels of 0-255. Giving them 0-65535 would just make for unnecessary confusion.
Message edited by author 2007-02-07 17:45:06. |
|
|
|
02/07/2007 05:43:24 PM · #14 |
Originally posted by kirbic:
True, dat.
Besides, very few Photoshop users are versed in binary math, and they are simply used to levels of 0-255. Giving them 0-65535 would just make for unnecessary confusion. |
Though I think it does give you them in some places, just to throw that unnecessary confusion back into the mix. (some of the info dialogs I think can be switched between 8 bit & 16 bit output)
|
|
|
|
Current Server Time: 04/19/2024 12:50:02 PM  |
Home -
Challenges -
Community -
League -
Photos -
Cameras -
Lenses -
Learn -
Prints! -
Help -
Terms of Use -
Privacy -
Top ^
DPChallenge, and website content and design, Copyright © 2001-2024 Challenging Technologies, LLC.
All digital photo copyrights belong to the photographers and may not be used without permission.
Current Server Time: 04/19/2024 12:50:02 PM EDT.
|
