Write to file (Binary Or Text) EOL problem

[Olivioloyer]

Hi everyone,

I have a problem with both the write to text file and the write to binary file vis,

Even if I deactivate the Convert EOL on the write to text file VI or use the Write to binary file VI I get the same results:

-CR/LF are converted into some blank caracter,

That is a problem because the file I am trying to convert is actually a 2 or 3 jpeg files concatenated and I am trying to extract one of them, write the data to another file to show it on the front panel in a picture control.

The caracters that separates the jpg files is ÿØÿà

See attached Capture which is a comparaison from beyondcompare software and the two files the B86 one is the initial file.

Thanks a lot,

Best Regards.

[Olivioloyer]

Here is the initial file.

Sorry

[Anuar]

Hi Olivioloyer!!

Thanks for using National Instrument's Discussion Forums!!  According to the LabVIEW Help File:

Therefore, you will always get an EOL character when writing a text file using this specific function.  From what I understand, you already have a binary file that contains the info for the three JPEGs you want to extract.  All you are trying to do is extract the data for the three different JPEGs in order to display them using a picture control.  Is this correct??  Why do you have to write the data into three different files after the extraction??  

Can you attach the VI you are using for the extraction of data??  

Hope to hear from you soon!!

[Thoric]

I'm pretty sure "Write to Binary.vi" does not alter then data you provide, and it won't add an EOL character like the write to text. If you think you are seeing an EOL in your resultant file then the equivalent byte for EOL must be in the data you are providing to the data terminal.

 You state that you have characters used to separate the jpeg binary content in the file. This isn't a sensible approach because it's always possible these characters -appear in the actual binary content of the image itself. To write sequential binary lumps to a single binary file requires a dependable approach to determine the true image data length. So I recommend you prepend the jpeg data with an I32 representation of the length of the jpeg image stream. Then when reading this back you can read first this I32 and use it to perform a second read of exactly the right length to load the jpeg image data.