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 |
#81
|
|||
|
|||
Kennedy McEwen wrote:
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) Hello Is the same true for imaging from spacecraft, interplanetary or otherwise or is gamma encoding done before transmission? Mike Engles |
#83
|
|||
|
|||
I thought it was outer-space.
John "Mike Engles" wrote in message ... 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 |
#84
|
|||
|
|||
John Doe wrote:
I thought it was outer-space. John "Mike Engles" wrote in message ... 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 Hello Like one way or another, we're all, like, spaced out man. Mike Engles |
#85
|
|||
|
|||
John Doe wrote:
I thought it was outer-space. John "Mike Engles" wrote in message ... 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 Hello Like one way or another, we're all, like, spaced out man. Mike Engles |
#86
|
|||
|
|||
Dave Martindale wrote:
[re Photoshop's 16 bit representation] The Pixar Image Computer used tricks like this many years ago. The memory was 12 bits per component, with 2048 representing a value of 1.0. Values up to 3071 were brighter than white, up to 1.5. The range 3072-4095 represented negative values in [-0.5, 0]. When a 12-bit value was loaded into the processor, it was automatically extended to 16 bits in a way that preserved the positive or negative meaning, then the arithmetic was all 16/32 bit. Dave It did indeed, and I'm astonished that you remember these details so long after I, who worked on this stuff for years, have forgotten them! You touch on another important aspect of having displayable values occupy only a subset of the total 16 bits. This is the ability to represent negative intermediate values. Negative numbers are an important component of most graphic calculations, and the ability to represent negative values in place saves, storage, and the time required to convert between storage formats, while retaining the ability to make calculations that require per pixel negative values. An example would be the subtraction of two channels, or the Pirl function, which uses negative terms in calculating the theoretically perfect resampling filter. OTOH, Adobe's weird 16 bit format makes it more difficult to interface to other graphics libraries, requiring additional passes to convert to and from 16 bit mode. -- Mike Russell www.curvemeister.com www.geigy.2y.net |
#87
|
|||
|
|||
Mike Engles wrote:
.... [re linear encoding of specialized pixel data values] Is the same true for imaging from spacecraft, interplanetary or otherwise or is gamma encoding done before transmission? Yes. Gama encoding compresses some data values, and there is no reason to do this to raw data from a spacecraft. Here's an article that may interest you, by Alvy Ray Smith, on the distinction of work and display color spaces. http://alvyray.com/Memos/MemosMicros...rAlphaQuestion -- Mike Russell www.curvemeister.com www.geigy.2y.net |
#88
|
|||
|
|||
Mike Engles wrote:
.... [re linear encoding of specialized pixel data values] Is the same true for imaging from spacecraft, interplanetary or otherwise or is gamma encoding done before transmission? Yes. Gama encoding compresses some data values, and there is no reason to do this to raw data from a spacecraft. Here's an article that may interest you, by Alvy Ray Smith, on the distinction of work and display color spaces. http://alvyray.com/Memos/MemosMicros...rAlphaQuestion -- Mike Russell www.curvemeister.com www.geigy.2y.net |
#89
|
|||
|
|||
In article ,
wrote: In message , Chris Cox wrote: Without your original data to test, I can't even guess what went wrong. You don't need my original data. Any image in "16 bit greyscale" mode has all kinds of numbers between 0 and 32768 missing, Only if you started with an image that had numbers missing. The representation is 0..32768 -- all numbers are possible. and not possible no matter hown much you blur or interpolate. "16 bit greyscale" is about 13.5 bit greyscale. No, that is not even remotely correct. Chris |
#90
|
|||
|
|||
In article , Matt Austern
wrote: Chris Cox writes: 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). Perhaps this is offtopic, and perhaps you can't answer it without revealing proprietary information, but can you explain why 15-bit computation should be so much faster than 16-bit? (If there's a publication somewhere you could point me to, that would be great.) I've thought about this for a few minutes, I haven't been able to think of an obvious reason, and now I'm curious. 1) Because a shift by 15 (divide by 32768) is much faster than a divide by 65535. One of the most common operations is (value1*value2 + (maxValue/2)) / maxValue With 0..255 we can pull some tricks to make the divide reasonably fast. For 0..65535 the tricks take quite a bit more time (and serialize the operation), or we have to use a multiply by reciprocal For 0..32768, we can just use a shift. 2) A lot fewer overflows of 32 bit accumulators This is still a problem. When 64 bit processors become the norm (and the @#!^&$ OS allows a fully 64 bit application), then that becomes less of a problem. 3) The 2^N maximum value also has some benefits when dealing with subsampled lookup tables that require interpolation. 4) the 2^N maximum value also has benefits to blending operations that need a middle value (for 0..255 it was pretty random whether 127 or 128 was used for the middle). 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 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 |