Conversion of PGM (16 bits) to JPEG2000

Ask for help and post your question on how to use XnView Classic.

Moderators: XnTriq, xnview

Post Reply
Greg1

Conversion of PGM (16 bits) to JPEG2000

Post by Greg1 » Mon Jul 31, 2006 2:53 pm

Hi,

I have the following problem: I wrote a small programm that writes out PGM images using 16 bits per pixel (in fact only 12 bits per pixel are used). XnView displays these images correctly, however it claims that the images are 8 bpp.

Now I want to convert these images to JPEG2000 format using lossless compression (yes, I do need lossless compression). The conversion works, however the resulting image is only 8 bpp. How can I convert it to JPEG2000 with 16 bits? An example of the pgm-file(test16.pgm) can be found here: http://rapidshare.de/files/27672575/images.zip.html

Additionally I think that I found 2 bugs in XnView:
- XnView cannot display JPEG2000 images with more than 8 bpp (at least greyscale images) correctly. An example (16bit.jp2) can be found in the same archive. ACDSee displays it correctly.
- XnView crashes trying to open a PGM-file, in which the max. greyscale value is more than 65535 (according to PGM-format it really cannot be bigger than 65535, however XnView should not crash in this case). An example is crash.pgm in the same archive.

Guest

Post by Guest » Mon Jul 31, 2006 6:56 pm

Just curious: how do you know tgat XNVIEW displays these 16-bit PNG's correctly ?
I have an 16 bit PNG file which surely isn't displayed as it should. In fact
I hardly know of any program which displays it correctly.
Also the viewing program has to somehow remap the 16 bit data
into 8 bit video-card, it can do that by several options, for instance skipping the least significant 6 bits or remapping the lot into 8 bit.
In my case (I use XNVIEW 1.82.4) it seems that XNVIEW only shows the least significant 8 bits, it also says it has 256 unique colours which obviously should be 65536.
As far as I know also Paint Shop and Photoshop can't handle these files properly.
If your interested you can see the effect yourself:

http://members.home.nl/ramekers/16bit_test.png

This should be an monotone increasing grey wedge 200 pixels wide and 16384 pixels long .


René

User avatar
Clo
XnThusiast
Posts: 4441
Joined: Sun Oct 17, 2004 4:57 am
Location: Bordeaux, France
Contact:

Not supported…

Post by Clo » Mon Jul 31, 2006 7:18 pm

—>All

:) Good evening,

• A long while ago, I supported a request for the 16-bit images management…
- Pierre answered that there is no benefit to do this, for some (technical?) reasons.
- Apparently, he wasn't right with regard to your messages here :|

- Sorry, I couln't find out that thread from the Search here…
- I'll rummage in my PC, maybe have I it somewhere as a text backup …Image

EDIT : The topic is THERE (in French…)

:mrgreen: Kind regards,
Claude
Clo
Old user ON SELECTIVE STRIKE till further notice

Greg1

Post by Greg1 » Tue Aug 01, 2006 7:03 am

Anonymous wrote:Just curious: how do you know tgat XNVIEW displays these 16-bit PNG's correctly?
Because what I see is correct. In fact I have 12 bits images, however you must use 2 bytes if you have more than 8 bits per pixel in PGM-format, so the upper 4 bits are always 0. But you also specify the max. grey value in the header (which is in my case 4095=2^12 - 1).
Anonymous wrote:In fact I hardly know of any program which displays it correctly.
And this is exactly my problem. Additionally I want to compress these images using JPEG2000 lossless compression. Of course I don't want to loose the 16 bits precision. Can you recommend me a tool or maybe some C/C++ library, which can do this?
Anonymous wrote:In my case (I use XNVIEW 1.82.4) it seems that XNVIEW only shows the least significant 8 bits, it also says it has 256 unique colours which obviously should be 65536.
I tried to write out just the 8 least significant bits of my images and the result is very very different from the original image. So I my case XnView does use both bytes to determine the greyscale pixel value. But you are right: even in this case it claims that the image is only 8bpp.
Anonymous wrote:As far as I know also Paint Shop and Photoshop can't handle these files properly.
I don't have Photoshop here, but I tried to display my images with ACDSee. It could not display my 16bpp (or 12 bpp) PGM-images correctly, but it was able to display 16 bpp JPEG2000 images correctly (which XnView could not, see 16bit.jp2 in the zip-archive).

