PICT images with missing rows and columns

[j-p-sequeira]

This is a barely noticed issue. I have come across a PICT issue where a single row and column is missing from the generated image. It is better seen in non-photo images (like the drawing in the following example).

The PICT images I have were created by me with Photoshop and are displayed properly in Photoshop (I have no other app for handling PICT images).

Here is an example where a row (at +/- 352px) and a column (at +/- 354px) are missing (the column is harder to spot because there are only 2 points where it affects the girl and 1 of these matches the row issue):

The overall size of the image is correct, so the problem results in the last column and row to be transparent.

Either two things are happening while reading the image: or the row and column are skipped or they overwrite a previously read row and column. After a quick glance, it seems the first scenario (though I can't understand what's really going on).

Not related to this issue, but I have been wanting to ask, is the ".PIC" format that Twelve Monkeys can read referring to the "PICT - Apple Picture" format or to the "HDR - High Dynamic Range" format?

PS: I'll attach the original PCT file.
pict-example.zip

[haraldk]

Hi José,

Thank you for reporting and providing a sample file! I can reproduce the problem here. I will look into it in more detail later. Seems like some kind of rounding error or so.

About the ".pic" file extension, it could mean many formats. But the only TwelveMonkeys plugin that claims to read it, is the HDRImageReader. So, yes, it's the latter, "Radiance RGBE High Dynaimc Range (HDR)".

--
Harald K

[haraldk]

PS: For reference, can you please open the above PICT file in Photoshop, convert it to PNG and attach it here?

--
Harald K

[j-p-sequeira]

No, I am the one who should thank you! Great work you're doing here. I am all excited waiting for version 3.4, can't wait to include it in my viewer Meew.

About the ".pic" file extension, it could mean many formats. But the only TwelveMonkeys plugin that claims to read it, is the HDRImageReader. So, yes, it's the latter, "Radiance RGBE High Dynaimc Range (HDR)".

Great, I made a wild guess in Meew and I associated the PIC with the HDR. Glad I was right. However, the way it is coded, the extension is ignored when getting an ImageReader, so an Apple PICT ending with .PIC will be correctly read as well, even though it will display this in the info window as the type:

PIC Image (RGBA) [image/x-pict] - HDR - High Dynamic Range

The later part is incorrect (the later part is the SO file description) because during setup I associate the PIC with HDR. I also group PIC with HDR for file filters when showing the opening dialog. Though I've always wonder if it was the right choice, at least I'm more at ease now.

PS: For reference, can you open the above PICT file in Photoshop, convert it to PNG and attach it here?

Sure, here goes:

[haraldk]

Thanks!

I think I have it fixed now, by rounding the x/y coordinates, instead of truncating by casting. I think it should make it to 3.4.

Re. PIC: Determining file format by file extension is never safe, so you should probably do it by data inspection instead. Also, it really is Radiance RGBE (not RGBA) HDR format, see Wikipeida. There are many other formats capable of HDR, although the Radiance format was one of the first, and thus has wide support.

PS: The Mime type for the Radiance RGBE format isn't "image/x-pict", that is an unofficial extension mime-type (as is always for "image/x-something") for PICT. The correct mime is "image/vnd.radiance".

--
Harald K

[j-p-sequeira]

Beautiful!!! It would be very sweet to see this fixed in 3.4 : ) Many thanks.

Oh, yes, that was the example of a .PIC that wrongly held a PICT image instead of HDR, but thank you for caring. For true HDR pictures I get this:

HDR Image (RGBE) [image/vnd.radiance] - HDR - High Dynamic Range

The first part and mime-type should always be shown correctly (I hope), the description is retrieved from the SO, so it will be incorrect if the extension is wrong. But I want it there so I can easily see that the extension is incorrect for the file (when there is a mime and description mismatch). For the mime-type, I had problems getting it right (all Java methods seem to only care about the extension and the one that truly probed the file contents only supported 3 or 4 formats, ugh) and the way I got to solve this was "cheating a bit". Since the proper image reader is always loaded for the input stream, I do something like this (not exactly, since I also do a check to strip the point before the extension, that it shouldn't be there, but just in case):

ImageInputStream stream = ...;
Iterator<ImageReader> readersIterator = ImageIO.getImageReaders(stream);
ImageReader reader = ...; // Select one of the available readers, actually I have a method to prefer Java or 3rd party based on an user configuration setting
String lowerCaseType = reader.getFormatName().toLowerCase();

switch (lowerCaseType) {
    case "psd":
        mymeType = "image/vnd.adobe.photoshop";
        break;
    case "wbmp":
    case "wbm":
        mymeType = "image/vnd.wap.wbmp";
        break;
    case "hdr":
    case "rgbe":
    case "xyze":
    case "pic":
        mymeType = "image/vnd.radiance";
        break;
    case "ico":
    case "cur":
        mymeType = "image/x-icon";
        break;
    case "pcx":
    case "dcx":
        mymeType = "image/x-pcx";
        break;
    case "pict":
    case "pct":
        mymeType = "image/x-pict";
        break;
    case "tga":
    case "targa":
    case "tpic":
        mymeType = "image/x-targa";
        break;
    case "pmb":
        mymeType = "image/x-portable-bitmap";
        break;
    case "pgm":
        mymeType = "image/x-portable-graymap";
        break;
    case "ppm":
        mymeType = "image/x-portable-pixmap";
        break;
    case "pam":
        mymeType = "image/x-portable-anymap";
        break;
    case "j2k":
        mymeType = "image/jp2";
        break;
    case "hdp":
    case "wdp":
        mymeType = "image/jxr";
        break;
    case "wmz":
        mymeType = "image/wmf";
        break;
    case "emz":
        mymeType = "image/emf";
        break;
    default:
        mymeType = "image/" + lowerCaseType;
}

And as you can see, I associated the pic with hdr : )

For the "Bitmap\Grayscale\Indexed\RGB\RGBA\RGBE" info, if the image is colored I check the number of bits and it should be something like this: 24=RGB, 32=RGBA, over 32=RGBE, otherwise Index with n bits.

[haraldk]

I see. 😀

You probably know already, but just in case, an alternative way of finding the mime type is:

ImageReaderSpi provider = reader.getOriginatingProvider();
String[] mimeTypes = provider.getMIMETypes(); // All the types the reader will claim to read

// There's also:
String[] formatNames = provider.getFormatNames(); // reader.getFormatName() simply returns originatingProvider.getFormatNames()[0]
String[] suffixes = provider.getFileSuffixes(); 

--
Harald K

[haraldk]

In any case, the fix is in. Will be part of 3.4

--
Harald K