512 byte header in caffe to nnef translation

[jnorwood]

I noticed that the output from my current download of nnef tools, using the caffe-to-nnef conversion with the python, results in a 512 byte header, in other words zero padding out to 0x200, while previously the conversion didn't have this large gap.

If this isn't a known issue, I will try to repeat it and debug the issue before I post again. I'm converting on ubuntu 18.04 linux. The network is the squeezenet 1.1 deploy.prototxt and associated caffemodel from https://github.com/DeepScale/SqueezeNet/tree/master/SqueezeNet_v1.1

I change the batch dimension to 1 manually, then ran the caffe_to_nnef conversion script. After that I simply did an od -x on the result

This is what I got on the current conversion: 0000000 ef4e 0001 9000 0000 0004 0000 0040 0000 0000020 0010 0000 0003 0000 0003 0000 0000 0000 0000040 0000 0000 0000 0000 0000 0000 0020 0000 0000060 0000 0000 0000 0000 0000 0000 0000 0000 * 0000200 7d1b bd6f f444 bd80 a360 3dd5 c2b7 3d49 0000220 454e bd3b e23b bd1a 6705 3d0d af51 3d70 0000240 cef6 bd8d e854 3dad cfce beb3 d9f4 3dc4 0000260 8bf3 3ec0 7d29 3dc5 a820 beb7 8732 bd92 ...... 0110100 81d2 3db7 dbd3 3d66 91cd be09 54bc 3c20 0110120 e53e 3c47 23a0 be3f e91b bc74 a2bb 3e35 0110140 143f bdd9 4134 be6f b43e 3e54 7ab2 39db 0110160 8f14 be6e 7791 3dd0 bcad be11 8fc6 bd31 0110200

This is what I got on one of the prior builds: 0000000 ef4e 0001 0020 0000 0004 0000 0040 0000 0000020 0010 0000 0003 0000 0003 0000 2000 0000 0000040 7d1b bd6f f444 bd80 a360 3dd5 c2b7 3d49 0000060 454e bd3b e23b bd1a 6705 3d0d af51 3d70 0000100 cef6 bd8d e854 3dad cfce beb3 d9f4 3dc4 ..... 0107740 81d2 3db7 dbd3 3d66 91cd be09 54bc 3c20 0107760 e53e 3c47 23a0 be3f e91b bc74 a2bb 3e35 0110000 143f bdd9 4134 be6f b43e 3e54 7ab2 39db 0110020 8f14 be6e 7791 3dd0 bcad be11 8fc6 bd31 0110040

[gyenesvi]

Just to confirm, do I understand right that the problem is that the fixed size header itself, which should be 128 bytes, is instead 512 bytes long? It is weird, since it uses the same code under the hood as for other converters, and those don't seem to have that problem.

[gyenesvi]

By the way, we have just pushed some updates to all tools, can you update on your side and re-check?

[jnorwood]

Just to confirm, do I understand right that the problem is that the fixed size header itself, which should be 128 bytes, is instead 512 bytes long?

Yes, in the bold od -x output you can see that the data starts at 0x200 after a block of zeros. I haven't retested, but I will download and test this morning. I also haven't tested the other converters.

[jnorwood]

I find that the current parser build using cmake, then make doesn't complete on ubuntu 18.04. Has something changed in the build instructions?

std::strncmp requires include of but the link step fails

I'm using cmake v 3.13.3 `/home/jay/NNEF-Tools/parser/cpp/main.cpp:90:19: error: ‘strcmp’ is not a member of ‘std’ if ( std::strcmp(argv[i], "--custom") == 0 )

fixed that with include jay@jay-sk:~/NNEF-Tools/parser/cpp/build$ make Scanning dependencies of target nnef-validator [ 50%] Building CXX object CMakeFiles/nnef-validator.dir/main.cpp.o [100%] Linking CXX executable bin/nnef-validator CMakeFiles/nnef-validator.dir/main.cpp.o: In function main': main.cpp:(.text+0xa2d): undefined reference tonnef::load_model`

[szihs]

I am also getting build link error with latest code.

[gyenesvi]

It seems that nnef.cpp (a new file that contains the implementation of the NNEF parser behind a simplified interface, along with the header nnef.h) was not added to the cmakelist. I have updated it now.

Also, I have included <cstring> header into the main.cpp.

[jnorwood]

ok, the new tools with the fixes built fine. I misinterpreted the odx left column to be bytes ... it is character count in hex. Still, this appears to be a problem ... same as I saw previously .. but it is 512 character header, or 256 bytes. based on what I see here for the squeezenet 1.1, with deploy.prototxt batch changed to 1. So, the problem I see is that the .dat files have a 256 byter header rather than the 128 bytes that is in the spec. caffe_to_nnef deploy.prototxt --model=squeezenet_v1.1.caffemodel jay@jay-sk:~/caffe_squeezenet/converted/fire2_expand1x1$ od -x filter.dat 0000000 ef4e 0001 1000 0000 0004 0000 0040 0000 0000020 0010 0000 0001 0000 0001 0000 0000 0000 0000040 0000 0000 0000 0000 0000 0000 0020 0000 0000060 0000 0000 0000 0000 0000 0000 0000 0000 * 0000200 7a08 be0a ebab be6e 851e 3eca f411 be5e

[jnorwood]

The filter.dat file size is 4224 which is correct number of bytes for the filter size = 64x16 x 4 bytes per fp32 + 128 byte header so, it looks like I'm just misunderstanding the od -x display. I'm going to close this...

[gyenesvi]

I have just been calculating the same, and was about to ask how you know where the header ends and the data starts. But I'm glad it turned out to be okay.

[jnorwood]

with different od parameters, it annotates the header lines counts correctly as bytes, so this is just my error using od.

jay@jay-sk:~/caffe_squeezenet/converted/fire2_expand1x1$ od -A x -t x1z -v filter.dat 000000 4e ef 01 00 00 10 00 00 04 00 00 00 40 00 00 00 >N...........@...< 000010 10 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 >................< 000020 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00 00 >............ ...< 000030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< 000040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< 000050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< 000060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< 000070 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >................< 000080 08 7a 0a be ab eb 6e be 1e 85 ca 3e 11 f4 5e be >.z....n....>..^.<