Output not in sRGB format

Dear All,

I’m looking - but still can’t find :frowning: - the solution for the following problem:
For a scientific project - cluster identification - I need to process a bunch of TIFF images. I wrote a C-code which works but only for 8-bit grayscale pictures. (I mean 1 byte per pixel.) With gmic, the pre-analyzis (basically edge detection) can be done perfectly using this code line:
gmic input input.tif -jeje_normalize_local_variance 31.5,4.5,15.41,1,0,0 -fx_thin_edges[0] 0,18.5,0,100,100 -o Test.bmp,
but this line saves the output always in RGB format. Is it any possibilty to force the gmic to define the output as an uncompressed grayscale image?

Best regads, Fiser

Hi @Fiser.PhD, and welcome,

Would this help: G'MIC - GREYC's Magic for Image Computing: A Full-Featured Open-Source Framework for Image Processing - Reference Documentation - to_gray ?

Have fun!
Claes in Lund, Sweden

Dear Claes,

Tried it, it works - sure - but it keeps the number of channels. So the result of the output is still 24-bit RGB … :slight_smile:

Cheers, F.

Not in .bmp format. I’m not even sure .bmp supports grayscale images.
You may use the .pgm or .png formats to store grayscale images.

Welcome to the board! luminance is your friend:

$ gmic sample flower,256 print. luminance. print.
[gmic]-0./ Start G'MIC interpreter.
[gmic]-1./ Input sample image 'flower' (1 image 256x240x1x3).
[gmic]-1./ Print image [0] = 'flower'.
[0] = 'flower':
  size = (256,240,1,3) [720 Kio of floats]. <-- # three channels of RGB data 
  data = (17,15,13,11,12,10,12,12,10,10,10,10,(...),1,1,1,1,2,2,2,2,2,2,2,2).
  min = 1, max = 254, mean = 103.994, std = 84.3464, coords_min = (32,0,0,2), coords_max = (138,13,0,0).
[gmic]-1./ Compute luminance of image [0].
[gmic]-1./ Print image [0] = 'flower'.
[0] = 'flower':
  size = (256,240,1,1) [240 Kio of floats]. <-- # one channel of gray data
  data = (27.3985,24.6241,21.8751,19.122,19.2758,18.976,18.4777,18.4777,18.1673,17.3626,18.1673,17.3626,(...),7.62518,8.34209,7.62518,7.62518,11.1498,11.1498,11.1498,11.9446,11.9446,12.7448,12.7448,11.1498).
  min = 5.25198, max = 244.662, mean = 126.078, std = 69.6529, coords_min = (43,0,0,0), coords_max = (182,30,0,0).
[gmic]-1./ End G'MIC interpreter.

-to_gray serves as well, but is a wrapper for -luminance that does some upfront sanity checking as well.
See the luminance tutorial for background.

However, here:

$ gmic sample flower -jeje_normalize_local_variance 31.5,4.5,15.41,1,0,0 -fx_thin_edges[0] 0,18.5,0,100,100 
[gmic]-0./ Start G'MIC interpreter.
[gmic]-1./ Input sample image 'flower' (1 image 640x600x1x3). <-- three channels here
[gmic]-1./ Display image [0] = 'flower'.
[0] = 'flower':
  size = (640,600,1,1) [1500 Kio of floats]. <-- Single channel here
  data = (255,255,255,255,255,255,255,255,255,255,255,255,(...),255,255,255,255,255,255,255,255,255,255,255,255).
  min = 0, max = 255, mean = 235.965, std = 67.02, coords_min = (375,0,0,0), coords_max = (0,0,0,0).

also produces an output image with only has one channel:
image
So, I’m a bit mystified on how you may be obtaining RGB output with this code…

1 Like

It sounds a good idea! :slight_smile:

Hi,

Thanks for the idea … I tried it. Please check the output file too … the output not an 8 bit image, it’s a 24 bit image! Both the luminance and the to_gray act a similar way.

Cheers, Z.

G’MIC always saves images in 24 bits RGB[A], there is no way to output an indexed image format. For this task, nobody can beat ImageMagick probably.

Ah! -o Test.bmp is the culprit! Though the image is one channel on G’MIC’s image list (as desired), upon conversion to .bmp in outputting the file, it converts back to three channel RGB. I think @David_Tschumperle may be right. .bmp does not have the concept of GRAY (or GRAYA).

I was looking for a simple solution in the frame of the gmic, because in the Gimp you can just switch to grayscale and save the image … I though that I’m completely blind not to find the right - and trivial - solution!
Otherwise the conversion with ImageMagick also not trivial. It could save the picture 24-bit and 1 bit (black & white) format. And my wish is missing … :smiley:

Yep! It would be nice to save an image e.g. layer-by-layer or just force the output to 8 bit format.

With gimp, I get three identical planes (24 bpp) with a grayscale bitmap. How married are you to .bmp? You have a downstream C program, no? Can you teach it about 3 redundant .BMP planes, and just use the first?
Some more background:
What is the BMP format for Gray scale Images?

It is exactly what I’m doing now … but reviewing a 1000 lines of code is not my favorite activity … :pensive:

So? How married are you to .bmp?
You have, just before output off G’MIC’s image pipeline, exactly what you want. At least two non-corrupting formats, G’MIC’s own .cimg and Portable Network Graphics .png write out one GRAY image plane and read back in one GRAY plane, both 8 bpp. With BMP, G’MIC tries to write out a one plane GRAY, but what lands onto disk is a 3 plane (all identical), file; when G’MIC reads it back in, it pulls in three planes. Gory details:

