File sink file size mismatch problem

GNU Radio
1

Hello All,

  A couple of days ago i had installed a GNURadio digital image

processing block that makes an image source and sink block available as
displayed in the image below.
Resource : GitHub - a-w-s/GNURadio-DIP: Digital Image Processing using GNURadio
Flowgraph : http://i.imgur.com/1lJzD.png

The output of the image source and the input to the image sink are
“floats”
only and nothing else. I tried to collect pixel information into a file
sink and i am successful at that but the problem comes in when the size
of
the input file size is not the same as the size of the file sink output.

The image is a basic black and white test image called lena.bmp whose
file
size is 65.0 KB. The link to which is also provided below ,
Resource to Image :
https://www.google.com/search?q=lena+256+x+256&hl=en&prmd=imvns&source=lnms&tbm=isch&ei=_G7GT7vkC4rs8wSG99SaBg&sa=X&oi=mode_link&ct=mode&cd=2&sqi=2&ved=0CD8Q_AUoAQ&biw=1280&bih=827

The file size of the received file (file sink) is 76.0 KB.

The reason why I pay more attention to this is because i intend to
calculate BER / Pixel Error Rate which would take into account a
reference
stream which in this case would be the file with the extra bits , and
Image
sink output ( or the demodulated output) .

Please feel free to ask me any questions that one might have .

Thanks and regards,
Josh.

2

Hey Tom,

I thought i was replying to the list.(Apologies....) I was thinking

about it on similar lines as you have. If the fllow graph is stopped by
hand the latency when i hit stop and when the flow graph stops it should
put some more data but i tried over running the flowgraph for a time
span
of atleast 15 more seconds after the image-sink(fyi the image sink in
this
case is quite different from the gr_file_sink because the image sink
displays the image as soon as the last bit that completes the image is
received.) and that is when i stop the flow graph which brings me to my
next question

Can 1 second bring about a 11KB file change??

Also the flowgraph that i was talking about is as follows.
http://i.imgur.com/1lJzD.png

The reason why i convert a float to char is because when i connect
Image Source (Float) -------> Image Sink (Float)
|
|
|----> File SInk (Float) { Tjhe
size
of the output file was 336KB (6 times the size of the input image).
as opposed to a float to char which got me closer to the actual size of
the
input file. What i was aiming for was to have 2 files of equal size (the
output of the file sink in the above mentioned flow graph and the output
of
the packet decoder at the receiver end and convert those values into
binaries and do a BER .)

Thank you so much again for your help,

Josh.

3

On Wed, May 30, 2012 at 3:04 PM, Josh Stevens
[email protected] wrote:

and i am successful at that but the problem comes in when the size of the
BER / Pixel Error Rate which would take into account a reference stream
which in this case would be the file with the extra bits , and Image sink
output ( or the demodulated output) .

Please feel free to ask me any questions that one might have .

Thanks and regards,
Josh.

Hi Josh,

In general, when doing things like this, there is often some extra
“stuff” that happens because the scheduler works on a per-chunk basis.
So sometimes the size of what’s been processed can be confused a bit,
but if you’re file is only so large, I wouldn’t think this would
happen. Also, 11 KB is a pretty substantial difference in file size.

Do you know where your image is actually located in the output file?
That is, what’s the byte offset? (You could try to read this into
Python with scipy or Matlab and do a correlation to see where in the
file the image exists). I’m just trying to help determine if there’s
some initial fill or if the extra 11 KB are produced at the end of the
file.

Tom