AnsweredAssumed Answered

PNG image corrupted

Question asked by TimButler on Nov 22, 2007
Latest reply on Aug 12, 2014 by iee488

Like • Show 0 Likes0
Comment • 20

Hello there,

I'm using LabVIEW to try and get a screen capture from my DSO6032A. I'm sending the following code:

:DISP:DATA? PNG

The operation seems to complete (scope reads "Remote operation completed") and returns approx. 27kb of data, which I then save after stripping off the 10 byte header. The problem is that when I try and view the image it is corrupted (see attachment), usually from half of the way through but sometimes from the beginning and (very infrequently) the image is almost perfect. If I try getting a BMP

:DISP:DATA? BMP

then the operation works perfectly but the aprrox. 2.4mB file size is prohibitive.

   Has anyone any suggestions?

      Thanks,

           Tim

Attachments

SCOPE.PNG26.8 KB

No one else has this question

Outcomes

20 Replies

dnt Nov 27, 2007 9:00 AM
Mark Correct
Correct Answer
How are you handling the data return? The returned format is BINBLOCK
and if you are not using a canned BINBLOCK parser, such as available
in the Agilent IO libraries VISA COM object, you must parse the BINBLOCK
return yourself.
Like • Show 0 Likes0
Actions
artybear Jul 5, 2011 1:35 PM
Mark Correct
Correct Answer
Hello. I know that this thread is very old. I apologize if I'm supposed to start a new one. The problem I'm having is the same.

I am trying to read the display data, via GPIB, from an MSO6032A. I am able to parse the BINBLOCK format by stripping off the header and the trailing newline. The image transfer works well using the BMP format, but that file size is too big. The PNG data, however, seems to get corrupted. The scope is able to save a correct PNG image directly to a USB drive, so I am able to compare, byte-for-byte, how the GPIB data is different.

The image file is the correct size, and the different parts of the PNG file have the correct types, sizes, and CRC values, which I learned after implementing a parser using information here: http://en.wikipedia.org/wiki/Portable_Network_Graphics. A PNG file is split into "chunks," each of which has a CRC value for checking validity. The data received via GPIB has the same CRC values stored as those in the file saved to the USB drive, but the file transferred over GPIB has data that doesn't match its own CRC. When looking at the image files in a hex-editor, it's apparent that the differences are sparse: in a file of ~27kB, just a 115 bits are corrupted, scattered throughout.

Here is the expected image, which I got by saving to a USB stick, followed by some stats about the file structure:

File: via USB.png
     header: ['89', '50', '4E', '47', '0D', '0A', '1A', '0A']
     chunks:
          Type     Length     Stored CRC     Calculated CRC
          --------------------------------------------
          IHDR     13     903381594     903381594
          IDAT     8192     1551882305     1551882305
          IDAT     8192     1025453588     1025453588
          IDAT     8192     1170855713     1170855713
          IDAT     3086     1713161409     1713161409
          IEND     0     -1371381630     -1371381630
          --------------------------------------------

Here is the image that I got by transferring via GPIB, also with stats about its file structure:

File: via GPIB.png
     header: ['89', '50', '4E', '47', '0D', '0A', '1A', '0A']
     chunks:
          Type     Length     Stored CRC     Calculated CRC
          --------------------------------------------
          IHDR     13     903381594     903381594
          IDAT     8192     1551882305     -1206728792
          IDAT     8192     1025453588     1055614771
          IDAT     8192     1170855713     251794870
          IDAT     3086     1713161409     793817477
          IEND     0     -1371381630     -1371381630
          --------------------------------------------

You can see that all of the IDAT-type chunks (which contain the picture pixel information) have data corruption, but that the other parts are intact.

Note that, in the above code snippets with file stats, the part listed as "header" is the PNG file format header in hexadecimal. It is not the header of the GPIB BINBLOCK transfer (which was discarded before the file was saved).

I thought that maybe there was further bit manipulation required, but I don't see a regular pattern in the differences of the files, and the total success of the BMP format would indicate that my BINBLOCK parsing is working.

Any ideas?

Thanks,
Arthur Hebert
Attachments
- via USB.png27.1 KB
- via GPIB.png27.1 KB
Like • Show 0 Likes0
Actions
bret Jul 8, 2011 6:48 AM
Mark Correct
Correct Answer
I'll give it a try next time when I get a chance, but judging from your sample image, it seems like you are using old firmware? The new interface is blue in color. Assuming your parsing method is correct, the new firmware might have fixed the "bug".

You can search for the latest firmware from the 6000 series website.
Like • Show 0 Likes0
Actions
artybear Jul 11, 2011 10:09 AM
Mark Correct
Correct Answer
Thanks for the reply bret. Indeed I'm running old firmware:

