pngread does not read 12bit gray images

[de Almeida, Valmor F.]

Hello,

I am using imread() to read 12-bit png images. The result of

Y = imread("foo.png");
class(I);

is uint16. However the max and min values of Y are not correct. I
tracked the problem down to this section of pngread.cc in the
octave-forge package image-1.06

  // For now, use 8-bit only
  if (bit_depth == 16) {
      png_set_strip_16(png_ptr);
  }

Is there a simple fix for this so that I do get all gray values into the
matrix Y? The issue here is that after the 8-bit strip, the image loses
critical information; in particular contrast details that are important
for the image processing code I am writing.

Thanks,

--
Valmor

PS: Actually I started writing an experimental pngread() for reading
gray images with depths greater than 8 bits. Since this is something I
have not done before, I would appreciate any inputs.




_______________________________________________
Help-octave mailing list
Help-octave@...
https://www.cae.wisc.edu/mailman/listinfo/help-octave

[Søren Hauberg]

lør, 05 07 2008 kl. 13:41 -0400, skrev de Almeida, Valmor F.:

> I am using imread() to read 12-bit png images. The result of
>
> Y = imread("foo.png");
> class(I);
>
> is uint16. However the max and min values of Y are not correct. I
> tracked the problem down to this section of pngread.cc in the
> octave-forge package image-1.06
>
>   // For now, use 8-bit only
>   if (bit_depth == 16) {
>       png_set_strip_16(png_ptr);
>   }
>
> Is there a simple fix for this so that I do get all gray values into the
> matrix Y? The issue here is that after the 8-bit strip, the image loses
> critical information; in particular contrast details that are important
> for the image processing code I am writing.

The first thing I would do is to see if ImageMagick can read the file
for you. The current 'imread' function works something like this for png
files

  if (have_pngread)
    I = pngread (filename)
  elseif (have_magickread)
    I = __magick_read__ (filename)
  else
    # try to do it using the 'convert' utility, I think
  endif

Since you have 'pngread' installed 'imread' will try to use that. So,
I'd try to use '__magick_read__' directly, i.e.

  Y = __magick_read__ ("foo.png");

and see how that works.

Søren

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www.cae.wisc.edu/mailman/listinfo/help-octave

[baf88]

On 2008-07-05 7:41 PM, "de Almeida, Valmor F." <dealmeidav@...> wrote:

>
> Hello,
>
> I am using imread() to read 12-bit png images. The result of
>
> Y = imread("foo.png");
> class(I);
>
> is uint16. However the max and min values of Y are not correct. I
> tracked the problem down to this section of pngread.cc in the
> octave-forge package image-1.06
>
>   // For now, use 8-bit only
>   if (bit_depth == 16) {
>       png_set_strip_16(png_ptr);
>   }
>
> Is there a simple fix for this so that I do get all gray values into the
> matrix Y? The issue here is that after the 8-bit strip, the image loses
> critical information; in particular contrast details that are important
> for the image processing code I am writing.
>
> Thanks,
>
> --
> Valmor

I'm working on one to:
Download and try:
http://pinus.tt.ltu.se/~baf/pngread.cc
The test for endianness of the machine should be done during compilation but
I haven't figured out how.

And if it seems to work just include it in the distro.





_______________________________________________
Help-octave mailing list
Help-octave@...
https://www.cae.wisc.edu/mailman/listinfo/help-octave

[John W. Eaton]

On 10-Jul-2008, Bengt-Arne Fjellner wrote:

| I'm working on one to:
| Download and try:
| http://pinus.tt.ltu.se/~baf/pngread.cc
| The test for endianness of the machine should be done during compilation but
| I haven't figured out how.
|
| And if it seems to work just include it in the distro.

The next release of Octave will include an imread function that will
be able to read png images using the GraphicsMagick library, so I
don't see the need for a separate pngread function.

jwe
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www.cae.wisc.edu/mailman/listinfo/help-octave

