|
|
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 |
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 |
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 |
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 |
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 |
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 |
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 |
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 |
|
| All times are GMT +1. The time now is 02:10 PM. |
Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
PhotoBanter.com