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 |
#52
|
|||
|
|||
|
#53
|
|||
|
|||
wrote:
wrote: "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)"? A minor danger is that if IP is 0xffff, the above will map to 0 if done in 16b arithmetic. "IP 1" (M. Clarke's equation) is a single instruction that doesn't suffer from overflow problems. But if wider arithmetic is allowed, then: PS = rint(IP*(32768.0/65535.0)) or its integer equivalent may be used. Note that PhotoSlop is "just an image editor" (a large, complicated, extensible, useful one to be sure), so precise stuff like you are demanding will probably never make it high on the priority list at Adobe, where most of their users are graphic artists, not by-the-bit technician types. Can MaximDL and similar handle non-astronomical imagery? It's internals are probably _alot_ more formal (linear images, etc). Hello Is astronomical image processing done in a linear space or a gamma space? Mike Engles |
#54
|
|||
|
|||
wrote:
wrote: "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)"? A minor danger is that if IP is 0xffff, the above will map to 0 if done in 16b arithmetic. "IP 1" (M. Clarke's equation) is a single instruction that doesn't suffer from overflow problems. But if wider arithmetic is allowed, then: PS = rint(IP*(32768.0/65535.0)) or its integer equivalent may be used. Note that PhotoSlop is "just an image editor" (a large, complicated, extensible, useful one to be sure), so precise stuff like you are demanding will probably never make it high on the priority list at Adobe, where most of their users are graphic artists, not by-the-bit technician types. Can MaximDL and similar handle non-astronomical imagery? It's internals are probably _alot_ more formal (linear images, etc). Hello Is astronomical image processing done in a linear space or a gamma space? Mike Engles |
#55
|
|||
|
|||
In article , Mike Engles
writes Hello Is astronomical image processing done in a linear space or a gamma space? Normally in linear space, Mike - because you are primarily interested in physical quantities and their quantitative results. After that has been achieved, the representation for human consumption is created - either from the source data or the processed data depending on the objective required. -- Kennedy Yes, Socrates himself is particularly missed; A lovely little thinker, but a bugger when he's ****ed. Python Philosophers (replace 'nospam' with 'kennedym' when replying) |
#56
|
|||
|
|||
In article , Mike Engles
writes Hello Is astronomical image processing done in a linear space or a gamma space? Normally in linear space, Mike - because you are primarily interested in physical quantities and their quantitative results. After that has been achieved, the representation for human consumption is created - either from the source data or the processed data depending on the objective required. -- Kennedy Yes, Socrates himself is particularly missed; A lovely little thinker, but a bugger when he's ****ed. Python Philosophers (replace 'nospam' with 'kennedym' when replying) |
#57
|
|||
|
|||
In article ,
wrote: 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. We don't. Without your original data to test, I can't even guess what went wrong. But the 0..32768 representation will have to remain for the forseeable future (unless you have a modern processor that does integer divides just as fast as it does integer shifts). Chris |
#58
|
|||
|
|||
In article ,
wrote: 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. We don't. Without your original data to test, I can't even guess what went wrong. But the 0..32768 representation will have to remain for the forseeable future (unless you have a modern processor that does integer divides just as fast as it does integer shifts). Chris |
#59
|
|||
|
|||
In article , Toby
Thain wrote: wrote in message . .. In message , (Dave Martindale) wrote: writes: It's not obvious, though, when the missing values are 15-bit values. Rather than 32,769 values, there are only about 11,000 values. That is indeed very strange. I can't think of any reason the greyscale representation should be any different from one channel of an RGB image. Me neither. Just one of a series of many disappointments with PS. This happens, I've found, with any conversion to greyscale in "16-bit" mode. The color management is different for color and greyscale, too, so if you switch back and forth there may be a continual loss of accuracy. Someone should tell adobe that we have fast machines now and can work with accurate data. Photoshop is accurate, as far as we know. Without your original data to test, I don't know what might have gone wrong. But other people who are picky about their bits don't have any problems with Photoshop. I've tried. Their engineer insists that it's 30x faster to work with 15 bit quantities than 16 bit ones. Which is correct (for 0..32768 representation versus 0..65535 representation). Chris |
#60
|
|||
|
|||
In article , Toby
Thain wrote: wrote in message . .. In message , (Dave Martindale) wrote: writes: It's not obvious, though, when the missing values are 15-bit values. Rather than 32,769 values, there are only about 11,000 values. That is indeed very strange. I can't think of any reason the greyscale representation should be any different from one channel of an RGB image. Me neither. Just one of a series of many disappointments with PS. This happens, I've found, with any conversion to greyscale in "16-bit" mode. The color management is different for color and greyscale, too, so if you switch back and forth there may be a continual loss of accuracy. Someone should tell adobe that we have fast machines now and can work with accurate data. Photoshop is accurate, as far as we know. Without your original data to test, I don't know what might have gone wrong. But other people who are picky about their bits don't have any problems with Photoshop. I've tried. Their engineer insists that it's 30x faster to work with 15 bit quantities than 16 bit ones. Which is correct (for 0..32768 representation versus 0..65535 representation). Chris |
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 01: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 03:35 PM |