my 16 bit 'gray' RGB keeps becomon 8Bit Grayscale

[Howie L]

Hi,

I am trying to do some pixel math for a simple astronomy application.

I want to convert a mono16 bit image into a RGB 16bit image that I can use in pixel math as trichro 16bit gray

convert mono.tif mono.tif mono.tif -combine trichoroGray.tif

mono.tif is 16bit,
trichroGray.tif is alwasy mono 8bit grayscale

How do I get trichroGray.tif to be rgb with 16big channels

Right now I can do it if I offset the channels by 1 so they are not exact duplicates

convert mono.tif mono.tif -evaluate add 1 mono.tif -evaluate add -1 -combine trichoroGray.tif

Is there a better way

Thanks,
Howie

[fmw42]

what version of IM and what platform? can you upload your input image to dropbox.com (public folder) or some other free service that will not change the format and put a link here so others can test with it?

Single channel grayscale images in IM are really 3 channels, but labelled as gray. So if you combine 3 grayscale channels together, you end up with still the same image. I do not think you can force it to be type truecolor rather than gray, unless you change a pixel.

If I try to create a grayscale gradient and save to tiff in IM 6.8.9.2 Q16 Mac OSX, it comes back as 16/8-bit, though the data range is 16-bit (0 to 65535)


convert -size 256x256 gradient: -depth 16 grad.tiff

identify -verbose grad.tiff

Image: grad.tiff
Format: TIFF (Tagged Image File Format)
Mime type: image/tiff
Class: DirectClass
Geometry: 256x256+0+0
Units: PixelsPerInch
Type: Grayscale
Base type: Grayscale
Endianess: MSB
Colorspace: Gray
Depth: 16/8-bit
Channel depth:
gray: 8-bit
Channel statistics:
Gray:
min: 0 (0)
max: 65535 (1)
mean: 32767.5 (0.5)
standard deviation: 18992.4 (0.289805)
kurtosis: -1.20004
skewness: 1.26355e-12

[Howie L]

Hi,

The version is ImageMagick 6.8.9 Q16 (32-bit)

Ok if i take your example, and try and build a RGB out of it

convert -size 256x256 gradient: -depth 16 grad.tiff

convert grad.tiff grad.tiff grad.tiff -combine aRGB.tif

convert grad.tiff grad.tiff -evaluate ADD 1 grad.tiff -evaluate ADD 2 -combine bRGB.tif

Info gives
aRGB.tif TIFF 256x256 256x256+0+0 16-bit Grayscale Gray 0.000u 0:00.000

bRGB.tif TIFF 256x256 256x256+0+0 16-bit TrueColor sRGB 0.016u 0:00.015

I was looking for something at the end of the command to force it to sRGB like ... -
.... -combine -set colorspace sRGB (this didnt seem to work )
is there anything that would do it besides changing a pixel.

But changing a pixel in each channel would work for me, would be harmless in my application,
( my method above would go back to GrayScale when I rebalanced the color channels which was causing problems)

Thank Your for you Help, it is much appreciated

Regards,
Howie

[snibgo]

"-type Truecolor" works for me, to give the output file 3 channels. Don't use "identify" to find how many channels a file has.

As Fred says, "convert grad.tiff grad.tiff grad.tiff -combine aRGB.tif" should have no effect if grad.tiff doesn't have any colour. If it does have colour and you want to make it gray, there are better (quicker and more controllable) ways.

[fmw42]

If I add -type truecolor, it makes no difference to identify as user snibgo said. It still shows as type grayscale.

convert -size 256x256 gradient: -depth 16 -type truecolor grad.tiff

Image: grad.tiff
Format: TIFF (Tagged Image File Format)
Mime type: image/tiff
Class: DirectClass
Geometry: 256x256+0+0
Units: PixelsPerInch
Type: Grayscale
Base type: Grayscale
Endianess: MSB
Colorspace: Gray
Depth: 16/8-bit
Channel depth:
gray: 8-bit
Channel statistics:
Gray:
min: 0 (0)
max: 65535 (1)
mean: 32767.5 (0.5)
standard deviation: 18992.4 (0.289805)
kurtosis: -1.20004
skewness: 1.26355e-12


