locked
Error: unable to convert file to SDI

    Question

  • Hi,
      I'm running SparseImageComposer in standalone and I get the following error message:

        Error: unable to convert file to SDI

      It is a big file -- about 5000 images. I've run bigger (up to about 7000 so far). Unfortunately, I have no idea what kind of bad input I'm feeding the tool. I've also never seen the failure -- so I'm not sure at what phase of the composition it fails.

      So, two questions:

      1) What does this error mean?

      2) Is there a way to get the SparseImageTool to write out its dialog updates to standard output rather than pop up a dialog box? That way I could see exactly where it failed. Perhaps if it was scanning a particular image I could see what image was causing the problem...

      Finally, did anythign about the XML format change with the latest XML drop?

      Many thanks!

        Cheers,
            Gordon.
    Gordon
    Wednesday, August 27, 2008 8:03 AM

Answers

  • Hi Gordon,
    No, nothing did change with regards to the XML with the latest build. We do respect aspect ratios and tile sizes better, and we fixed a range of issues where images that fell within a certain range of values (100x100, etc.) produced incorrect tiles.

    That error means that the encoder was unable to generate the image tiles. It could be a particular image variant isn't recognized, but I haven't seen that before. This related to your next question, we unfortunately don't have better error logging in the tools this time around. We will (hopefully) in a future release.

    Cheers!
    Kirupa :)
    • Marked as answer by GordonTWatts Saturday, August 30, 2008 8:35 PM
    Wednesday, August 27, 2008 9:17 PM

