backward recreatoin of an lut

[rustyconc]

Hi,

I am trying to do a quick analysis of satellite data available from NASA here:
http://oceancolor.gsfc.nasa.gov/cgi/l3

For example, this thumbnail (for quick download):
http://oceancolor.gsfc.nasa.gov/cgi/l3/V20142742014304.L3m_MO_NPP_CHL_chlor_a_4km.nc.ico.png?sub=img&novl=1

The problem is the available image format is PNG, which imports into imagej as an RGB.  However, the images are false-colored, according to a LUT provided in another PNG image:
http://oceancolor.gsfc.nasa.gov/images/NPP_CHL_chlor_a_colorscale.png

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?

Disclaimer re alternatives:  I know there are other portals to access this data, and I'm going about it backwards: delving into NASA's system would allow direct download of the data.  However, the complexity sky-rockets (likely involving Matlab to handle hdf files) and the monthly PNG images are exactly what I need to work with, and this portal provides the highest resolution available.

Thanks
Russell

[Gabriel Landini]

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

[Kenneth R Sloan]

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

[Kenneth R Sloan]

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

[Michael Schmid]

Hi Russell,

you could try the macro below. Select the calibration bar as exactly as
you can with the Rectangle tool, then run the macro.

Michael
_______________________________________________________________________

/** Select a calibration bar and convert it to a LUT, which gets stored
 *  in the ImageJ/LUTS directory */
macro "Calibration Bar to LUT" {
  if (bitDepth() != 24)
    exit("RGB image required");
  if (selectionType() != 0)
    exit("Error:\nCalibration bar must be selected with the Rectangle Tool");
  run("Duplicate...", "title=scaleBar-tmp");
  selectWindow("scaleBar-tmp");
  if (getHeight() > getWidth())
    run("Rotate 90 Degrees Right");
  run("Size...", "width=256 height=1 average interpolation=Bilinear");
  makeRectangle(0, 0, 3, 1);
  getStatistics(area, meanLeft);
  makeRectangle(253, 0, 3, 1);
  getStatistics(area, meanRight);
  run("Select None");
  if (meanLeft-100 >meanRight)
    run("Flip Horizontally", "stack");
  tmpID = getImageID();
  run("RGB Stack");
  filename = getString("Name for the LUT", "");
  if (! endsWith(filename, ".lut"))
    filename = filename + ".lut";
  path = getDirectory("luts")+filename;
  saveAs("Raw Data", path);
  selectImage(tmpID);
  close();
}


_______________________________________________________________________



On Fri, June 5, 2015 06:33, rustyconc wrote:

> Hi,
>
> I am trying to do a quick analysis of satellite data available from NASA
> here:
> http://oceancolor.gsfc.nasa.gov/cgi/l3
>
> For example, this thumbnail (for quick download):
> http://oceancolor.gsfc.nasa.gov/cgi/l3/V20142742014304.L3m_MO_NPP_CHL_chlor_a_4km.nc.ico.png?sub=img&novl=1
>
> The problem is the available image format is PNG, which imports into
> imagej
> as an RGB.  However, the images are false-colored, according to a LUT
> provided in another PNG image:
> http://oceancolor.gsfc.nasa.gov/images/NPP_CHL_chlor_a_colorscale.png
>
> 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?
>
> Disclaimer re alternatives:  I know there are other portals to access this
> data, and I'm going about it backwards: delving into NASA's system would
> allow direct download of the data.  However, the complexity sky-rockets
> (likely involving Matlab to handle hdf files) and the monthly PNG images
> are
> exactly what I need to work with, and this portal provides the highest
> resolution available.
>
> Thanks
> Russell
>
>
>
>
>
>
>
> --
> View this message in context:
> http://imagej.1557.x6.nabble.com/backward-recreatoin-of-an-lut-tp5013041.html
> Sent from the ImageJ mailing list archive at Nabble.com.
>
> --
> ImageJ mailing list: http://imagej.nih.gov/ij/list.html
>

--
ImageJ mailing list: http://imagej.nih.gov/ij/list.html

[rustyconc]

Thanks to all that replied.  The simplest solution, which I followed, was to take advantage of the HDF5 plugin I was not previously aware of:

http://lmb.informatik.uni-freiburg.de/resources/opensource/imagej_plugins/hdf5.html

This, with a custom xy import, allows the original data to be easily loaded into ImageJ.

Best regards,
Russell