Re: [Liborigin-devel] OPJU support

[Miquel <gbm...@gm...>]

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...> 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?
> >
>