[Søren Hauberg]

tor, 10 07 2008 kl. 19:23 +0200, skrev Bengt-Arne Fjellner:

> On 2008-07-05 7:41 PM, "de Almeida, Valmor F." <dealmeidav@...> wrote:
> > I am using imread() to read 12-bit png images. The result of
> >
> > Y = imread("foo.png");
> > class(I);
> >
> > is uint16. However the max and min values of Y are not correct. I
> > tracked the problem down to this section of pngread.cc in the
> > octave-forge package image-1.06
>
> I'm working on one to:
> Download and try:
> http://pinus.tt.ltu.se/~baf/pngread.cc
> The test for endianness of the machine should be done during compilation but
> I haven't figured out how.
>
> And if it seems to work just include it in the distro.

Can any of you 16 bit people check that the __magick_read__ function can
read your images? I don't have any 16 bit images available at the
moment, so I can't check this...

Søren

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www.cae.wisc.edu/mailman/listinfo/help-octave

[de Almeida, Valmor F.]

> -----Original Message-----
> From: Søren Hauberg [mailto:soren@...]
> Sent: Sunday, July 06, 2008 3:26 AM
>
> Since you have 'pngread' installed 'imread' will try to use that. So,
> I'd try to use '__magick_read__' directly, i.e.
>
>   Y = __magick_read__ ("foo.png");
>
> and see how that works.

Yep. It does work. However it is a little tricky to compare the max(Y(:)) and min(Y(:)) values octave has in memory with the output of imagemagick's "identify" tool.

Just for the record. In the following output from identify

  Format: PNG (Portable Network Graphics)
  Class: DirectClass
  Geometry: 275x220+0+0
  Type: Grayscale
  Endianess: Undefined
  Colorspace: Gray
  Depth: 16-bit
  Channel depth:
    Gray: 12-bit
  Channel statistics:
    Gray:
      Min: 774 (0.188968)
      Max: 1558 (0.380377)
      Mean: 1213.52 (0.296275)
      Standard deviation: 95.3054 (0.0232683)

Octave's values for min and max are: 12384 and 24928. These are obtained from multiplying the corresponding numbers in parentheses from the "identify" output by 65536.


Thanks,

--
Valmor

>
> Søren


_______________________________________________
Help-octave mailing list
Help-octave@...
https://www.cae.wisc.edu/mailman/listinfo/help-octave

[Søren Hauberg]

fre, 11 07 2008 kl. 01:10 -0400, skrev de Almeida, Valmor F.:

> > From: Søren Hauberg [mailto:soren@...]
> > Since you have 'pngread' installed 'imread' will try to use that. So,
> > I'd try to use '__magick_read__' directly, i.e.
> >
> >   Y = __magick_read__ ("foo.png");
> >
> > and see how that works.
>
> Yep. It does work. However it is a little tricky to compare the max(Y(:)) and min(Y(:)) values octave has in memory with the output of imagemagick's "identify" tool.
>
> Just for the record. In the following output from identify
>
>   Format: PNG (Portable Network Graphics)
>   Class: DirectClass
>   Geometry: 275x220+0+0
>   Type: Grayscale
>   Endianess: Undefined
>   Colorspace: Gray
>   Depth: 16-bit
>   Channel depth:
>     Gray: 12-bit
>   Channel statistics:
>     Gray:
>       Min: 774 (0.188968)
>       Max: 1558 (0.380377)
>       Mean: 1213.52 (0.296275)
>       Standard deviation: 95.3054 (0.0232683)
>
> Octave's values for min and max are: 12384 and 24928. These are obtained from multiplying the corresponding numbers in parentheses from the "identify" output by 65536.

Hmmm, that's a bit odd isn't it? It seems that

  0.188968 * (2^12 - 1) = 774

and
 
  0.188968 * (2^16 - 1) = 12384

