Opened 16 years ago

Closed 9 years ago

#2027 closed defect (fixed)

IREP setting for JPEG compressed NITF files wrong

Reported by: warmerdam Owned by: warmerdam
Priority: normal Milestone: 1.8.1
Component: GDAL_Raster Version: svn-trunk
Severity: normal Keywords: nitf jpeg
Cc:

Description

When writing to JPEG compressed NITF files, this is what I (Reiner) found:

  • Grayscale (1 Band) images are displayed correctly.
  • RGB images (3 Bands) are displayed incorrect - wrong colors.
  • IMPORTANT: The image which was reported "reddish" was a 3 Band image; not a 1 Band image. In my previous mail, I said the image was grayscale, which was basically correct. However, it had 3 identical Bands, which I didn't notice in the first place ...
  • When I changed the IREP field in the image subheader from "RGB" to "YCbCr601", the image was displayed correctly by Geo*View.
  • It was not necessary to modify the IREPBAND1-3 from "R", "G", "B" to "Y", "Cb", "Cr". Not sure if that would be "cleaner" ...

Conclusion: to fix this issue, set the IREP field the "YCbCr601" in case of JPG compressed RGB images.

Change History (5)

comment:1 by warmerdam, 16 years ago

Potentially related problem with jpeg2000 output:

  • There seems to be a similar problem with the IREP field for JP2000 compressed images as for JPG: In case of a RGBX image the IREP was set to "MONO" instead of "RGB". As a result, Geo*View did display the image in monochrome. When I used a hex editor to set the value to "RBG " Geo*View had the colors right. My GDAL based reader did not care. Please note that I did that test with a Blue Marble Image, which is a 4 band image:

comment:2 by warmerdam, 16 years ago

Status: new → assigned

I have corrected the JPEG case to set IREP to YCbCr601 and also set the IREPBAND values for completeness (r13207).

I'd still like to review the jpeg2000 case.

comment:3 by warmerdam, 16 years ago

Milestone: 1.5.0 → 1.5.1

Core issue dealt with, 1.5.1 may be soon enough for the jpeg2000 case review.

comment:4 by ReinerBeck, 15 years ago

This bug was reported again in ticket 2343.

It should be noted that the problem is not limited to jpg2000 compressed images. The same problem exists for non compressed images. The jpg compression is not affected, as the driver does not support four band images with jpg compression.

The new ticket also provides a proposed solution.

comment:5 by Jukka Rahkonen, 9 years ago

Resolution: → fixed
Status: assigned → closed

ReinerBeck writes that #2343 is the same issue and it has fixed 7 years ago which makes me trust that this one was solved by the same.

Note: See TracTickets for help on using tickets.