Patch to read GML geo metadata and other associated data for inclusio…#1110
Patch to read GML geo metadata and other associated data for inclusio…#1110HWiman wants to merge 11 commits into
Conversation
|
Sample image file with GML XML data as defined in the GML standard. Result of opj_dump -i T33VWD_20170127T102301_B10.jp2 |
| return NULL; | ||
| } | ||
|
|
||
| cstr_info->nbasoc = 0; |
There was a problem hiding this comment.
Indentation issue. Please build with cmake -DWITH_ASTYLE=ON and run scripts/prepare-commit.sh
There was a problem hiding this comment.
I just did that, but with no effect. Is the prepare-commit.sh Windows-compatible?
There was a problem hiding this comment.
Hum probably not... Maybe under Cygwin ? Anyway on already committed code, this has no effect. You can use scripts/astyle.sh your.c to fix an existing committed file
There was a problem hiding this comment.
Latest push clearly changed everything. My attempt with astyle failed completely.
There was a problem hiding this comment.
I am afraid I need your assistance to format the committed six files since it can not be done on Windows. I compiled on a remote Linux machine WITH_ASTYLE, but it does not have C++11 and I am not authorized to install gcc. Can you please run astyle.sh on the commited files?
There was a problem hiding this comment.
OK, I've run astyle. Please pull from rouault:associated_data_support to get rouault@713e131
| assert(jp2 != 00); | ||
| assert(p_header_data != 00); | ||
| assert(p_manager != 00); | ||
|
|
There was a problem hiding this comment.
you should check p_header_size is at least 8 bytes long here
| asoc = &(jp2->asoc[jp2->numasoc-1]); | ||
| asoc->level = jp2->numasoc-1; /* TODO: This is not correct if a parent asoc contains multiple child asocs! */ | ||
| asoc->label_length = asoc_size; | ||
| asoc->label = opj_malloc(asoc_size); |
There was a problem hiding this comment.
would be safer for users to allocate asoc_size + 1 and nul terminate asoc->label[asoc_size]
| asoc = &(jp2->asoc[jp2->numasoc-1]); | ||
| asoc->level = jp2->numasoc-1; /* TODO: This is not correct if a parent asoc contains multiple child asocs! */ | ||
| asoc->label_length = asoc_size; | ||
| asoc->label = opj_malloc(asoc_size); |
There was a problem hiding this comment.
you should check asoc->label is not null
There was a problem hiding this comment.
asoc->label is always uninitialized since it is created a few lines above.
| p_header_data += asoc_size; | ||
| p_header_size -= asoc_size; | ||
|
|
||
| opj_read_bytes(p_header_data,&asoc_tag,4); |
There was a problem hiding this comment.
ypi sjpimd check that there's at least 4 remaining bytes
| /* Copy the unknown data for external handling. | ||
| NOTE: This is not tested, but does the same as if an XML tag was found.*/ | ||
| asoc->xml_len = p_header_size; | ||
| asoc->xml_buf = opj_malloc(p_header_size); |
| to_asoc->level = asoc->level; | ||
| to_asoc->label_length = asoc->label_length; | ||
| to_asoc->xml_len = asoc->xml_len; | ||
| to_asoc->label = opj_malloc( to_asoc->label_length ); |
There was a problem hiding this comment.
null pointer checks needed
| } | ||
|
|
||
|
|
||
| OPJ_OFF_T opj_stream_skip_api(opj_stream_t * p_stream, OPJ_OFF_T p_size) |
There was a problem hiding this comment.
this is unrelated to this pull request AFAICS. Better put that in another one
There was a problem hiding this comment.
Indeed, sorry! Some files (like NITF) encapsulate JP2 in a file, so we need to offset the start of file reading. I did not find any way to do that so added this method.
There was a problem hiding this comment.
This is a bit self-promotion, but you are probably aware of the GDAL library (http://gdal.org/) that takes care of all this geo stuff already and deals with NITF.
There was a problem hiding this comment.
Yes, that´s an impressing and complete library! We do all our software in Java so it would require a lot of JNI bindings and we have implemented almost all image and sensor support we need already, this GML parsing being one of few missing parts.
| * number, or "ALL_CPUS". If OPJ_NUM_THREADS is set and this function is called, | ||
| * this function will override the behaviour of the environment variable. | ||
| * | ||
| * Currently this function must be called after opj_setup_decoder() and |
There was a problem hiding this comment.
why has this comment been removed ?
There was a problem hiding this comment.
Unintentional mistake. Re-inserted.
| opj_tile_info_v2_t *tile_info; /* FIXME not used for the moment */ | ||
|
|
||
| /** Number of associated data boxes*/ | ||
| OPJ_UINT32 nbasoc; |
There was a problem hiding this comment.
technically GMLJP2 boxes are JP2 level info, not codestream-level, so it is a bit weird to put them there. @detonin any better idea of a more appropriate structure ?
|
I get fails that I do not understand: The following tests FAILED: What action should I take for these? |
|
Except from fails and the potential move of associated data from code stream structure, I think the review is finished. Thanks a lot for taking the time! |
|
@HWiman Can you pull from from rouault:associated_data_support to get rouault/openjpeg@713e131 which should fix indentation issues ? |
|
Accepted pull request from @rouault . |
|
@detonin Are you OK with the addition of the new members at the bottom of opj_codestream_info_v2_t ? I had a semantic observation that GMLJP2 boxes are at the JP2 level and not the codestream one, but I'm not sure of a better place where that could be stored ? |
|
@rouault Indeed this kind of geoinformation needs to be at JP2 level and certainly not in the J2K codestream. The dedicated function you propose seems to be a good option. I guess it means that we will have to bump the minor version in the next release (as we add function in the API). |
|
There is an unused |
|
I'm fine with you implementing opj_get_jp2_metadata() and using opj_jp2_metadata. Could you add a comment in the doc of the opj_jp2_metadata struct to mention that it should never be allocated by calling code, and only used as the return of opj_get_jp2_metadata() (so we can add fields without breaking the ABI). There will probably be a need for a cleanup function to release allocated memory ? |
- Fixed bug in allocation of asoc data (length was set one byte larger than allocated)
…penjpeg into associated_data_support
|
Hi,
I finally implemented and pushed changes which put asoc data in the
opj_jp2_metadata struct as agreed. Possibly the code needs to be
reformatted again? If so, can I ask you, Evan, to do it for me like last
time since I do not have the tools? I´ll merged it into my branch according
to your last message when you´re done, like last time:
@HWiman <https://github.com/HWiman> Can you pull from from
rouault:associated_data_support to get rouault/openjpeg@713e131
<rouault@713e131> which should fix
indentation issues ?
Cheers,
Håkan
…On Wed, Apr 18, 2018 at 3:59 PM, Even Rouault ***@***.***> wrote:
I'm fine with you implementing opj_get_jp2_metadata() and using
opj_jp2_metadata. Could you add a comment in the doc of the
opj_jp2_metadata struct to mention that it should never be allocated by
calling code, and only used as the return of opj_get_jp2_metadata() (so we
can add fields without breaking the ABI). There will probably be a need for
a cleanup function to release allocated memory ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1110 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/Aj1kMAPR9GC3v8gIFPu5juXxiXd6D9v1ks5tp0bagaJpZM4S2-IT>
.
|
|
@HWiman I've run astyle on your changes and committed the reformat in rouault@14fd14e |
|
I've also fixed memory leaks per rouault@e984dfc |
|
@HWiman Can you pull my changes from https://github.com/rouault/openjpeg/tree/associated_data_support to update this PR ? |

Referring to Issue #1109, this is the requested pull request.
We need the GML meta data stored in some JP2 files as described here.
There was no reader for ASOC, LBL or XML boxes so I have added that (v2.3.0). I hope you will consider adding these changes to future versions of openjpeg.Please let me know if I can assist in getting this into openjpeg.
The patches add a new opj_jp2_asoc_t type. An opj_jp2 decoder has numasoc number of such instances in asoc. For retrieval on client side, these data are copied to opj_codestream_info_v2_t for direct access and can be dumped using opj_dump_associated_data( opj_codestream_info_v2_t cstr_info, FILE *output_stream ).