So, this is somehow related to the fact that the image is 12 bit but is
read as 16 bit. Should the minimum value be 774 (as ImageMagick reports)
or should it be 12384 (as Octave reports) ? I mean, who's right?

Søren

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www.cae.wisc.edu/mailman/listinfo/help-octave

[Bill Denney-5]

Søren Hauberg wrote:

> fre, 11 07 2008 kl. 01:10 -0400, skrev de Almeida, Valmor F.:
>  
>> Yep. It does work. However it is a little tricky to compare the max(Y(:)) and min(Y(:)) values octave has in memory with the output of imagemagick's "identify" tool.
>>
>> Just for the record. In the following output from identify
>>
>>   Format: PNG (Portable Network Graphics)
>>   Class: DirectClass
>>   Geometry: 275x220+0+0
>>   Type: Grayscale
>>   Endianess: Undefined
>>   Colorspace: Gray
>>   Depth: 16-bit
>>   Channel depth:
>>     Gray: 12-bit
>>   Channel statistics:
>>     Gray:
>>       Min: 774 (0.188968)
>>       Max: 1558 (0.380377)
>>       Mean: 1213.52 (0.296275)
>>       Standard deviation: 95.3054 (0.0232683)
>>
>> Octave's values for min and max are: 12384 and 24928. These are obtained from multiplying the corresponding numbers in parentheses from the "identify" output by 65536.
>>    
>
> Hmmm, that's a bit odd isn't it? It seems that
>
>   0.188968 * (2^12 - 1) = 774
>
> and
>  
>   0.188968 * (2^16 - 1) = 12384
>
> So, this is somehow related to the fact that the image is 12 bit but is
> read as 16 bit. Should the minimum value be 774 (as ImageMagick reports)
> or should it be 12384 (as Octave reports) ? I mean, who's right?

I'd say that ImageMagick is right, but that we shouldn't change our
output unless we implement a 12 bit numeric class (with the new classes
that could be done relatively easily, but I don't think it's worth the
effort for this).  The reason is that we should be able to replicate the
image through its normalized intensity in the current bit depth.  If we
set it to 774, but it's stored in an uint16, then unless you
specifically knew the image was 12 bit, it seems likely that you would
represent the image as lower contrast than it really is (most code will
make the assumption that the intensity is 774/(2^16 -  1)).  Keeping the
12384 allows round-trips to be made correctly while I don't think that's
the case for 774.

Have a good day,

Bill
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www.cae.wisc.edu/mailman/listinfo/help-octave

[Søren Hauberg]

fre, 11 07 2008 kl. 07:04 -0400, skrev Bill Denney:

> > So, this is somehow related to the fact that the image is 12 bit but is
> > read as 16 bit. Should the minimum value be 774 (as ImageMagick reports)
> > or should it be 12384 (as Octave reports) ? I mean, who's right?
> I'd say that ImageMagick is right, but that we shouldn't change our
> output unless we implement a 12 bit numeric class (with the new classes
> that could be done relatively easily, but I don't think it's worth the
> effort for this).  The reason is that we should be able to replicate the
> image through its normalized intensity in the current bit depth.  If we
> set it to 774, but it's stored in an uint16, then unless you
> specifically knew the image was 12 bit, it seems likely that you would
> represent the image as lower contrast than it really is (most code will
> make the assumption that the intensity is 774/(2^16 -  1)).  Keeping the
> 12384 allows round-trips to be made correctly while I don't think that's
> the case for 774.

I just think of images as matrices, so to me the actual numerical values
in each pixel should not be altered when the image is read. The way I
understand the issue, is that the image contains a pixel with the value
774, that Octave reads as 12384, which can't be right. So, it sounds
like a bug in __magick_read__ to me... Am I understanding things
correctly?
I think that 12 bit images should be represented as 16 bit images that
happens to have a maximum value of 2^12 - 1.

Søren

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www.cae.wisc.edu/mailman/listinfo/help-octave

