Re: Dealing with MONO12 images in memory

Hello Bob

The 12 bit images are from an Allied Vision Technologies Manta
camera, and like the Basler you mention, 12 bit mode images are
delivered as 16 bytes per pixel by the Aravis libraries. So I've
coded it like this:

  Blob blob(pRaw16Image, (arv_width * arv_height *
nbytes));

  dbprintf(0, "Blob data: 0x%x, length: %ld\n", blob.data(),
blob.length());

  Image gmimage;

//Â Â Â gmimage.depth(16);

//Â Â Â gmimage.endian(LSBEndian);

  gmimage.read(blob,Geometry(arv_width, arv_height),"GRAY");

  gmimage.depth(16);

  gmimage.endian(LSBEndian);

//Â Â Â gmimage.normalize();

//@ Â gmimage.read(blob, Geometry(arv_width, arv_height), 16,
"GRAY");

//@Â Â gmimage.endian(LSBEndian);

//$Â Â gmimage.read(arv_width, arv_height, "I", ShortPixel,
pRaw16Image);

//$Â Â gmimage.endian(LSBEndian);

//$$Â gmimage.normalize();

  dbprintf(0,"gmimage.isValid: %d, depth: %d\n",
gmimage.isValid(), gmimage.depth());

#if 1

  char * jpgFilename = pAdo->GetContJpg();

  if((jpgFilename != NULL) && (strcmp(jpgFilename,
"none") != 0)) {

    dbprintf(1, "writing file: %s\n", jpgFilename);

    gmimage.write(jpgFilename);

    gmimage.display();

  }

#endif

When pRaw16Image is pointing to memory containing a "MONO12"
grayscale image where each pixel is 12 bits of intensity information
in 16 bits of storage I do not get a good image from
image.display(). In fact, image.display() shows the image as having
"two pages". If the file I write has a "tiff" extension, display
programs like gimp also think there are two images.

If I feed this same code a grayscale image in "MONO8" where each
pixel is represented in 8 bits, things look good - without changing
the code from depth(16) to depth(8).

So I added the printout of what the image depth is. At first I was
setting depth before the image.read() and the depth was reported as
8, so I tried setting the depth after the read() but the depth is
still reported as 8.

The second style of read (commented out with "//@" had the same
result.

The third style of read (commented out with "//$") resulted in a
black looking image, until I added normalize, and then the image
actually looked good! But I think something is probably still
wrong, because the image depth is still reported as 8, and the
displayed image's info says it has only 256 values, so only 8 bits
deep.

Is there some other way of specifying the image depth for a GRAY
image? Am I doing something else wrong? Any suggestions for other
things to try? My users are physicists who are interested in
lossless images with the full dynamic range available.

Once again, I really appreciate your help with this. I am looking
forward to getting beyond this and trying some of the other
graphicsmagick features.

Rob

On 11/21/17 17:38, Bob Friesenhahn
wrote:

On Tue, 21 Nov 2017, Robert H. Olsen wrote:

Thank you very much for your quick reply Bob.

This works very well when I limit the camera to MONO_8 images.Â
I am still having trouble with the 12 bit images, but I need to
verify my own code (I may have may some mistakes refactoring to
use GraphicsMagick)Â before I assume the problem is with how I
am calling your functions.

The gray coder does not appear to support 12 bit images since the
C API supports obtaining a sub-rectangle of the image, which
requires random access. Random access is most easily done with
pixels aligned with bytes. The gray coder can support 8/16/32 bit
images.

Are your 12-bit images a compact stream of bits (e.g. in
big-endian order with samples crossing byte boundaries), or are
they 12-bits in 16-bit samples, or something else? One possible
way to know is if the (rows * columns * depth) / 8 ~= data size.

If you do have compacted 12-bit data, do not lose hope since there
is always Plan B.

Can you tell me where I can find the
options for that final argument "GRAY" in the image.read()
function? I tried calling

 ListMagickInfo_L("ListMagickInfoResult");

which looked like it might give me that sort of information, but
I probably either made a mistake in linking or scoping (or...)
since I got a message that the function couldn't be found.

From the command line, one can learn the
supported formats via:

 gm convert -list formats

The ListMagickInfo() function writes the same output to a C file
handle as produced using fopen().

Bob

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot

_______________________________________________
Graphicsmagick-help mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/graphicsmagick-help