LINUX.ORG.RU
Форум — Development  

А есть ли штатная возможность добавить своих метаданных в заголовок .npy файла?

 , ,


0

2

В заголовке .npy файла лежит словарь вида

{'descr': '<f8', 'fortran_order': False, 'shape': (15, 15), }

раз там есть словарь, наверное я могу туда положить еще че то от себя? Тем более что аж стандарт v2.0 придумали, что бы можно было заголовки длиннее чем 2^16 делать (насколько я понял) - такими тремя записями 2^16 ИМНО фиг забьешь…

Попытки вручную че то туда доложить успехом не увенчались, штатный ридер ломается

ValueError: Header does not contain the correct keys: ['descr', 'fortran_order', 'q', 'shape']

Да и интерфейса стандартного для того что бы что то от себя в этот словарь положить/получить я не вижу.

Это вообще возможно?

★★★★

Последнее исправление: AntonI (всего исправлений: 1)

Свой интерпретатор хедера + frombuffer (и это уже будет не npy)? Хотя, тогда уж проще свой велосипед по аналогии сделать [json header] + [raw data] после него.

https://github.com/numpy/numpy/blob/d4243a381778109ba2522ed7d155e1338e4ca6de/... 

    if EXPECTED_KEYS != d.keys():
        keys = sorted(d.keys())
        msg = "Header does not contain the correct keys: {!r}"
        raise ValueError(msg.format(keys))

thunar ★★★★★
()
Последнее исправление: thunar (всего исправлений: 5)
Ответ на: комментарий от thunar

Свой велосипед есть. Причем он сильно лучше нампаевского в смысле расширяемости заголовка и пр. А сами сами данные лежат точно так же.

Коллеги начали бубнить - давай дескать перейдем на стандартный формат. А названия осей, систему координат и пр.куда я там дену?!

AntonI ★★★★
() автор топика
Ответ на: комментарий от thunar

ЗЫ. И не надо тула джсоны всякие тащить…

AntonI ★★★★
() автор топика
Ответ на: комментарий от AntonI

А названия осей, систему координат и пр.куда я там дену?!

Так есть же npz с нулевым сжатием — если не ошибаюсь, тогда файл можно напрямую ммэпнуть. Ну и пишите массив в name.npy, а метаданные — в какой ни будь name_meta.txt внутри того же архива. С форматом совместимо, а чобы удобно читать пишется обёртка вокруг np.load или zipfile.

не надо тула джсоны всякие тащить…

Ну для нампаевского дикта там-ж вообще safe_eval. А жсон для произвольной метаинформации таки предпочтительней.

thunar ★★★★★
()
Последнее исправление: thunar (всего исправлений: 6)
Ответ на: комментарий от thunar

Вариант конечно, но все равно как то костыльно выглядит. Главное чего я не пойму - напуркуа было совать в заголовок словарь, если в нем три и только три записи?!

А жсон для произвольной метаинформации таки предпочтительней.

Для произвольной наверное. Но в данном случае она вполне детерминирована.

AntonI ★★★★
() автор топика
Ответ на: комментарий от AntonI

напуркуа было совать в заголовок словарь, если в нем три и только три записи?!

Так npy и не должен хранить больше чем обычный numpy.array (в котором никакой метаинформации нет).

thunar ★★★★★
()
Последнее исправление: thunar (всего исправлений: 1)
Ответ на: комментарий от thunar

ЯННП. Если не должен, то это делается гораздо прямее без всяких словарей. Если есть словарь, то почему он закрыт?

Вопросы риторические.

AntonI ★★★★
() автор топика
Ответ на: комментарий от AntonI

Если не должен, то это делается гораздо прямее без всяких словарей. Если есть словарь, то почему он закрыт?

В этом как раз логика есть. Словарь – для того, чтобы добавлять новые ключи с сохранением обратной совместимости, а закрыт – чтобы занимались этим только разработчики стандарта.

В чем-то это близко к вашей ситуации:

Свой велосипед есть. Причем он сильно лучше нампаевского в смысле расширяемости

А жсон для произвольной метаинформации таки предпочтительней.

Для произвольной наверное. Но в данном случае она вполне детерминирована

Zeta_Gundam ★
()
Ответ на: комментарий от Zeta_Gundam

Словарь тут очень избыточен все таки…

AntonI ★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
Development