0.72 jpegs save with suspect headers - ICC Profile

[CameronD]

Running under Win-7 x64. If I use XnView MP to write a jpeg, then exiftool reports a warning: invalid Metadata data.
I have found this happens in the following cases (not exhaustive testing):

• crop image, save-as
• crop image, save (and overwrite)
• batch process, overwrite in same dir (simply changing jpg compression levels)

Using exiftool's -htmldump, there are now 21 ICC profile entries, and the size of each is given as 65537 bytes. The original profile was 3158 bytes.

The original Canon profile is not copied from the old image to the new one, as far as I can tell.

In format settings, ''Keep ICC Profile'' is ticked/enabled, and the same applies for keeping EXIF, IPTC, XMP. Chroma subsampling 1x1, Quality 90
The profile from the image was sRBG.

Update: The camera's ICC profile seems to have been replaced with my primary monitor profile, which is a custom calibrated profile prepared using X-Rite's eye-1 display hardware.

My settings for General->ICC are:
use ICC profile for monitor : enabled
Selected "system" profile (which is the one that gets embedded in the jpeg).
Default Profile of Picture: None

Update again:
The monitor ICM file is 1,322,148 bytes in size

[CameronD]

I have run exiftool at verbosity level 5 and it is happy with the ICC data being split into 21 chunks, and it is only when it gets to the end of the ICC profile that it issues the warning.

Code: Select all

...the output near the warning...
  | 14) Metadata (SubDirectory) -->
  |     - Tag 'meta' (184 bytes, type 'dict'):
  |       142bec: 64 69 63 74 00 00 00 00 00 00 00 03 00 00 00 10 [dict............]
 ... 9 lines deleted 
  |       142c8c: 00 72 00 6f 00 66 00 69 00 6c 00 65 00 46 00 61 [.r.o.f.i.l.e.F.a]
  |       142c9c: 00 6c 00 73 00 65 00 00                         [.l.s.e..]
  | Warning = Invalid Metadata data
JPEG DQT (65 bytes):

It is still not clear to me what exiftool thinks is ''invalid''.
The block 14 count seems correct.
The earlier code says there are 15 directory entries, so this is the last one.

The bytes in block 14 match the content at the end of the monitor's ICM file.

[xnview]

do you have original and output file? And the way to create output file?

[CameronD]

I have sent good and bad images together with the monitor ICM file to your "contact" email address.

I cannot reproduce the problem with V0.69 code, nor with classic V2.13.

So it seems to be a change in behaviour introduced recently.

Whether the new behaviour is correct or not I cannot say, because I don't understand colour management well enough.

I originally had "use ICC profiles" enabled because I was using AbobeRGB and I needed XnView to do proper colour-management.
My understanding of that setting was that it caused XnView to convert the image's colour to display correctly on the monitor but that it should still use the original embedded profile as the file's colour space.

[xnview]

The problem exist in lastest version of XnView too, XnView 2.13 this issue too.

When you load picture with icc profile, the data is changed according to the profile. So when you save it, the new profile is used...

PS: i don't understand why photosop complains abou this profile...