If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#32
|
|||
|
|||
In message ,
wrote: wrote: (Mitch Alsup) wrote: This looks like somebody is applying the gamma correction to the RAW data ouptut = input**2.2 / some-fixed-scaling No; it's totally linear. Form your own table: 32764/19128 = 1.713 65525/32762 = 2.000 So it isn't exactly linear. From these two points (essentially all you posted) it looks like there is a gamma-esque hump in the transfer function. You should fetch gnuplot or a similar plotting tool and plot the entire "real" vs "photoslop" correspondance you obtained. Yes, you're right; it isn't perfectly linear, due to color management. It is almost linear (gamma close to 1), but that isn't the most disturbing problem. The problem is that the data is severely posterized. Even with color management disabled, this only happens with greyscale; 16-bit RGB bitmaps transfer very simply; they are psvalue=int((inputvalue+1)/2)). Greyscale only uses 1/3 as many levels as RGB; 6 input values become 1 PS value, as opposed to 2 becoming 1. -- John P Sheehy |
#33
|
|||
|
|||
In message ,
wrote: wrote: (Mitch Alsup) wrote: This looks like somebody is applying the gamma correction to the RAW data ouptut = input**2.2 / some-fixed-scaling No; it's totally linear. Form your own table: 32764/19128 = 1.713 65525/32762 = 2.000 So it isn't exactly linear. From these two points (essentially all you posted) it looks like there is a gamma-esque hump in the transfer function. You should fetch gnuplot or a similar plotting tool and plot the entire "real" vs "photoslop" correspondance you obtained. Yes, you're right; it isn't perfectly linear, due to color management. It is almost linear (gamma close to 1), but that isn't the most disturbing problem. The problem is that the data is severely posterized. Even with color management disabled, this only happens with greyscale; 16-bit RGB bitmaps transfer very simply; they are psvalue=int((inputvalue+1)/2)). Greyscale only uses 1/3 as many levels as RGB; 6 input values become 1 PS value, as opposed to 2 becoming 1. -- John P Sheehy |
#34
|
|||
|
|||
In message ,
"Bart van der Wolf" wrote: "Mike Engles" wrote in message ... SNIP There was a discussion about this kind of thing on the scanner group, comp.periphs.scanner. Post your observation there. You might get a explanation. You probably are referring to these: 1. Chris Cox's 'explanation' of the internal format of 15bits+1: http://groups.google.nl/groups?selm=...25ccox%40minds pring.com&output=gplain 2. The way Photoshop converts (16-bits to 8-bits) http://groups.google.com/groups?selm...%25ccox%40mind spring.com&output=gplain The slight gamma turned out to be from color management, but what I am talking about appears to be slightly different from what is discussed in the 15-bit + 1, or 16-8-bit discussions. 16-bit greyscale is highly posterized. With color management turned off, the count starts: 0 0 0 1 1 1 1 1 1 3 3 3 3 3 3 ... Where is 2? You can't be skipping numbers while others are being repeated multiple times; that makes no sense whatsoever. The sad fact of the matter is that not only is PS' "16-bit" RGB only 15-bit, but its "16-bit" greyscale has even less effective bits. Even if you perform a bicubic upsampling, you can't get the missing values. -- John P Sheehy |
#35
|
|||
|
|||
In message ,
"Bart van der Wolf" wrote: "Mike Engles" wrote in message ... SNIP There was a discussion about this kind of thing on the scanner group, comp.periphs.scanner. Post your observation there. You might get a explanation. You probably are referring to these: 1. Chris Cox's 'explanation' of the internal format of 15bits+1: http://groups.google.nl/groups?selm=...25ccox%40minds pring.com&output=gplain 2. The way Photoshop converts (16-bits to 8-bits) http://groups.google.com/groups?selm...%25ccox%40mind spring.com&output=gplain The slight gamma turned out to be from color management, but what I am talking about appears to be slightly different from what is discussed in the 15-bit + 1, or 16-8-bit discussions. 16-bit greyscale is highly posterized. With color management turned off, the count starts: 0 0 0 1 1 1 1 1 1 3 3 3 3 3 3 ... Where is 2? You can't be skipping numbers while others are being repeated multiple times; that makes no sense whatsoever. The sad fact of the matter is that not only is PS' "16-bit" RGB only 15-bit, but its "16-bit" greyscale has even less effective bits. Even if you perform a bicubic upsampling, you can't get the missing values. -- John P Sheehy |
#36
|
|||
|
|||
In message ,
"Roger N. Clark (change username to rnclark)" wrote: In my testing of photoshop on real images, I find the following equation: PS = int(IP/2), Are you sure it isn't "PS = int((IP+1)/2)"? where PS = the photoshop "16-bit" value and IP = the 16-bit output from ImagesPlus. -- John P Sheehy |
#37
|
|||
|
|||
In message ,
"Roger N. Clark (change username to rnclark)" wrote: In my testing of photoshop on real images, I find the following equation: PS = int(IP/2), Are you sure it isn't "PS = int((IP+1)/2)"? where PS = the photoshop "16-bit" value and IP = the 16-bit output from ImagesPlus. -- John P Sheehy |
#38
|
|||
|
|||
wrote:
In message , "Bart van der Wolf" wrote: "Mike Engles" wrote in message ... SNIP There was a discussion about this kind of thing on the scanner group, comp.periphs.scanner. Post your observation there. You might get a explanation. You probably are referring to these: 1. Chris Cox's 'explanation' of the internal format of 15bits+1: http://groups.google.nl/groups?selm=...25ccox%40minds pring.com&output=gplain 2. The way Photoshop converts (16-bits to 8-bits) http://groups.google.com/groups?selm...%25ccox%40mind spring.com&output=gplain The slight gamma turned out to be from color management, but what I am talking about appears to be slightly different from what is discussed in the 15-bit + 1, or 16-8-bit discussions. 16-bit greyscale is highly posterized. With color management turned off, the count starts: 0 0 0 1 1 1 1 1 1 3 3 3 3 3 3 ... Where is 2? You can't be skipping numbers while others are being repeated multiple times; that makes no sense whatsoever. The sad fact of the matter is that not only is PS' "16-bit" RGB only 15-bit, but its "16-bit" greyscale has even less effective bits. Even if you perform a bicubic upsampling, you can't get the missing values. John: Can you send me your 256*256 raw file? I'll take a look at it with my tools, including some custom image processing unix programs and compare to photoshop and ImagesPlus. Roger |
#39
|
|||
|
|||
wrote:
In message , "Bart van der Wolf" wrote: "Mike Engles" wrote in message ... SNIP There was a discussion about this kind of thing on the scanner group, comp.periphs.scanner. Post your observation there. You might get a explanation. You probably are referring to these: 1. Chris Cox's 'explanation' of the internal format of 15bits+1: http://groups.google.nl/groups?selm=...25ccox%40minds pring.com&output=gplain 2. The way Photoshop converts (16-bits to 8-bits) http://groups.google.com/groups?selm...%25ccox%40mind spring.com&output=gplain The slight gamma turned out to be from color management, but what I am talking about appears to be slightly different from what is discussed in the 15-bit + 1, or 16-8-bit discussions. 16-bit greyscale is highly posterized. With color management turned off, the count starts: 0 0 0 1 1 1 1 1 1 3 3 3 3 3 3 ... Where is 2? You can't be skipping numbers while others are being repeated multiple times; that makes no sense whatsoever. The sad fact of the matter is that not only is PS' "16-bit" RGB only 15-bit, but its "16-bit" greyscale has even less effective bits. Even if you perform a bicubic upsampling, you can't get the missing values. John: Can you send me your 256*256 raw file? I'll take a look at it with my tools, including some custom image processing unix programs and compare to photoshop and ImagesPlus. Roger |
#40
|
|||
|
|||
|
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Sony Cybershot P100 VX '640x480' movie mode is fake | Mark Elkington | Digital Photography | 17 | November 2nd 04 02:24 AM |
What's the D300's "Close-up mode" for? | Darryl | Digital Photography | 10 | September 23rd 04 05:11 PM |
Q-Confused about which picture record mode to use in a digital camera. | Mr. Rather B. Beachen | Digital Photography | 1 | July 13th 04 01:50 AM |
What image quality mode to use? | Mr. Rather B. Beachen | Digital Photography | 2 | July 13th 04 01:21 AM |
wireless 550EX in manual mode with 420EX | danny | Other Photographic Equipment | 1 | February 15th 04 04:35 PM |