[de Almeida, Valmor F.]

> -----Original Message-----
> From: Søren Hauberg [mailto:soren@...]
> Sent: Friday, July 11, 2008 7:32 AM
> ..snip..
> I think that 12 bit images should be represented as 16 bit images that
> happens to have a maximum value of 2^12 - 1.

I tend to agree. The values should be read as they are.

--
Valmor

>
> Søren


_______________________________________________
Help-octave mailing list
Help-octave@...
https://www.cae.wisc.edu/mailman/listinfo/help-octave

[Bill Denney-5]

I assume that you meant to send this reply back to the list.  If not,
I'm sorry for putting it back here.  Also, if the message below sounds
harsh, please don't take it that way-- I just feel strongly about the
subject of accurate data representation and I'm not convinced that the
method you suggest will keep data in the most accurate format.

de Almeida, Valmor F. wrote:

>> -----Original Message-----
>> From: Bill Denney [mailto:wsloand@...] On Behalf Of Bill Denney
>> Sent: Friday, July 11, 2008 11:57 PM
>>
>> de Almeida, Valmor F. wrote:
>>    
>>>> -----Original Message-----
>>>> From: Søren Hauberg [mailto:soren@...]
>>>> Sent: Friday, July 11, 2008 7:32 AM
>>>> ..snip..
>>>> I think that 12 bit images should be represented as 16 bit images that
>>>> happens to have a maximum value of 2^12 - 1.
>>>>        
>>> I tend to agree. The values should be read as they are.
>>>      
>> the same way) and the number in the image represents the distance from 0
>> to the maximum on that scale.
>>    
>
> That is fine. But the user should have the option of doing this 0-1 scaling from integer to double on his/her own.
>  

Hopefully it's not actually converting to a double (I would view that as
a real problem).

>> If you use the method of having a value read from a 12 bit scale (x)
>> into a 16 bit scale (y), x/(2^12 - 1) should equal y/(2^16 - 1).  If you
>>    
>
> The point is that the max should be whatever is in the image and not be scaled to 2^16-1.
>
> I tend to agree with that because gray images of scientific importance are typically of low contrast and low SNR. Therefore I want to keep all the information intact when I read the image.

Having done scientific image analysis before, I realize that the work is
often low contrast and that it is necessary to keep all information
intact.  I would argue that putting 774 into a uint16 is not keeping all
information intact while putting the bits that make up 774 into the
leftmost bits of a uint16 is keeping the information intact and
corresponds to what most image processing/manipulation tools expect.

Note the following:

octave-3.0.1.exe:1> x_uint12 = uint16(774)
x_uint12 = 774
octave-3.0.1.exe:2> x_uint16 = bitshift(x_uint12, 4)
x_uint16 = 12384

If you know that your image is 12 bit then just right shift the data by 4:
octave-3.0.1.exe:3> bitshift(x_uint16, -4)
ans = 774

As I have stated before, it is not possible to round trip the data
through octave if it does not use the bit depth for the integer type
(without adding additional metadata).  Try the following (untested, but
it should work):

Y = imread("foo.png");
max(Y(:))
## You should see 12384 here
any(bitshift(Y, 12)(:))
## you should see 0 here indicating that the 4 least significant bits
are all 0
Y12 = bitshift(Y, -4);
max(Y12(:))
## you should see 774 here
imwrite("foo12.png", Y12)
## foo12.png is now the image that you had originally requested that
octave provide
imwrite("foo16.png", Y)
## foo16.png is the image that I think octave should provide (i.e. what
it currently provides)

If you examine foo, foo12 and foo16.png in any (non-contrast adjusting)
image viewer you should see that the original and 16 are the same while
12 is much darker.  How would you propose to correct that without the
addition of a 12 bit class (i.e. uint12) and without requiring
additional metadata to imwrite?

