Menu
▾
▴
Re: [Liborigin-devel] OPJU support
|
From: Stefan G. <ste...@un...> - 2020-04-20 11:54:26
|
Thank you very much. Can you comment on the tools that you used to reverse-engineer the OPJ format for anyone who wants to start a parser for the OPJU format? That would be great :-) best wishes Stefan On 2020-04-18 11:24, Miquel wrote: > Not much else to comment on. The OPJ and OPJU formats are quite different. > One way to get the data from an OPJU file is by converting it to the older OPJ format [1] > > best regards, > Miquel > > [1] https://www.originlab.com/doc/Quick-Help/Convert-OPJU-Project-File-Format-to-Older-OPJ > > Missatge de Stefan Gerlach <ste...@un... <mailto:ste...@un...>> del dia dl., 13 d’abr. 2020 a les 21:28: > > Dear Ivan, > > sorry for the late reply. > You are right, the OPJU format seems to be very different than the old OPJ format. Maybe Miquel can comment on that because he did most of the > parsing work. I'm not familiar with the methods to revers-engineer the format, but i would like to hear about that too :-) > > best wishes > Stefan > > On 2019-08-24 19:39, Ivan Krylov wrote: > > Dear liborigin maintainers, > > > > How different is the new OPJU format from OPJ? How much is known about > > it? I have noticed that the library checks for the new "CPYUA" header, > > but the OPJU files I have are impossible to parse, and a cursory glance > > at the files suggests that they are, indeed, very different. For > > example, there is far less 0x0a bytes in OPJU files than in > > corresponding OPJ files, and the encoding seems to be much more > > compact, although similar byte patterns crop up now and then: > > > > OPJ: > > > > 00170620 0A 63 6F 6C 28 43 4A 29 .........col(CJ) > > 00170630 2A 32 2E 33 30 33 2F 30 2E 30 33 00 00 0A 00 00 *2.303/0.03..... > > 00170640 00 00 0A 00 00 00 00 0A 6F 00 00 00 0A 00 00 06 ........o....... > > 00170650 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > > 00170660 5C 8F C2 F5 28 5C EE 3F DB B6 6D DB B6 6D AB 3F \...(\.?..m..m.? > > 00170670 14 00 00 00 00 10 01 3E 00 3E 00 C2 FF C2 FF 00 .......>.>...... > > 00170680 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > > 00170690 00 00 00 47 52 31 00 00 00 00 00 00 00 00 00 00 ...GR1.......... > > 001706A0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ > > 001706B0 00 00 00 00 00 00 00 00 00 00 00 00 0A 14 00 00 ................ > > 001706C0 00 0A ..col(CI)*2.303/ > > > > OPJU: > > > > 000FBE70 0A 63 6F 6C 28 43 4A 29 2A 32 2E 33 30 33 2F ..col(CJ)*2.303/ > > 000FBE80 30 2E 30 33 00 00 0A 00 00 00 00 0A 00 00 00 80 0.03............ > > 000FBE90 2C 03 00 00 06 8D 11 5C 8F C2 F5 28 5C EE 3F DB ,......\...(\.?. > > 000FBEA0 B6 6D DB B6 6D AB 3F 14 81 0A 10 01 3E 00 3E 00 .m..m.?.....>.>. > > 000FBEB0 C2 FF C2 FF 91 03 47 52 31 A5 01 08 90 00 00 14 ......GR1....... > > 000FBEC0 00 00 00 0A ....col(CI)*2.30 > > > > For example, some short strings are prefixed with their length instead > > of being surrounded by NUL bytes, like 0x03 "GR1" in the example above > > or 0x07 "Book2_B" elsewhere in the same file. > > > > The data might also be compressed, since gnuplot commands > > > > plot for [i=0:7] 'file.opju' binary array=(-1) format="%double" skip=i not > > > > or > > > > plot for [i=0:3] 'file.opju' binary array=(-1) format="%float" skip=i not > > > > don't seem to reveal any structure, unlike they did for OPJ files (in > > the latter case, if I know typical range of values stored in the file > > and set it manually before plotting, I can usually see the data as they > > appear in the file). > > > > Is there a known methodology one could use to adapt the parser for > > the new format? > > > |