Greg1

Re: Not supported…

Post by Greg1 » Tue Aug 01, 2006 7:15 am

Clo wrote:—>All

:) Good evening,

• A long while ago, I supported a request for the 16-bit images management…
- Pierre answered that there is no benefit to do this, for some (technical?) reasons.
- Apparently, he wasn't right with regard to your messages here :|

- Sorry, I couln't find out that thread from the Search here…
- I'll rummage in my PC, maybe have I it somewhere as a text backup …Image

EDIT : The topic is THERE (in French…)

:mrgreen: Kind regards,
Claude
Clo
I don't understand French, but the topic is from 2004, maybe Pierre added the 16bpp support after that.

User avatar
rra
Posts: 190
Joined: Thu May 11, 2006 1:46 pm
Location: The Netherlands

Post by rra » Tue Aug 01, 2006 10:11 am

I forgot to login as a registered user, anyway:
The only package I know which can handle a (few) image-types with 16 bit (or 48 bit) channel depth is LabVIEW with IMAQ vision addon.
I use that package in my work very often.
Unfortunately it can't (yet) deal with JPG2000 images at all.
Just PNG,JPG,TIFF and a few others.
As for my example 16 bit PNG: it is really 12 bit (as is your image)
with an greyscale-value starting from zero to 16383. Irfanview doesn't show this properly also.
There is a tendency to use 12 or 16 bit levels per channel more and more.
Data can come from scanners (some special scanner software (like VUESCAN) can extract to full 16 bit levels (x 3)) or from some (very expensive) digital camera's.
I hope Pierre will consider to adapt XnView to deal with these images
correctly.

User avatar
Drahken
Posts: 884
Joined: Sun Apr 10, 2005 4:29 pm

Post by Drahken » Tue Aug 01, 2006 10:20 am

It's strange. Every prog in existance can handle 8bit and 24bit images, many can even handle 32bits, but almost none can handle 16bits. If 24 and 32 bits aren't too hard to do, why is 16bits? I just don't get it. ::confused::


There is a version o ImageMagick which claims to support 16 bits: http://studio.imagemagick.org/script/bi ... hp#windows
Oh the feuhrer, oh the feuhrer, oh the feuhrer's nipples bonk!

User avatar
xnview
Author of XnView
Posts: 31737
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Post by xnview » Tue Aug 01, 2006 11:09 am

Drahken wrote:It's strange. Every prog in existance can handle 8bit and 24bit images, many can even handle 32bits, but almost none can handle 16bits. If 24 and 32 bits aren't too hard to do, why is 16bits? I just don't get it. ::confused::


There is a version o ImageMagick which claims to support 16 bits: http://studio.imagemagick.org/script/bi ... hp#windows
XnView can load 8/10/12/16/24/32 bits per component picture, but components are converted in 8bits... And it's a known issue with PGM 16bits...
Pierre.

Greg1

Post by Greg1 » Tue Aug 01, 2006 12:21 pm

xnview wrote:XnView can load 8/10/12/16/24/32 bits per component picture, but components are converted in 8bits... And it's a known issue with PGM 16bits...
XnView can load it, but it displays wrong information about it in the status bar. After converting to another format (e.g. JPEG2000) the image really contains only 8bpp, so the high precision is lost.

User avatar
Clo
XnThusiast
Posts: 4441
Joined: Sun Oct 17, 2004 4:57 am
Location: Bordeaux, France
Contact:

*Peanuts*

Post by Clo » Tue Aug 01, 2006 12:45 pm

—> Greg1