Almost all of the scientific image analysis that I'm aware of works on
contrast not on absolute numbers.  Also, if you need the actual original
number and you know the bit depth of the original, you can always modify
the original with a bit shift.

Have a good day,

Bill
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www.cae.wisc.edu/mailman/listinfo/help-octave

[de Almeida, Valmor F.]

> -----Original Message-----
> From: Bill Denney [mailto:wsloand@...] On Behalf Of Bill Denney
> Sent: Monday, July 14, 2008 6:54 PM
> To: help-octave@...; de Almeida, Valmor F.
> Subject: Re: pngread does not read 12bit gray images
>
> I assume that you meant to send this reply back to the list.  If not,

Thanks for putting it back. Here are some comments for the record.

> > That is fine. But the user should have the option of doing this 0-1
> scaling from integer to double on his/her own.
> >
>
> Hopefully it's not actually converting to a double (I would view that
as
> a real problem).

I misunderstood your past e-mails when you mentioned 0-1 scale.
 
> Having done scientific image analysis before, I realize that the work
is
> often low contrast and that it is necessary to keep all information
> intact.  I would argue that putting 774 into a uint16 is not keeping
all
> information intact while putting the bits that make up 774 into the
> leftmost bits of a uint16 is keeping the information intact and
> corresponds to what most image processing/manipulation tools expect.

I guess I care about what happened to my $774; that is, this "tangible,
buying-power quantity" which is represented as

     774 on the decimal base system and,

  0000001100000110 on a big-endian 16-binary base system.

If it happens that it has been bit shifted to the left by 4 instead, I
would certainly welcome that because now

  0011000001100000  represents

$12384 and that is certainly a financial advantage :)

Thank you for pointing this out. I currently read 12-bit png images as
follows

Y = __magick_read__(filename);

Y = bitshift(Y,-4);

and this matches the info from running imagemagick identify on the file.

imread() should not be used if you have libpng on your system because
this will call a reader that converts the 12-bit data to 8-bit data, and
that is not good.

I have also loaded the file with cinepaint and verified that internally
the pixel values have been shifted to the left by 4 as you mentioned.

Thanks,

--
Valmor

 

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www.cae.wisc.edu/mailman/listinfo/help-octave

[John W. Eaton]

On 16-Jul-2008, de Almeida, Valmor F. wrote:

| Thank you for pointing this out. I currently read 12-bit png images as
| follows
|
| Y = __magick_read__(filename);
|
| Y = bitshift(Y,-4);
|
| and this matches the info from running imagemagick identify on the file.
|
| imread() should not be used if you have libpng on your system because
| this will call a reader that converts the 12-bit data to 8-bit data, and
| that is not good.

The imread function will be included in the next major release of
Octave, but it won't use pngread or jpgread.  Instead, it will only
use GraphicsMagick++ to read image files.

jwe
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www.cae.wisc.edu/mailman/listinfo/help-octave

[Søren Hauberg]

ons, 16 07 2008 kl. 18:49 -0400, skrev de Almeida, Valmor F.:
> Thank you for pointing this out. I currently read 12-bit png images as
> follows
>
> Y = __magick_read__(filename);
>
> Y = bitshift(Y,-4);
>
> and this matches the info from running imagemagick identify on the file.

Would it be possible for you to put your 12-bit image somewhere online?
I think it would be nice if the future version of 'imread' would support
12 bit images in a way where the 'bitshift' wasn't needed. But I don't
have any 12 bit images at hand so its hard to debug...

Søren

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www.cae.wisc.edu/mailman/listinfo/help-octave

[Bill Denney-5]

Søren Hauberg wrote:

> ons, 16 07 2008 kl. 18:49 -0400, skrev de Almeida, Valmor F.:
>  
>> Thank you for pointing this out. I currently read 12-bit png images as
>> follows
>>
>> Y = __magick_read__(filename);
>>
>> Y = bitshift(Y,-4);
>>
>> and this matches the info from running imagemagick identify on the file.
>>    
>
> Would it be possible for you to put your 12-bit image somewhere online?
> I think it would be nice if the future version of 'imread' would support
> 12 bit images in a way where the 'bitshift' wasn't needed. But I don't
> have any 12 bit images at hand so its hard to debug...

