Announcement

Collapse
No announcement yet.

Allow reading and displaying image files without extensions

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    Requested Allow reading and displaying image files without extensions

    Most image files have a type identification in the header. It would be useful if there were an option to allow parsing of the header to determine file type. I run into this problem most often with DICOM files, because in the standard data interchange format that is used for these files, they do not have an extension. However, the file type is clearly stated in the header.

    Yes, it is extra work. So, I would say it should be an option, and not all file types need to be recognized at the first iteration of implementing it. For me, DICOM is by far the most important, but it occasionally happens that even jpeg files lack extensions for some reason or other, probably user error (by somebody else, of course).

    Thanks.

    #2
    You may be aware of this already, there is an option to ask to rename false/missing extensions. There is a message and you can answer yes or no. In either case the image will be shown if recognized by IV.

    The message may be a nuisance when you browse many files of this kind, but it's a start.

    Click image for larger version

Name:	iv_rename_ext.png
Views:	1
Size:	32.5 KB
ID:	83471

    currently running 4.56 / 32 bit

    Comment


      #3
      Originally posted by jazzman View Post
      You may be aware of this already, there is an option to ask to rename false/missing extensions. There is a message and you can answer yes or no. In either case the image will be shown if recognized by IV.

      The message may be a nuisance when you browse many files of this kind, but it's a start.

      [ATTACH=CONFIG]5889[/ATTACH]
      Thanks, but...

      I was not currently aware of that option, but I already have it checked and I see no effect when I attempt to open an extensionless dicom file, either by double click (via shell), by drag and drop, or by file > open. With all those methods, it complains that it can't even read the file header, which is nonsense, because I can easily examine the header in an editor, and the first thing in that header after a bunch of nulls is "DICM". That's probably a separate bug, though.

      I probably should have mentioned that I am using v. 4.53 64bit on win 7.

      Comment


        #4
        Here is the DICOM standard description of the header:

        A fixed 128 byte field available for Application Profile or implementation specified use. If not used by an Application Profile or a specific implementation all bytes shall be set to 00H.

        File-set Readers or Updaters shall not rely on the content of this Preamble to determine that this File is or is not a DICOM File.

        DICOM Prefix

        Four bytes containing the character string "DICM". This Prefix is intended to be used to recognize that this File is or not a DICOM File.

        Comment

        Working...
        X