:) Hello !
I don't understand French, but the topic is from 2004, maybe Pierre added the 16bpp support after that.
:( Nope … nothing more for two years…

• In brief :
- I said that the 16-bit colour mode could produce smaller sized image, and that it could be sufficient in the most cases since the human eye can't distinguish more than 15,000 colours about.
- Pierre said that 16-bit images could be very difficult to compress.
… and the issue remained pending :|

:mrgreen: KR
Claude
Clo
Old user ON SELECTIVE STRIKE till further notice

User avatar
Olivier_G
XnThusiast
Posts: 1423
Joined: Thu Dec 23, 2004 7:17 pm
Location: Paris, France
Contact:

Re: Not supported…

Post by Olivier_G » Tue Aug 01, 2006 2:12 pm

Clo wrote:The topic is THERE (in French…)
Hi Clo. The French topic is about '16 bits color mode' (ie: 65536 colours) whereas the issue here is about 16 bits per channel (ie: 65536 shades of grey; 281 trillions of colours).
Greg1 wrote:XnView can load it, but it displays wrong information about it in the status bar. After converting to another format (e.g. JPEG2000) the image really contains only 8bpp, so the high precision is lost.
I am already glad XnView can browse/view 3x16 bits TIFF files correctly. Adding full 16 bits management would be nice, but I don't see this as a high priority request. I support it, though, with a low priority.
Olivier

User avatar
Drahken
Posts: 884
Joined: Sun Apr 10, 2005 4:29 pm

Post by Drahken » Tue Aug 01, 2006 3:09 pm

XnView can load 8/10/12/16/24/32 bits per component picture, but components are converted in 8bits...
I still don't get why programs (not just xnview) can fully handle 8, 24, and (usually) 32 bit images (including saving as 8/24/32), but not 16. I could see 10 and 12 being an issue since they're not evenly divisible by 8, but 16??

Greg- You could either convert the pics to 24 bits (image->truecolor) before saving them as JP2s (larger filesize, but no loss of color or detail), or install and use ImageMagick for the conversion. One drawback (advantage in some cases) to ImageMagick is that it's a commandline oriented program.
Oh the feuhrer, oh the feuhrer, oh the feuhrer's nipples bonk!

User avatar
Olivier_G
XnThusiast
Posts: 1423
Joined: Thu Dec 23, 2004 7:17 pm
Location: Paris, France
Contact:

Post by Olivier_G » Tue Aug 01, 2006 3:33 pm

Drahken wrote:I still don't get why programs (not just xnview) can fully handle 8, 24, and (usually) 32 bit images (including saving as 8/24/32), but not 16.
Dont mix bit depth per component/channel as discussed here and overall bit depth.
The issue discussed here is about managing 3x16=48 bits (or subcategories like 3x10; 3x12...) while XnView works internally with a precision of only 8 bits per channel (3x8=24bits) - if we consider RGB color images.
Olivier

User avatar
rra
Posts: 190
Joined: Thu May 11, 2006 1:46 pm
Location: The Netherlands

Post by rra » Tue Aug 01, 2006 4:29 pm

I agree totally, that is exactly why it is far more difficult to do then 24 bit RGB, but still I think it would be very nice to be able to display such images and do some manipulations (scaling , filtering and such) without losing
the high pixel-depth resolution;
saving of the resulting image would ofcourse also be supported.
May be one day ...


René

User avatar
xnview
Author of XnView
Posts: 31737
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Post by xnview » Tue Aug 01, 2006 4:32 pm

Greg1 wrote:
xnview wrote:XnView can load 8/10/12/16/24/32 bits per component picture, but components are converted in 8bits... And it's a known issue with PGM 16bits...
XnView can load it, but it displays wrong information about it in the status bar. After converting to another format (e.g. JPEG2000) the image really contains only 8bpp, so the high precision is lost.
XnView doesn't support more than 8bits per component, and all 10/12/16/24/32bits will be converted in 8
Pierre.

Post Reply