Question : what format to be used to decompress the color HTJ2K compressed imaging data about openjph HOT 6 CLOSED

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.

from openjph.

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?

from openjph.

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.

from openjph.

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

from openjph.

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.

from openjph.

I am closing this due to no activity.

from openjph.