PhotoBanter.com

PhotoBanter.com (http://www.photobanter.com/index.php)
-   Digital Photography (http://www.photobanter.com/forumdisplay.php?f=5)
-   -   "16-bit" mode. (http://www.photobanter.com/showthread.php?t=19356)

[email protected] November 17th 04 02:33 AM

In message ,
wrote:

Kibo informs me that
stated that:

In message ,
wrote:

What format are you using to store your artificial data?


A binary file of 2-byte unsigned integers from 0 to 65535, loaded as
.raw.


Got any data on that format? You've gotten me interested enough in this
question to want to try a few experiments myself. ;)


I just wrote an applet in C that stripped the RAW data out of
uncompressed .dng files and multiplied them by 16 so that there wouldn't
be any quantization (the .dng files use the numbers 0 to 4095 in 16-bit
space) . I modified it slightly to create a string of 65536 2-byte
integers, 0 to 65535, and loaded it into PS as a 256*256 16-bit
greyscale bitmap. I placed the "Info" cursor over it, and got those
values.
--


John P Sheehy


[email protected] November 17th 04 02:36 AM

In message ,
(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. 6 sequential 16-bit values become one "PS
16-bit" value (except for the highest and lowest values, which are 3 to
1).

I think its time for Adobe to realize that people have fast machines,
and that they need to stop cutting corners on quality for speed.
--


John P Sheehy


[email protected] November 17th 04 02:36 AM

In message ,
(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. 6 sequential 16-bit values become one "PS
16-bit" value (except for the highest and lowest values, which are 3 to
1).

I think its time for Adobe to realize that people have fast machines,
and that they need to stop cutting corners on quality for speed.
--


John P Sheehy


MArtin Chiselwitt November 17th 04 02:42 AM

what the hell are you talking about?!!! :(

MArtin Chiselwitt November 17th 04 02:42 AM

what the hell are you talking about?!!! :(

Roger N. Clark (change username to rnclark) November 17th 04 02:48 AM

wrote:

In message ,
real
16-bit PS values
data

0 0
1 0
2 0
3 3
4 3
5 3
6 3
7 3
8 3
9 5

32764 19128
32765 19131
32766 19131
32767 19131
32768 19131
32769 19131
32770 19131
32771 19134
32772 19134

65525 32762
65526 32762
65527 32766
65528 32766
65529 32766
65530 32766
65531 32766
65532 32766
65533 32768
65534 32768
65535 32768

In my testing of photoshop on real images, I find the following
equation:

PS = int(IP/2),

where PS = the photoshop "16-bit" value and
IP = the 16-bit output from ImagesPlus.

Roger


Roger N. Clark (change username to rnclark) November 17th 04 02:48 AM

wrote:

In message ,
real
16-bit PS values
data

0 0
1 0
2 0
3 3
4 3
5 3
6 3
7 3
8 3
9 5

32764 19128
32765 19131
32766 19131
32767 19131
32768 19131
32769 19131
32770 19131
32771 19134
32772 19134

65525 32762
65526 32762
65527 32766
65528 32766
65529 32766
65530 32766
65531 32766
65532 32766
65533 32768
65534 32768
65535 32768

In my testing of photoshop on real images, I find the following
equation:

PS = int(IP/2),

where PS = the photoshop "16-bit" value and
IP = the 16-bit output from ImagesPlus.

Roger


Bart van der Wolf November 17th 04 02:27 PM


"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

Bart


Bart van der Wolf November 17th 04 02:27 PM


"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

Bart


[email protected] November 17th 04 05:32 PM

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.


All times are GMT +1. The time now is 11:29 PM.

Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
PhotoBanter.com