gosgood@bertha ~ $ gmic  i test.bmp [0] -jeje_normalize_local_variance 31.5,4.5,15.41,1,0,0 -fx_thin_edges[0] 0,18.5,0,100,100 o[0] test_out_too.cimg
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ Input file 'test.bmp' at position 0 (1 image 256x240x1x3).
[gmic]-1./ Input copy of image [0] at position 1 (1 image 256x240x1x3).
[gmic]-2./ Output image [0] as cimg file 'test_out_too.cimg', with pixel type 'auto'.
[gmic]-2./ End G'MIC interpreter.
gosgood@bertha ~ $ gmic test_out_too.cimg
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ Input file 'test_out_too.cimg' at position 0 (1 image 256x240x1x1). # <-- one 8 bpp plane coming in...
[gmic]-1./ Display image [0] = 'test_out_too.cimg'.
[0] = 'test_out_too.cimg':
  size = (256,240,1,1) [240 Kio of floats]. # <-- one 8 bpp plane image on the stack. 
  data = (255,255,255,255,255,255,255,255,255,255,255,255,(...),255,255,255,255,255,255,255,255,255,255,255,255).
  min = 0, max = 255, mean = 222.465, std = 85.0764, coords_min = (150,0,0,0), coords_max = (0,0,0,0).
[gmic]-1./ End G'MIC interpreter.
gosgood@bertha ~ $ gmic  i test.bmp [0] -jeje_normalize_local_variance 31.5,4.5,15.41,1,0,0 -fx_thin_edges[0] 0,18.5,0,100,100 o[0] test_out_too.png
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ Input file 'test.bmp' at position 0 (1 image 256x240x1x3).
[gmic]-1./ Input copy of image [0] at position 1 (1 image 256x240x1x3).
[gmic]-2./ Output image [0] as png file 'test_out_too.png' (1 image 256x240x1x1). # <-- G'MIC asks the .PNG delegate to write out a one 8 bpp plane image
[gmic]-2./ End G'MIC interpreter.
gosgood@bertha ~ $ gmic test_out_too.png
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ Input file 'test_out_too.png' at position 0 (1 image 256x240x1x1). # <-- G'MIC reads back in a one 8 bpp plane image 
[gmic]-1./ Display image [0] = 'test_out_too.png'.
[0] = 'test_out_too.png':
  size = (256,240,1,1) [240 Kio of floats]. #<-- and a one plane, 8 bpp is on the image stack.
  data = (255,255,255,255,255,255,255,255,255,255,255,255,(...),255,255,255,255,255,255,255,255,255,255,255,255).
  min = 0, max = 255, mean = 222.465, std = 85.0764, coords_min = (150,0,0,0), coords_max = (0,0,0,0).
[gmic]-1./ End G'MIC interpreter.
gosgood@bertha ~ $ gmic  i test.bmp [0] -jeje_normalize_local_variance 31.5,4.5,15.41,1,0,0 -fx_thin_edges[0] 0,18.5,0,100,100 o[0] test_out_too.bmp
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ Input file 'test.bmp' at position 0 (1 image 256x240x1x3).
[gmic]-1./ Input copy of image [0] at position 1 (1 image 256x240x1x3).
[gmic]-2./ Output image [0] as bmp file 'test_out_too.bmp' (1 image 256x240x1x1).# <-- G'MIC asks the .BMP delegate to write out a one 8 bpp plane image
[gmic]-2./ End G'MIC interpreter.
gosgood@bertha ~ $ gmic test_out_too.bmp
[gmic]-0./ Start G'MIC interpreter.
[gmic]-0./ Input file 'test_out_too.bmp' at position 0 (1 image 256x240x1x3). #<-- !!! G'MIC reads back in a three plane 24 bpp image from what was actually written to disk!
[gmic]-1./ Display image [0] = 'test_out_too.bmp'.
[0] = 'test_out_too.bmp':
  size = (256,240,1,3) [720 Kio of floats]. #<-- A three plane, 24 bpp is on G'MIC's image stack: 3 × 240 = 720 kilos
  data = (255,255,255,255,255,255,255,255,255,255,255,255,(...),255,255,255,255,255,255,255,255,255,255,255,255).
  min = 0, max = 255, mean = 222.465, std = 85.076, coords_min = (150,0,0,0), coords_max = (0,0,0,0).
[gmic]-1./ End G'MIC interpreter.

In linux land, where I live, I believe G’MIC uses ImageMagick as a delegate to write formats like .png and .bmp and has no idea what happens after the hand-off. (Plenty of people here can correct me if I’m wrong). At this stage, should I go poof! and suddenly become you, I’d be asking myself how important is the particularity of a file format to my overall workflow. Just because I happen to have a toy that reads .bmp? Or is the .bmp reader inextricably mangled with the C code that also does the analytics — that would be a problem ( Ah, me. No Separation of Concerns — shot myself in the foot a billion times not heeding that…). Judging from the links I’ve looked at, the world, in general, seems to have difficulty putting just one plane, 8 bpp, into a .bmp file…

1 Like

For BMP format, see BMP file format - Wikipedia

The only BMP format that stores just 8 bits per pixel, grayscale, is an indexed (aka palette) format.

ImageMagick can readily create such files. For example, if in.png is an 8-bit grayscale PNG image …

magick in.png out.bmp

… then out.bmp is an 8-bit indexed image with RLE (Run Length Encoding) compression. If you don’t want RLE, then insert “-compress None” before writing the output.

2 Likes

Thanks!
It is really the simpliest solution I can find out. I was almost there, but just tried the
convert in.png out.bmp
command and did not find the “-compress None” attribute.

Using one layer could be the solution but the file size 100MB vs 33MB. That is why, I do not like the idea.