The currently installed versions are:
System: 4.01
Boot: 3.05
Graphics: 1.89

I tried installing the updates from http://www.home.agilent.com/agilent/editorial.jspx?cc=US&lc=eng&ckey=802477&nid=-33565.536905496&id=802477. When I press the load button on the first file, sys6000.jzp, it shows a progress bar for about 10 seconds, then stops and says "Invalid file. Loading canceled."

I have verified that the file size is correct, and I tried downloading twice to make sure. Any suggestions on how to proceed?
Like • Show 0 Likes0
Actions
bret Jul 11, 2011 8:02 PM
Mark Correct
Correct Answer
Hello ...

I tried saving a PNG using ":DISP:DATA? PNG" via both GPIB (GPIB to USB converter, though) and LAN, and it worked.

As for the firmware upgrade, try the "If the 5000 or 6000 Series oscilloscope will not boot up" section in

http://www.home.agilent.com/agilent/edi ... &id=670496

I'm guessing your current firmware is too old since it is 2 major revisions behind.

Hope this helps.
Like • Show 0 Likes0
Actions
artybear Jul 11, 2011 9:31 PM
Mark Correct
Correct Answer
I ran through the instructions on the troubleshooting page, still unable to install the new firmware. I copied sys6000.bin and sys6000.jzp to the root of my USB thumb drive, and booted with it as described. Then the front panel blinked it the button backlights, continuously cycling from the bottom buttons to the top. I let it run like that for 35 minutes with no progress.

Is there something else I should look for that I'm doing wrong?

Thanks!
Arthur
Like • Show 0 Likes0
Actions
bret Jul 12, 2011 6:29 AM
Mark Correct
Correct Answer
Hi Arthur,

I'm no expert in this area and I might make things worse for you, so hopefully someone from Agilent in this forum can provide a solution to the firmware-upgrade problem.

But I experimented a bit, and managed to boot an older firmware from my archives directly from USB to prove that the troubleshooting guide really works. But I did that without the sys6000.bin, just the sys6000.jzp. So, maybe you want to try deleting the .bin and give it another shot? Also, remember to switch off the instrument after 4 seconds (roughly when the Run/Stop LED lights up) ... I'm sure you did that, but just re-iterating Another thing to try is change USB sticks as mentioned in the guide.

Let me know if that works

bret
Like • Show 0 Likes0
Actions
artybear Jul 12, 2011 11:19 AM
Mark Correct
Correct Answer
It worked! New firmware fixed the problem, and PNG files transfer correctly over GPIB.

The firmware finally loaded. Seemingly I took the same steps, but things always work better when tech support is on the line.

Sample screen shot:

Bret, thank you very much for your help!
Attachments
- scope.png74.0 KB
Like • Show 0 Likes0
Actions
- johnc_fes @ artybear on Apr 2, 2013 6:12 AM
  Mark Correct
  Correct Answer
  I am having problems copying over the image data and I found this topic. I am using LabVIEW 2010 and I am able to generate the .png file, it is ~21kb, same size as the images saved to a USB stick. But when I try to open the file, it says it is corrupt. I would greatly appreciate if you guys could share the VI file that you have working. I am using a MSO-X 3014A, and I have been able to do just about everything I need EXCEPT for successfully saving this image. I tried saving it as .bmp also and still received the corrupt message when trying to open it. Thank you so much in advance for any help.
  
  P.S. I just updated the firmware and I still receive the corrupt message when opening the image files on my Windows 7 machine. I have attached the VI file that generates the corrupted image file.
  
  Edited by: johnc_FES on Apr 1, 2013 1:41 PM
  
  Edited by: johnc_FES on Apr 2, 2013 7:09 AM
  Attachments
  - Acquire Screen Capture (2).vi14.9 KB
  Like • Show 0 Likes0
  Actions
  - bret @ johnc_fes on Jun 19, 2013 8:08 AM
    Mark Correct
    Correct Answer
    Nobody with LabView knowledge to help out?
    
    Anyway, I believe LabView will eventually use :DISP:DATA?, which has been proven to be working. You'll just need to ensure the returned bytes are arranged correctly to construct the PNG file. The examples of :DISP:DATA? in the programming guide is a start. You could also compare the bytes returned by :DISP:DATA? with the PNG file that you save directly using a USB drive to gain some insight on what is wrong.
    Like • Show 0 Likes0
    Actions
  - hognala @ johnc_fes on Jul 1, 2013 12:53 PM
    Mark Correct
    Correct Answer
    The fundamental problem that you were facing, was that you were sending more than just the picture data to the file. The :DISP:DATA? query returns the data in an IEEE Binary Block format, which needs to be trimmed off of the actual data stream. I've attached a modified .vi, as well as a sub .vi to do the data trimming.
    
    Also, it looks like you were trying to grab a .png file, but were specifying BMP as the file format to use in the SCPI command. I changed that as well.
    Attachments
    Acquire Screen Capture (2).vi15.7 KB
    Remove Binary Block From Screenshot Data.vi14.2 KB
    Like • Show 0 Likes0
    Actions
    - iee488 @ hognala on Aug 12, 2014 9:02 AM
      Mark Correct
      Correct Answer
      > {quote:title=hognala wrote:}{quote}
      > The fundamental problem that you were facing, was that you were sending more than just the picture data to the file. The :DISP:DATA? query returns the data in an IEEE Binary Block format, which needs to be trimmed off of the actual data stream. I've attached a modified .vi, as well as a sub .vi to do the data trimming.
      >
      > Also, it looks like you were trying to grab a .png file, but were specifying BMP as the file format to use in the SCPI command. I changed that as well.
      
      Found this thread during a Google search.
      
      Your answer is very helpful.
      
      Can you explain or point me to information about the IEEE Binary Block format?
      I would like to understand what the trimming VI is doing.
      Thank you.
      Like • Show 0 Likes0
      Actions