Hi Soren,

Without reiterating my statements from the entire thread, how would you
do this without requiring a uint12 class or additional meta-data?

Have a good day,

Bill
_______________________________________________
Help-octave mailing list
Help-octave@...
https://www.cae.wisc.edu/mailman/listinfo/help-octave

[de Almeida, Valmor F.]

Here is a curve-ball.

If you save the following into a file named img.pgm

P2
# plain gray image; pgm
1 1
65535
4080

And use imagemagick to convert to png, you will get from indentify (on either the .png or .pgm files) the following

Image: img.png
  Format: PNG (Portable Network Graphics)
  Class: DirectClass
  Geometry: 1x1+0+0
  Type: Grayscale
  Endianess: Undefined
  Colorspace: Gray
  Depth: 16-bit
  Channel depth:
    Gray: 12-bit
  Channel statistics:
    Gray:
      Min: 255 (0.0622568)
      Max: 255 (0.0622568)
      Mean: 255 (0.0622568)
      Standard deviation: 0 (0)
  Histogram:
         1: ( 4080, 4080, 4080) #0FF00FF00FF0 rgb(6.22568%,6.22568%,6.22568%)


We know for sure that the value in the original file is 4080. Say

pgmhist img.pgm

value   count   b%      w%
-----   -----   --      --
4080    1         100%    100%

Therefore the identify program is messing things up. The real min and max are

0.0622568 * (2^16-1)

However 0.062258 * (2^12-1) is 255 which is NOT what is in the original file. Also note that 255 is obtained from bit shifting 4080 to the right by 4.

If you read the image with __magick_read into octave

octave:9> Y = __magick_read__("img.png")
Y = 4080

The final answer to the whole story is that nothing needs to be done. Just read the bloody 12-bit gray image with __magick_read__() and it will have the correct data.

I ran into some oddities when doing this exercise but I have reached the limits of my patience.

--
Valmor

PS. You can create the smallest 12-bit image in a binary file as follows

pgmtopgm  img.pgm
P2
#
1 1
65535
4080

> -----Original Message-----
> From: Søren Hauberg [mailto:soren@...]
> Sent: Thursday, July 17, 2008 3:11 AM
> To: de Almeida, Valmor F.
> Cc: Bill Denney; help-octave@...
> Subject: RE: pngread does not read 12bit gray images
>
> ons, 16 07 2008 kl. 18:49 -0400, skrev de Almeida, Valmor F.:
> > Thank you for pointing this out. I currently read 12-bit png images as
> > follows
> >
> > Y = __magick_read__(filename);
> >
> > Y = bitshift(Y,-4);
> >
> > and this matches the info from running imagemagick identify on the file.
>
> Would it be possible for you to put your 12-bit image somewhere online?
> I think it would be nice if the future version of 'imread' would support
> 12 bit images in a way where the 'bitshift' wasn't needed. But I don't
> have any 12 bit images at hand so its hard to debug...
>
> Søren

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www.cae.wisc.edu/mailman/listinfo/help-octave

[Søren Hauberg]

tor, 17 07 2008 kl. 07:35 -0400, skrev Bill Denney:
> Without reiterating my statements from the entire thread, how would you
> do this without requiring a uint12 class or additional meta-data?

Matlab provides i 'imfinfo' function for reading such meta-data. Using
uint16 to represent 12 bit images is what Matlab seems to do, and IMHO
it is the only sane thing to do, as 'imread' should just read whatever
numbers the image happens to contain -- it should do nothing else.

Søren

_______________________________________________
Help-octave mailing list
Help-octave@...
https://www.cae.wisc.edu/mailman/listinfo/help-octave