Question : what format to be used to decompress the color HTJ2K compressed imaging data

[madhub]

Hi
I have color imaging data compressed using HTJ2K format , I was trying to decompress to a raw format (yuv), I am getting below error.

ojph error 0x20000005 at ojph_expand.cpp:310: The current implementation of yuv file object does not support saving file when conversion from yuv to rgb is needed; in any case, this is not the normal usage of yuvfile.

Any idea how to decompress it to raw ?
Note , image data is in RGB

[aous72]

Why do you want to decompress to raw?

JPEG2000 usually converts RGB to YUV, and stores the Y, U, and V components. Most implementations, including OpenJPH, do that,

The difficulty I face is when we save to raw or yuv, do we save RGB or the internal YUV? Note that U and V can be signed components -- I need to check about signedness.
This can be supported with command line options, but I do not currently give these options.

For your case, I would recommend saving to ppm. It is a very simple format.
There is a short header followed by interleaved image data. so you have
RGB for first pixel, RGB for second pixel and so on.
Data can be 8-bit or big-endian 16-bit.

Hope this helps.

[madhub]

Why do you want to decompress to raw?

JPEG2000 usually converts RGB to YUV, and stores the Y, U, and V components. Most implementations, including OpenJPH, do that,

The difficulty I face is when we save to raw or yuv, do we save RGB or the internal YUV? Note that U and V can be signed components -- I need to check about signedness. This can be supported with command line options, but I do not currently give these options.

For your case, I would recommend saving to ppm. It is a very simple format. There is a short header followed by interleaved image data. so you have RGB for first pixel, RGB for second pixel and so on. Data can be 8-bit or big-endian 16-bit.

Hope this helps.

Ok, couple of questions.

1. While decompressing into to PPM format , Is their any way to know whether pixel data is in RGB or YUV format or PPM only stores in RGB.

2. Is their anyway to know , how pixel is organized, interleaved or planner while decompression into PPM format?

[aous72]

It is always RGB.
It is always interleaved, as in
R first pixel, G first pixel, B first pixel, R second pixel, G second pixel, B second pixel.
See https://netpbm.sourceforge.net/doc/ppm.html
The code of class ojph::ppm_in in ojph_img_io.h, ojph_img_io.cpp can read pgm/ppm, where pgm is a single color file.
I noticed there is the variable plannar in ppm_in, but it is never used and should be removed.

Forgot to say nobody uses ASCII format, AFAIK, because it is not efficient. So don't worry about it.

[madhub]

It is always RGB. It is always interleaved, as in R first pixel, G first pixel, B first pixel, R second pixel, G second pixel, B second pixel. See https://netpbm.sourceforge.net/doc/ppm.html The code of class ojph::ppm_in in ojph_img_io.h, ojph_img_io.cpp can read pgm/ppm, where pgm is a single color file. I noticed there is the variable plannar in ppm_in, but it is never used and should be removed.

Forgot to say nobody uses ASCII format, AFAIK, because it is not efficient. So don't worry about it.

ok, I wrote simple bufferwriter to receive decompressed pixel data in memory buffer based on the raw_out implementation for grayscale , class BufferWriter : public ojph::image_out_base
For color I am planning implement based on the ppm_out .

Here is the use case where I need to pixel data to be updated in the DICOM file

[aous72]

Excellent!
I think this should work.
For your output, you need to buffer the 3 color components in memory before writing them out, or perhaps sending them out to next stage.
It should be simpler than ppm_out because you have no headers, and you do not need to interleave the color components.

[aous72]

I am closing this due to no activity.