Posted by
Kenneth R Sloan on
Jun 05, 2015; 2:59pm
URL: http://imagej.273.s1.nabble.com/backward-recreatoin-of-an-lut-tp5013041p5013053.html
Here’s what *I* would do, assuming that dithering is not acceptable.
a) cluster the RGB pixel values from the original image - aim for around 240-256 clusters
b) assign a prototype color to each cluster
c) assign the cluster NUMBER to each pixel belonging to the cluster
d) construct a LUT that maps cluster numbers to the prototype colors for the clusters
This will produce a non-sensical gray-scale image (the values are just cluster numbers, not intensity values.
If this is not acceptable (that is, you actually want a gray-scale image that looks reasonable), you might sort the clusters by the intensity of the prototype colors. This would properly ORDER the gray levels, but not in anything resembling a linear ramp.
I’m guessing that this last step is not really necessary. Which is a good thing, because I’m not sure how well it would work, in general.
Note that if you want to DISPLAY a gray-level image, that can be done with a second LUT.
If dithering is acceptable, then you don’t necessarily want your 256 colors to be the prototypes of 256 clusters of RGB values. You want colors that can be blended to give you the full gamut of perceived colors, while still using only 8 bits per pixel. This calls for a mixture of distributing colors over the entire RGB cube - and perhaps slightly tweaking each color towards the prototype colors found by clustering. Again - you will have an 8-bit image of codes, interpreted by the LUT to 256 colors in your pallette, and further processed by the display and the viewer’s visual system to spatially average local neighborhoods. Good for LOOKING at the picture - perhaps not so good for machine analysis of the images.
Good luck! This is a very interesting problem - the right solution depends on what kind of images you have and what information you need to preserve as you compress to 8bits per pixel.
--
Kenneth Sloan
[hidden email]
Vision is the art of seeing what is invisible to others.
> On Jun 5, 2015, at 06:25 , Kenneth R Sloan <
[hidden email]> wrote:
>
> there was work in the early 80s on rendering images using a restricted set of colors (specifically for frame buffers with 8bits per pixel and a hardware 8->12bits Video Lookup Table. This was often combined with dithering. See, for example , a paper by Paul Heckbert at SIGGRAPH.
>
> These techniques might help.
>
> question: do you require the 8bit image to be a reasonable gray scale rendition of the image, or can the 8bit values be arbitrary?
>
> -Kenneth Sloan
> (von meinem iPhone5S gesendet)
>
>> On Jun 5, 2015, at 04:29, Gabriel Landini <
[hidden email]> wrote:
>>
>>> On Thursday 04 Jun 2015 21:33:12 rustyconc wrote:
>>> Is there an easy way to convert the data RGB image to 8 bit gray scale so
>>> that the colour scaling in the color scale image is preserved?
>>
>> You could use the color inspector 3D plugin to investigate this.
>>
>> The map of one image I loaded has 17187 colours, and the colour scale has 458.
>> Most likely there is some smoothing going on at the edges of continents,
>> unmapped regions and the superimposed grid which end up blending with the data
>> and generating non-LUT colours which need to be dealt with.
>>
>> I think it will be difficult to know what is going on in the images with any
>> certainty and it would be better use the original data, if available.
>>
>> Cheers
>>
>> Gabriel
>>
>> --
>> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html>
> --
> ImageJ mailing list:
http://imagej.nih.gov/ij/list.html--
ImageJ mailing list:
http://imagej.nih.gov/ij/list.html