However, if I use EXIFTOOL, with the image above (-type truecolor), it shows

exiftool -s -ee -g1 -u -n -D grad.tiff
---- ExifTool ----
- ExifToolVersion : 8.71
---- System ----
- FileName : grad.tiff
- Directory : .
- FileSize : 393896
- FileModifyDate : 2014:05:31 20:29:42-07:00
- FilePermissions : 644
---- File ----
- FileType : TIFF
- MIMEType : image/tiff
- ExifByteOrder : II
---- IFD0 ----
256 ImageWidth : 256
257 ImageHeight : 256
258 BitsPerSample : 16 16 16
259 Compression : 1
262 PhotometricInterpretation : 2
266 FillOrder : 1
273 StripOffsets : (Binary data 344 bytes, use -b option to extract)
274 Orientation : 1
277 SamplesPerPixel : 3
278 RowsPerStrip : 5
279 StripByteCounts : (Binary data 259 bytes, use -b option to extract)
284 PlanarConfiguration : 1
297 PageNumber : 0 1
318 WhitePoint : 0.3127000035 0.3289999963
319 PrimaryChromaticities : 0.6399999858 0.3300000132 0.300000012 0.600000024 0.150000006 0.05999999867
---- Composite ----
- ImageSize : 256x256

PhotometricInterpretation=2 means RGB and 16 16 16 for BitsPerSample would indicate 3 channels with 16 bits per channel.

If I leave off the -type truecolor, then I get grayscale (PhotometricInterpretation=1 and BitsPerSample=16).

So snibgo, is right. IM identify -verbose is often misleading (regarding grayscale vs truecolor). Best to use EXIFTOOL or something like that.


see
http://www.awaresystems.be/imaging/tiff ... eline.html
http://www.sno.phy.queensu.ca/~phil/exiftool/

[Howie L]

Hi Snibgo,

That seems to work also,.. and my other programs are opening the file correctly and seeing the RGB and the correct color depth.

While I am bothering you...
I have another problem.

Lets say I want to correct a gradient in a picture ( usually this would be a lens gradient for my application)
but lets say it is the gradient in the above example.
I would want to do a divide of the original image by the above gradient.
It would have to be a 'normalized' divide
does this exist ?

( i forgot what I was trying but it may have been something like -evaluate-sequence divide )

Other math functions like 'add' were ok, but the divide kind of flattens out most of the data to near 1
because at a pixel level, you can see say one pix is 8000 another is 7000 you do 8000/7000 and
and get 1.1????or something.. which makes a image full if pixels with a value of one. There should be a normalize value to expand it back up when the math is done, while you still the numerical precision.

Is the a divide for between 2 images that normalizes the data back up to a certain given level ?

Thanks,
Howie

[fmw42]

I am not sure what you mean by normalize. But the usual way to correct an image for some background shading issue is to do a divide using -compose divide

Code: Select all

convert image1 image2 +swap -compose divide -composite result

The above does image1/image2. Note the +swap due to the way compose operates on two images. You can just do

Code: Select all

convert image2 image1 -compose divide -composite result

to get the same result.

See
http://www.imagemagick.org/Usage/compose/#divide

If you need to stretch the denominator image to full dynamic range before dividing, then use -auto-level.

Code: Select all

convert image1 \( image2 -auto-level \) +swap -compose divide -composite result

[snibgo]

... say one pix is 8000 another is 7000 you do 8000/7000 and and get 1.1????or something.. which makes a image full if pixels with a value of one.

With integer IM, divide 8000/7000 and you get Quantum * 1.0, ie it clamps the value at Quantum (eg 2^16-1). With floating point (HDRI), you get Quantum * 1.14286. You might then divide all the pixels by the largest value, if you want, before writing the image.

With integer IM, you can't "expand it back up when the math is done" because the correct value has vanished. In 16-bit arithmetic, there is no value above 2^16-1.

[fmw42]

You can preserve floating point accuracy by compiling IM in HDRI mode (Q16 is fine). But you need to use image formats that support floats, such as PFM, MIFF, TIFF, but the latter two need to have the quantum:format set. See

http://www.imagemagick.org/script/high- ... -range.php
http://www.imagemagick.org/script/formats.php (notes in Miff and Tiff sections)