All replies

  • Hi Gordon,
    No, nothing did change with regards to the XML with the latest build. We do respect aspect ratios and tile sizes better, and we fixed a range of issues where images that fell within a certain range of values (100x100, etc.) produced incorrect tiles.

    That error means that the encoder was unable to generate the image tiles. It could be a particular image variant isn't recognized, but I haven't seen that before. This related to your next question, we unfortunately don't have better error logging in the tools this time around. We will (hopefully) in a future release.

    Cheers!
    Kirupa :)
    • Marked as answer by GordonTWatts Saturday, August 30, 2008 8:35 PM
    Wednesday, August 27, 2008 9:17 PM
  • Thanks! I'm willing to guess that some image I generated as part of the process is corrupt. At least, that sounds like what the problem is. The difficulty is trying to figure out which image that is of the 5000 or so.

    So -- a follow up question. The Deep Zoom Composer puts up a nice dialog box that shows progress in making the deep zoom image. It seems to run the SparseImageTool - but the SparseImageTool's dialog box is no where in evidence - and it is getting feedback from SparseImageTool. How does that work? Having that sort of feedback might help me track this down...

      Cheers,
        Gordon.

    Gordon
    Saturday, August 30, 2008 8:37 PM
  • Thanks! I'm willing to guess that some image I generated as part of the process is corrupt. At least, that sounds like what the problem is. The difficulty is trying to figure out which image that is of the 5000 or so.

    So -- a follow up question. The Deep Zoom Composer puts up a nice dialog box that shows progress in making the deep zoom image. It seems to run the SparseImageTool - but the SparseImageTool's dialog box is no where in evidence - and it is getting feedback from SparseImageTool. How does that work? Having that sort of feedback might help me track this down...

      Cheers,
        Gordon.

    Gordon
    Saturday, August 30, 2008 8:37 PM
  • Hi,
      I finally have time to get back to this (vacation, moving back to Seattle, and start of school killed me). First I verified that other DZ images that were much larger still worked - they did. So there is something unique about the 5000 images I'm processing here.

      I attached the debugger (VS2008) to the SparseImageTool I was running and got the following stack dump:

    >   SdInterop.dll!Microsoft.LiveLabs.Seadragon.BaseComponent<Seadragon::IImageConverter>.ThrowException(string sMsg, int r) + 0x25 bytes      
        SdInterop.dll!Microsoft.LiveLabs.Seadragon.ImageConverter.ConvertFile(string path, string basename, bool async, object userstate) + 0x754 bytes   
        SdInterop.dll!Microsoft.LiveLabs.Seadragon.ImageConverter.ConvertFile(string path, string basename) + 0xe bytes   
        SparseImageTool.exe!Microsoft.LiveLabs.Seadragon.Tools.SceneGraph.ConvertNodesToSDI(string outPath = "C:\\Users\\gwatts\\AppData\\Local\\Temp\\SIT-Temp1", double maxProgress, Microsoft.LiveLabs.Seadragon.Tools.ConversionProperties convProps) + 0x291 bytes   
        SparseImageTool.exe!Microsoft.LiveLabs.Seadragon.Tools.SparsePyramid.GenerateSDI() + 0x3d2 bytes      
        mscorlib.dll!System.Threading.ThreadHelper.ThreadStart_Context(object state) + 0x66 bytes     
        mscorlib.dll!System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext executionContext, System.Threading.ContextCallback callback, object state) + 0x6f bytes      
        mscorlib.dll!System.Threading.ThreadHelper.ThreadStart() + 0x44 bytes     
        [Frames below may be incorrect and/or missing, no symbols loaded for mscorwks.dll]    
        kernel32.dll!77294911()       
        ntdll.dll!777be4b6()      
        ntdll.dll!777be489()      
     

    Unfortunately, I couldn't figure out how to access that "str" that is passed to the ThrowException method to see what the error is. But the debugger did know about the "$exception" variable. It's message was set to {"IImageConverter::ConvertFile() failed. Details: Failed to create new image"} and was of type System.Exception {System.Runtime.InteropServices.COMException}

    This happens repeatedly.

    Given where this error happens can you tell guess for me if this is my input XML or my input jpeg that is failing? With 5000 images it is a little tedious to check them all. But I'm sure I'm feeding SIT bad information - I just can't tell what I'm doing wrong [I build the input XML automatically; and there is a lot of image size rescaling going on so I could be doing something funny in all sorts of places].

        Cheers,
          Gordon.
    Gordon
    Saturday, September 20, 2008 6:24 PM
  • Hi,
      Ok -- I was able to walk up the stack and find one or two things that weren't optimized away in the released code. Specifically, in the ConvertNotesToSDI I found the following:
    -       this    {Microsoft.LiveLabs.Seadragon.Tools.SceneGraph} Microsoft.LiveLabs.Seadragon.Tools.SceneGraph  
            AspectRatio 1.0 double  
            aspectRatio_    1.0 double  
    +       BackColor   "{Name=ffffffffARGB=(255, 255, 255, 255)}"    System.Drawing.Color  
    +       backColor_  Function evaluation disabled because a previous function evaluation timed out. You must continue execution to reenable function evaluation. System.Drawing.Color  
            cancelRequested_    false   bool  
            ErrorString "Error: unable to convert file to SDI"  string  
            errorString_    "Error: unable to convert file to SDI"  string  
            Nodes   Count = 0x0000163a  System.Collections.Generic.List<Microsoft.LiveLabs.Seadragon.Tools.SceneNode> 
    +       nodes_  Count = Function evaluation disabled because a previous function evaluation timed out. You must continue execution to reenable function evaluation. System.Collections.Generic.List<Microsoft.LiveLabs.Seadragon.Tools.SceneNode> 
            NumNodes    0x0000163a  int  
            numNodes_   5690    int  
    +       pNotifier_  {Microsoft.LiveLabs.Seadragon.Tools.ProgressDlg}    Microsoft.LiveLabs.Seadragon.Tools.IProgressDlgNotifier {Microsoft.LiveLabs.Seadragon.Tools.ProgressDlg}  
            size    Function evaluation disabled because a previous function evaluation timed out. You must continue execution to reenable function evaluation. System.Drawing.Size  
    +       size_   {Width = 0 Height = 0}  System.Drawing.Size  
     

    The formatting isn't exact -- but it is the contents of the "this" variable (the first line is the "this" and in the debugger the following lines are indented because I've hit the "+" sign). The Count is 0x1638 = 5690. I couldn't really explore the nodes_ tree -- that caused the timeout for function evaluation. But the size_ variable looks a little funny (??).

    At any rate, I hope this helps!
    Gordon
    Saturday, September 20, 2008 7:00 PM
  • Hi,
      Ahhh... ignore this whole thread. All of this is connected to the low disk space issue. This DZ image I'm making requires about 20 GB in my user Temp area. I had only 15 GB free on my system disk and thus... I just hadn't noticed the connection previously. I think the problem was that I was running the SIT on a number of very large images rather than lots of small ones.

      I'm very impressed with the lack of limits in the tool. As long as I have the resources availible and am willing to let my computer run for a long period of time, it will work.

      So, I now have a feature request: let me specify the temp directory on the command line to SIT or through some other means. :-)
    Gordon
    Monday, September 22, 2008 6:56 AM