[gdal-dev] Fwd: Re: GDAL unable to write 4-band RGBA jp2 file with Kakadu 7.8

Aaron Boxer boxerab at gmail.com
Sat Feb 18 05:03:34 PST 2017 

---------- Forwarded message ----------
From: "Aaron Boxer" <boxerab at gmail.com>
Date: Feb 18, 2017 8:03 AM
Subject: Re: [gdal-dev] GDAL unable to write 4-band RGBA jp2 file with
Kakadu 7.8
To: "Kurt Schwehr" <schwehr at gmail.com>
Cc:



On Feb 18, 2017 7:26 AM, "Kurt Schwehr" <schwehr at gmail.com> wrote:

Jason,

Turns out you are hitting a known bug in v7.8 that is fixed in v7.9.  From
the kakadu v7.9 docs:

h. Corrected a tiny, yet very significant bug introduced into the
   handling of opacity channel descriptions in version 7.8.  The
   correction is in function `jp2_channels::set_opacity_mapping', where
   the opacity channel's component index accidentally overwrote the
   colour channel's component index.


Apparently Kakadu does no regression testing before a release 😁



It's pretty easy to backport the fix if you are currently stuck at 7.8.
It's just a change of a 0 to a 1.

--- kakadu/v7_8/apps/jp2/jp2.cpp
+++ kakadu/v7_9/apps/jp2/jp2.cpp
@@ -5976,7 +5976,7 @@
   if (lut_idx < 0)
     lut_idx = -1; // For consistency in comparisons later on.
   j2_channels::j2_channel *cp = state->channels+colour_idx;
-  cp->component_idx[0] = codestream_component;
+  cp->component_idx[1] = codestream_component; /* Was a bug in version 7.8
*/
   cp->lut_idx[1] = lut_idx;
   cp->codestream_idx[1] = codestream_idx;
   cp->data_format[1] = data_format;

The 0 can trigger an error that looks just like you are seeing:

Error: GdalIO: Error in Kakadu File Format Support: Attempting to create a
Component Mapping (cmap) box, one of whose channels refers to a
non-existent image component or palette lookup table. (code = 1)



On Mon, Feb 13, 2017 at 9:28 PM, Kurt Schwehr <schwehr at gmail.com> wrote:

> Hi Jason,
>
> I've seen the same thing with an alpha channel.  I'm not sure what's up.
> Using just RGB was successful.
>
> On 7.3, I'm also seeing problems when using more than the main thread on
> linux.
>
> With 7.3, I just noticed today that kdu_get_num_processors() only returns
> 0 on linux as kdu_arch.cpp is missing #include <unistd.h> so
> _SC_NPROCESSORS_ONLN and _SC_NPROCESSORS_CONF are undefined.  When I
> enabled _SC_NPROCESSORS_ONLN, I got kdu_get_num_processors() returning 74
> on what I thought was a 6 core (aka 12 hyperthread) box.   If I change the
> fall through from 0 to 2, I get all sorts of trouble from internal kakadu
> assertions and TSAN failures.
>
> So I clearly have more investigating to do.
>
> I've yet to pass along any of what I've found to Taubman and I haven't yet
> pushed any of my new tests to github, but I hope to do both soon.
>
> And I've yet to see what, if any, discussion is happening in the yahoo
> group.
>
> -kurt
>
> On Mon, Feb 13, 2017 at 8:14 PM, jason.liu <jason.liu at spookfish.com>
> wrote:
>
>> Hi gdal-dev,
>>
>> I am having trouble using GDAL to write 4-band RGBA jp2 file with Kakadu
>> 7.8. The following minimal code
>>
>>
>>     GDALAllRegister();
>>
>>     GDALDataset* srcDataset =
>> (GDALDataset*)GDALOpen("/home/jason.liu/00000783.tif", GA_ReadOnly);
>>     char **papszOptions = NULL;
>>     papszOptions = CSLSetNameValue( papszOptions, "QUALITY", "20" );
>>
>>     GDALDriver *driver = GetGDALDriverManager()->GetDri
>> verByName("JP2KAK");
>>     GDALDataset* destDataset =
>> driver->CreateCopy("/home/jason.liu/00000783.jp2",
>>                                                   srcDataset,
>>                                                   FALSE,
>>                                                   papszOptions,
>>                                                   NULL,
>>                                                   NULL);
>>
>>     if( destDataset != NULL ) {
>>         GDALClose( (GDALDatasetH) destDataset );
>>     }
>>     GDALClose( (GDALDatasetH) srcDataset );
>>     CSLDestroy(papszOptions);
>>
>>
>> crashes Kakadu 7.8 with the following message in stderr:
>>
>> ERROR 1: Error in Kakadu File Format Support:
>> Attempting to create a Component Mapping (cmap) box, one of whose channels
>> refers to a non-existent image component or palette lookup table.
>> terminate called after throwing an instance of
>> 'kdu_cpl_error_message::JP2KAKException'
>>
>>
>> where /home/jason.liu/00000783.tif is a 4-band 16-bit RGBA tif.
>>
>>
>> I have also done the following tests and noted the results:
>>
>> 3-band 8-bit RGB tif            OK
>> 3-band 16-bit RGB tif          OK
>> 4-band 8-bit RGBA tif          error as above
>> 4-band 16-bit RGBA tif        error as above
>>
>>
>> Am I doing anything wrong here?
>>
>> By the way, I am quite certain Kakadu 7.8 supports 4-band RGBA as I can
>> use
>> their example kdu_compress to produce 4-band RGBA jp2 images. So this
>> looks
>> to be a problem with GDAL, or the way I am invoking it.
>>
>>
>> Any insights will be greatly appreciated.
>>
>> Kind Regards
>> Jason
>>
>>
>>
>>
>> --
>> View this message in context: http://osgeo-org.1560.x6.nabbl
>> e.com/GDAL-unable-to-write-4-band-RGBA-jp2-file-with-Kakadu-
>> 7-8-tp5307801.html
>> Sent from the GDAL - Dev mailing list archive at Nabble.com.
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>
>
>
>
> --
> --
> http://schwehr.org
>



-- 
--
http://schwehr.org

_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170218/b5aa55d8/attachment.html>

More information about the gdal-dev mailing list