unknown zlib header (.vrscene) - zlib

This is format description of Vray's .vrscene file:
http://spot3d.com/vray/help/maya/sdk22/vrscene_format.html
I interested in paragraph about "Compressed hexadecimal lists". There is said that compressed list equals to header ("ZIPB") + uncompressed size + compressed size + zlib compressed string.
For example, in my .vrscene I have such compressed list: "ZIPB2C01000015000000e7X81OT0TG4S5ENN3D8Z8IVAPODONF7EA"
It means that "e7X81OT0TG4S5ENN3D8Z8IVAPODONF7EA" -- zlib compressed string. But I dont know how to decompress it. When I do Base64 decode I receive header 0x7bb5. I dont know such a header. Maybe I shouldnt use Base64 and should do something other instead?

So I know this is old, but the information in here was enough to get me to a solution, the only difference being that I have a different compressed list from a different vrscene file.
As you established, you need to remove the first 20 characters from the string since they are just descriptors used by vray and not part of the compressed data.
import base64, zlib
data = "ZIPCB81900003C000000eAHt0iERAAAMxLDC9694MkYCaqCXVZMHDDDAAAMMMMAAAwwwwAADDDDAAAMMMMAAAwwwwMC7gQMbojNx"
encoded_data = data[20:] #"eAHt0iERAAAMxLDC9694MkYCaqCXVZMHDDDAAAMMMMAAAwwwwAADDDDAAAMMMMAAAwwwwMC7gQMbojNx"
compressed_data = base64.b64decode(encoded_data)
hex_data = zlib.decompress(compressed_data)
# b'\x08\x00\x00\x00\x08\x00\x00\x00\x08\x00\x00\x00\x08\x00\x00\x00\x08\x00\x00\x00\x08\x00\x00\x00\x08\x00\x00\x00\x08\x00\x00\x00\x08\x00\x00\x00...'
Once you are at this point you have the raw hexidecimal list without any compression. If you want to turn that into readable python data types you can use struct to unpack them depending on what data type is stored in the list.
Further reading in the documentation that was linked explains that all such lists are stored as 4 bytes per entry (written as 8 half-bytes in the docs, but as far as python is concerned it's just 4 bytes). With that information we can determine that the number of entries in the list should be the length of the hex_data / 4 and build a struct format string that will unpack the whole list at once.
import struct
#I have a list of ints as my example, but for floats you could use "f" instead
format = "i" * int(len(hex_data)/4)
values = struct.unpack(format, hex_data)
# [8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, 8, ...]
There are also Color lists and Vector lists, but they are just float lists that need to be unflattened.
vectors = []
for i in range(0, int(len(values)), 3):
vectors.append(tuple(values[i:i+3]))
Since this method seems to be working with all of the compressed hex lists I've been encountering up to this point it seems like there is either an issue with the file you were originally trying to parse data from, or the developers were using an encoding method other than base64 at one point but have adopted base64 encoding since then (Perhaps that's the reason for "ZIPC" appearing in my files as opposed to "ZIPB in your example).

The documentation says hexadecimal, but the string you provided has other characters. It is probably not base64, since you don't get a valid zlib header at the start. (By the way, I get 0x7b 0xb5 when I decode it with base64, not what you got. But either way, it's not a zlib header.) Do you have a better source for the description of the format?
The data must have been highly compressible, e.g. all zeros, since it apparently went from 4140 bytes to 21 bytes.

Related

nanopb - how to specify encoding of integer in proto file

How do I set a int32 to use a fixed size for encoding?
In the API, it says
PB_LTYPE_FIXED32 0x04 32-bit integer or floating point.
But what option do I set in the .proto file to encode a int32 as a PB_LTYPE_FIXED32 as opposed to a PB_LTYPE_VARINT?
In the function encode_basic_field the fields structure, which is autogenerated, stores the field type which means that this information is set in .proto file somehow.
I think you should try "int32_t" instead of int32.
please check the "nanopb" project, in the file "nanopb_generator.py", there is a dictionary called "datatypes", here is some code:
FieldD.TYPE_FIXED32: ('uint32_t', 'FIXED32', 4, 4),
FieldD.TYPE_SFIXED32: ('int32_t', 'SFIXED32', 4, 4),
because it's my first time to see the "nanopb" project, I'm not 100% sure whether it will work or not.

Convert a raw sequence of N x M values into a proper image format with minimal effort

I have a file with a sequence of NxM unsigned integral values of fixed width - let's even assume they're single bytes - and I would like to "wrap" in some kind of common image file format. Preferably, something usable with popular image viewers; and otherwise with an image editor like GIMP.
What image format would require the minimum amount of conversion work, i.e. be as close as possible to just slapping some small header onto the raw data?
Notes:
This is a grayscale/intensity image - there are no color channels / interleaved values etc.
I don't care if the image format is row-major or column-major, i.e. if the image appears transposed relative to the order I wrote the data originally.
I've just noticed the Portable Pixmap Formats, which include the PGM format. The closest I've seen to a spec is on this page.
PGM files are supported by apps such as: Eye of Gnome (on Linux), IrfanView (on Windows), GIMP and others.
Create the image file programmatically
If I understand correctly, the following C function should convert the raw data OP has into a PGM file:
void write_pgm(FILE* file, size_t width, size_t height, uint8_t* data)
{
const char magic = "P5"; // for binary graymap
fprintf(file, "%2s %zu %zu 255\n", magic, width, height);
fwrite(data, 1, width * height, file);
}
This is a variation on a similar function for a PPM, here.
You can easily adapt this to whatever programming language you like.
Converting a file
So, suppose you've put your output in a file on disk. Apparently, there's a utility for making a PGM of it: rawtopgm. Here's a invocation for your case:
rawtopgm -bpp 1 -maxval 255 N M my_data_file > out.pgm
or, exploiting defaults:
rawtopgm N M my_data_file > out.pgm
pretty simple.

