Munching a JPG as a stream

  • Thread starter Thread starter Phil Jones
  • Start date Start date
P

Phil Jones

I'm having problem manipulating a file stream. What I'm doing (simplified
into a sample below) is opening a JPG file as a stream, and then saving it's
contents in a DB. However I seem to be munching the data somehow, because
if I try and save the file from the stream data, the JPG isn't readable.

Here's an example of the code I'm using, that appears to munch the file:

====================
REM -- Open an image.
Dim myImage As New FileStream("C:\TEMP\MyImage.jpg", FileMode.Open)

REM -- Copy to a stream.
Dim buffer(CInt(myImage.Length)) As Byte
myImage.Read(buffer, 0, buffer.Length)
Dim newStream As New MemoryStream(buffer)

REM -- Save stream data to a new file.
Dim newFile As New FileStream("C:\TEMP\Copy.jpg", FileMode.CreateNew)
newStream.Write(buffer, 0, buffer.Length)

REM -- Finish up.
myImage.Close()
newFile.Close()

====================

What am I missing here? Am I screwing up the buffer sizes or something?
Thanks anyone!
 
I put my comments into your code.

Phil Jones said:
I'm having problem manipulating a file stream. What I'm doing (simplified
into a sample below) is opening a JPG file as a stream, and then saving it's
contents in a DB. However I seem to be munching the data somehow, because
if I try and save the file from the stream data, the JPG isn't readable.

Here's an example of the code I'm using, that appears to munch the file:

====================
REM -- Open an image.
Dim myImage As New FileStream("C:\TEMP\MyImage.jpg", FileMode.Open)

REM -- Copy to a stream.
Dim buffer(CInt(myImage.Length)) As Byte
myImage.Read(buffer, 0, buffer.Length)

Note that Read has a return value: it can return with less data than
requested.
Dim newStream As New MemoryStream(buffer)

What's that for?
REM -- Save stream data to a new file.
Dim newFile As New FileStream("C:\TEMP\Copy.jpg", FileMode.CreateNew)

Do you write anything to this file?
newStream.Write(buffer, 0, buffer.Length)

Why do you write the data to the memory stream? It's already in there.
REM -- Finish up.
myImage.Close()
newFile.Close()

====================

What am I missing here? Am I screwing up the buffer sizes or something?

I guess that sample wasn't your real code, was it?
Niki
 
We had some problems which were solved by flushing the streams, you could
try that.

Pj
 
Thanks Niki,

No, just the salient parts that manipulate (or munch) the stream. The
sample makes a copy of the stream and then saves it, which is the
equivalient of putting it within the DB and then getting it back out again.

It's funny, but this code, doesn't hurt MP3 data - which I think has
something to do with the way MP3's work, so it could still be dropping parts
of the data - it's just that an MP3 doesn't break, but a JPG does.

Cheers,
===
Phil
 
Hi Phil,

I think you may try to change your code as bel0ow to see if this help you
to resolved the problem.

Imports System.IO
Module Module1
Sub Main()
REM -- Open an image.
Dim myImage As New FileStream("C:\Test\TestPIC\Blue hills.jpg",
FileMode.Open)
REM -- Copy to a stream.
Dim buffer(CInt(myImage.Length) - 1) As Byte
myImage.Read(buffer, 0, buffer.Length)
Dim newStream As New MemoryStream(buffer)
Dim newFile As New FileStream("C:\Test\TestPIC\Copy.jpg",
FileMode.Create)
REM -- Save stream data to a new file.
newStream.WriteTo(newFile)
REM -- Finish up.
newStream.Close()
myImage.Close()
newFile.Close()
End Sub
End Module

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.
 
Phil Jones said:
No, just the salient parts that manipulate (or munch) the stream. The
sample makes a copy of the stream and then saves it, which is the
equivalient of putting it within the DB and then getting it back out
again.

The trouble is, the sample *doesn't* do that. As Niki said, your
samplewrites to a memory stream (which isn't actually needed anyway)
and doesn't save anything to disk.

This is one of the reasons I advocate writing *complete* sample
programs - you can run them, check the results are still as expected,
and then just cut and paste the complete code.

See http://www.pobox.com/~skeet/csharp/complete.html
It's funny, but this code, doesn't hurt MP3 data - which I think has
something to do with the way MP3's work, so it could still be dropping parts
of the data - it's just that an MP3 doesn't break, but a JPG does.

I think it's probably just luck, to be honest.

See http://www.pobox.com/~skeet/csharp/readbinary.html for some more
info about your problem. The sample code is in C#, but it's fairly easy
to understand what's going on.
 
Point taken. Thanks also for the reference to reading binaries article -
that's useful.

Regards,
===
Phil : New Zealand
 
Back
Top