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

Kurt Schwehr schwehr at gmail.com
Mon Feb 13 21:28:54 PST 2017


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()->
> GetDriverByName("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.
> nabble.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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170213/52d70f45/attachment-0001.html>


More information about the gdal-dev mailing list