>
> On Sun, Jun 3, 2012 at 11:53 AM, Josh Stevens <
address@hidden>
> wrote:
>>
>> Hey Tom,
>> Thank you for replying .
>>
>> So here is how i do the conversion. The packet decoder is connected to the
>> image sink and file sink. The moment the output is displayed on the screen i
>> stop the flowgraph at the receiver side and the size of the
>> "received_file.dat" is achieved to be 64 KB (which is 1KB smaller in size
>> and still not exact but is considerably better as opposed to a 11KB
>> difference). I then use python command to convert this file into a readable
>> format by using numpy.fromfile and throw in the name of the file as the
>> first argument to the same but the dtype i choose is int8 . The received
>> file contains values ranging from 0-127 since the image is choose is a Black
>> and White image which when converted to binary would be 8 bits which also
>> explains the range(0-127) .
>>
>> About the question that you asked , the extra bits that are added , are
>> added to the end of the file , for example in this case the received file
>> contains 65536 ( 64*1024) and these bytes match the first 65536 bytes of the
>> numpy int8 converted transmitted file but the other 10,000 or so bytes are
>> just different numbers but all within the 0-127 range .
>>
>>
>> Thanks again and Kind regards,
>> Josh.
>>
>> On Sun, Jun 3, 2012 at 10:41 AM, Tom Rondeau <
address@hidden> wrote:
>>>
>>> On Wed, May 30, 2012 at 3:04 PM, Josh Stevens <
address@hidden>
>>> wrote:
>>> > 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 :
https://github.com/a-w-s/GNURadio-DIP
>>> > 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.
>>>
>>> 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
>>
>>
>