augustine Jul 24, 2013 3:23 AM
Mark Correct
Correct Answer
Can these PNG images be restored if we using a professioan [url=http://www.rasteredge.com/how-to/csharp-imaging/imaging-processing/]image processing and manipulation tools[/url] by sending no more data than just the picture data to the file and changed to the correct SCPI commands?

Edited by: Augustine on Jul 24, 2013 4:22 AM
Like • Show 0 Likes0
Actions
uncleben Oct 21, 2013 2:58 AM
Mark Correct
Correct Answer
Hi there

I am having the same problem too. I tried to get the PNG image to my pc through GPIB and somehow I could't open the PNG file. I think the problem is how I handled the returned value from the command ":DISPlay:DATA? PNG, SCReen, COLor". I wrote the code in VB6. Can someone show me how to handle the returned value in VB6 coding?

Appreciate ^^
Like • Show 0 Likes0
Actions
- hognala @ uncleben on Oct 21, 2013 10:47 AM
  Mark Correct
  Correct Answer
  Here's the code to get a screenshot using VB6 (or VBA) using VISA COM or VISA:
  
  *'VISA COM code*
  
  Function GetScreenshotWithVISACOM()
  
  'Setup the connection
  Dim grm As New VisaComLib.ResourceManager
  Dim fmio As New VisaComLib.FormattedIO488
  
  Set fmio.IO = grm.Open("TCPIP0::156.140.113.105::inst0::INSTR", NO_LOCK, 0, "")
  
  'Send the command to get the screenshot
  fmio.WriteString ":DISP:DATA? PNG,SCR,COL", True
  
  'It takes a while on this scope (MSO 6000),
  ' so set the timeout to 10 seconds
  fmio.IO.timeout = 10000
  
  'Read back the screenshot
  Dim screenshot() As Byte
  screenshot = fmio.ReadIEEEBlock(BinaryType_UI1, True, True)
  
  'Close the connection to the instrument
  fmio.IO.Close
  
  'Save the file to disk
  Open "c:\screenshot.png" For Binary Access Write As #1
  Dim writePosition As Integer
  writePosition = 1
  Put #1, writePosition, screenshot
  Close #1
  
  End Function
  
  *'VISA code*
  
  Function GetScreenshotWithVISA()
  
  'Setup the connection
  Dim rm As Long
  Dim vi As Long
  
  Call viOpenDefaultRM(rm)
  Call viOpen(rm, "TCPIP0::156.140.113.105::inst0::INSTR", 0, 0, vi)
  
  'Send the command to get the screenshot
  Call viVPrintf(vi, ":DISP:DATA? PNG,SCR,COL" + vbLf, 0)
  
  'It takes a while on this scope (MSO 6000),
  ' so set the timeout to 10 seconds
  Call viSetAttribute(vi, VI_ATTR_TMO_VALUE, 10000)
  
  'Read back the screenshot
  Dim returnCount As Long
  returnCount = 100000
  Dim screenshot(100000) As Byte
  Dim paramsArray(2) As Long
  
  paramsArray(0) = VarPtr(returnCount)
  paramsArray(1) = VarPtr(screenshot(0))
  
  Call viVScanf(vi, "%#b" + vbLf, paramsArray(0))
  
  'Close the connection to the instrument
  viClose (vi)
  viClose (rm)
  
  'Save the file to disk
  Open "c:\screenshot.png" For Binary Access Write As #1
  Dim writePosition As Integer
  writePosition = 1
  Put #1, writePosition, screenshot
  Close #1
  
  End Function
  Like • Show 0 Likes0
  Actions
  - uncleben @ hognala on Oct 21, 2013 7:09 PM
    Mark Correct
    Correct Answer
    Thanks Hognala.
    
    For the VISA COM code, I have tried something similar before but I couldn't call the ReadIEEEBlock function even though I have used "VISA COM 3.0 Type Library" and "VISA COM 488.2 Formatted I/O 1.0" as references. Just don't why.
    Anyways I will try your VISA code later on today. thanks once again for your help.
    Like • Show 0 Likes0
    Actions
  - uncleben @ hognala on Oct 22, 2013 12:45 AM
    Mark Correct
    Correct Answer
    Hi Hognala,
    
    The VISA code work perferctly. Thank u so much.
    Anyways I was thinking if it is not too troublesome for u, can you explain the actions behind the coding (Read back the screen shot section)? I tried to understand it but when I looked at the discription of "VarPtr()", the pop-out windon in VB6 stated "It is hiden".
    
    'Read back the screenshot
    Dim returnCount As Long
    returnCount = 100000
    Dim screenshot(100000) As Byte
    Dim paramsArray(2) As Long
    
    paramsArray(0) = VarPtr(returnCount)
    paramsArray(1) = VarPtr(screenshot(0))
    
    Call viVScanf(vi, "%#b" + vbLf, paramsArray(0))
    Like • Show 0 Likes0
    Actions
    - hognala @ uncleben on Oct 22, 2013 8:28 AM
      Mark Correct
      Correct Answer
      Uncle Ben, here you go....
      
      The viVScanf and viVPrintf functions have pretty good VB6 documentation in the Agilent VISA Help file.
      
      Basically we want to pass 2 parameters to the viVScanf function: returnCount and the screenshot array.
      *returnCount* is probably not a good name because it actually provides data to the function (how big is the array that I am passing in), AND it also returns how many bytes were written into the array by the function.
      *screenshot* is obviously where the screenshot bytes get written.
      
      To pass 2 parameters into the function we create an array of Pointers, *paramsArray*. Pointers are not something that VB6 devs deal with often. Think of it as the address of where in memory the variables are. Then we pack our two variables into *paramsArray* using the *VarPtr(...)* function. Since returnCount is a single item, we just pass it into VarPtr and VarPtr passes back the pointer to its location in memory. screenshot is an array, so we pass in the location of the first datapoint to VarPtr.
      
      Then on to the viVScanf call. The second parameter *%#b* is interesting, and probably the hardest to understand. It makes more sense I think if you are a C programmer. The *%* says that whatever comes in after this will be replaced by variables passed in subsequent parameters to the viVScanf function. *#* says to read the next variable for how many bytes to read from the next parameter. The *b* says to read data and expect it to be an array of bytes in the IEEE Definite-Length Binary Block format. The VISA documentation for the viScanf function has more details on what format characters/modifiers you can use.
      
      The end result is that the viVScanf function knows how much data to expect, knows how that data is going to be formatted and reads it from the device.
      
      Let me know if any of that is unclear (I think this is probably the most complex piece in all of VISA)
      
      Alan
      Like • Show 0 Likes0
      Actions
      - uncleben @ hognala on Oct 22, 2013 6:13 PM
        Mark Correct
        Correct Answer
        Hognala, thanks for your explanation.
        
        Let’s see if I get this right.
        paramsArray(0) = VarPtr(returnCount) --> gets 100000 address in memory
        paramsArray(1) = VarPtr(screenshot(0)) --> stores the screenshot data byte by byte into the memory space created in previous line.
        
        Call viVScanf(vi, "%#b" + vbLf, paramsArray(0))
        % -->still unclear to me;
        # -->read next variable and the variable shows how big the screenshot is (how many bytes the screenshot contains). So when reading process starts, it will read from first byte to the last byte. It sort of gives the reading process a start point and an end point.
        b --> read the data in byte format
        
        Am I getting it right?
        Like • Show 0 Likes0
        Actions
danik Nov 20, 2013 8:04 AM
Mark Correct
Correct Answer
I`ve had the same problem. I couldn’t open photos, which I made by my old camera in computer, because they were damaged. After this I try to recover photos with special programs, but mostly of them didn`t see cameras flash driver. To recover photos I can advise you to use program hetman repair. You can find it here http://hetmanrecovery.com/download.htm
Besides this check your camera. May be reason in it.
Like • Show 0 Likes0
Actions

PNG image corrupted

Attachments

Outcomes

Attachments

Attachments

Attachments

Attachments

Related Content

Recommended Content