How to check the given file is binary file or not in C programming?

I'm trying to check the given file is binary or not.
I refer the link given below to find the solution,
How can I check if file is text (ASCII) or binary in C
But the given solutions is not working properly, If I pass the .c file as argument, Its not working, It gives wrong output.
The possible files I may pass as argument:
a.out
filename.c
filename.txt
filename.pl
filename.php
So I need to know whether there is any function or way to solve the problem?
Thanks...
Note : [ Incase of any query, Please ask me before down vote ]
You need to clearly define what a binary file is for you, and then base your checking on that.
If you just want to filter based on file extensions, then create a list of the ones you consider binary files, and a list of the ones you don't consider binary files and then check based on that.
If you have a list of known formats rather then file extensions, attempt to parse the file in the formats, and if it doesn't parse / the parse result makes no sense, it's a binary file (for your purposes).
Depending on your OS, binary files begin with a header specifying that they are an executable and contain several informations about them (architecture, size, byte order etc.). So by trying to parse this header, you should know if a file is binary or not. If you are on mac, check the Mach-O file format, if you are on Linux, it should be ELF format. But beware, it's a lot of documentation.

Write File byte[] array received from C# to a file in C dll

I just created a simple PDF Document containing a word "Test" in it and created a byte stream out of it in C# Console Application:
buff = File.ReadAllBytes(<Path of File>);
The size of the file is around 9,651 bytes. I also created a Win32 C dll that exports a function which takes the file byte array and the length of the byte array as an argument, declared in C# using this:
[DllImport("<path to dll>", CallingConvention = CallingConvention.Cdecl)]
public static extern int file_data(byte[] byteArray, int length);
The method in C dll is exported as below:
#define FILEDATA_API __declspec(dllexport)
FILEDATA_API int file_data(char *byteArray, int size);
I then invoked ret = file_data(buff, buff.length); and in the C code, wrote the character pointer received directly to a temp file character by character as below:
while (length> 0)
{
fprintf(outFile, "%c", *fileData); //fileData is the actual byte array received from C# Code
fileData++;
length--;
}
But the problem arises here, the C code that dumps out the byte array to a file character by character generates a file of size 9,755 bytes. Most of the content inside it seems to look correct, except some new lines that gets introduced(as far as i know and may be some additional data), which causes the PDF file to get corrupted and this dumped out version does not open in Adobe. Can someone please provide some pointers on where I might be going wrong? I cannot use %s in fprint since some combination of the byte array in the PDF results in null terminated string in C which then dumps out even lesser data than I expect.
Thanks.
UPDATE:
The desired behavior is that the file byte array as received from C#
and when written using C code to a file should make the file open
successfully in Adobe.
The code present in the problem should be
sufficient for someone to generate a win32 dll, that simply writes
out the char pointer to a file, but I have added few more details.
You're probably calling fopen without the b mode flag. Append b to your mode specifier:
FILE *outFile = fopen("file.txt", "wb")
From this site (emphasis mine):
Text files are files containing sequences of lines of text. Depending on the environment where the application runs, some special character conversion may occur in input/output operations in text mode to adapt them to a system-specific text file format. Although on some environments no conversions occur and both text files and binary files are treated the same way, using the appropriate mode improves portability.
In my experience, this "conversion" on Windows changes \n to \r\n at least.

sdl ttf windows-1250 encoding

In file text.txt I have this sentenc:
"Příliš žluťoučký kůň úpěl ďábelské ódy."
(I think Windows uses Windows-1250 code page to represent this text.)
In my program I save it to a buffer
char string[1000]
and render string with ttf to SDL_Surface *surface
surface = TTF_RenderText_Blended(font, string, color);
/*(font is true type and support this text)*/
But it gives me not correct result:
I need some reputation points to post images
so I can only describe that ř,í,š,ž,ť,ů,ň,ď are not displayed correctly.
Is it possible to use ttf for rendering this sentence correctly?
(I tried also TTF_RenderUTF8_Blended, TTF_RenderUNICODE_Solid... with worse result.)
The docs for TTF_RenderText_Blended say that it takes a Latin-1 string (Windows-1252) - this will be why it isn't working.
You'll need to convert your input text to UTF-8 and use RenderUTF8, or to UTF-16 and use RenderUNICODE to ensure it is interpreted correctly.
How you do this depends on what platform your app is targeted to - if it is Windows, then the easiest way would be to use the MultiByteToWideChar Win32 API to convert it to UTF-16 and then use the TTF_RenderUNICODE_Blended to draw it.
My solution will be this:
Three input files. In first file there will be a set of symbols from czech alphabet.
Second file will be sprite bitmap file where graphic symbols will be sorted in the
same order as in first file. In my program symbols from third input file will be compared with symbols from first file and right section of sprite will be copied on sreen one by one.
I will leave out sdl_ttf. It has some advantages and disadvantages but I think it will work for my purposes.
Thanks for all responses

Resources