Tfs Embeded Images Tool

[MrHinsh]

This discussion is for questions, feedback, and community support related to the TFS Embedded Images Tool.

Quick Reference

• Class Name: TfsEmbededImagesTool
• Friendly Name: Tfs Embeded Images
• Documentation: TFS Embedded Images Tool

How to Use This Discussion

• Ask Questions: If you need help configuring or using this component
• Share Examples: Post your configuration examples or use cases
• Report Issues: Describe any problems you encounter (though bugs should be reported as GitHub Issues)
• Request Features: Suggest improvements or new features

Related Documentation

Please refer to the official documentation for detailed configuration options and examples.

[johannedin]

Hi,
I have the following configuration snippet:

"CommonTools": {
	"TfsEmbededImagesTool": {
        "Enabled": true
      },
      "TfsAttachmentTool": {
                "Enabled": true,
                "ExportBasePath": "c:\\temp\\migrationtest\\tb",
                "MaxAttachmentSize": 480000000,
                "RefName": "TfsAttachmentTool"
      },

I have a small work item with an image in the description of the work item. Is the expected behavior that when migrating, the image should be visible in Target? Because - that is not happening in my setup...

EDIT:
I debugged the code and figured out that "FixHtmlAttachmentLinks": true, must be set in the work item processor. In addition:

 protected static ImageFormat GetImageFormat(byte[] bytes)

in EmbededImagesRepairToolBase is not bullet proof. It can't for example successfully detect this image as a jpeg.

In particular - coverage for jpeg files is not complete. At minimum we should add:

var jpeg6 = new byte[] { 255, 216, 255, 239 }; // Adobe JPEG
var jpeg7 = new byte[] { 255, 216, 255, 227 }; // JPEG with ICC profile
var jpeg8 = new byte[] { 255, 216, 255, 219 }; // JPEG with quantization table
var jpeg9 = new byte[] { 255, 216, 255, 238 }; // JPEG with Photoshop metadata

Then we should extend the detection logic:

if (jpeg.SequenceEqual(bytes.Take(jpeg.Length)) ||
    jpeg2.SequenceEqual(bytes.Take(jpeg2.Length)) ||
    jpeg3.SequenceEqual(bytes.Take(jpeg3.Length)) ||
    jpeg4.SequenceEqual(bytes.Take(jpeg4.Length)) ||
    jpeg5.SequenceEqual(bytes.Take(jpeg5.Length)) ||
    jpeg6.SequenceEqual(bytes.Take(jpeg6.Length)) ||
    jpeg7.SequenceEqual(bytes.Take(jpeg7.Length)) ||
    jpeg8.SequenceEqual(bytes.Take(jpeg8.Length)) ||
    jpeg9.SequenceEqual(bytes.Take(jpeg9.Length)))
    return ImageFormat.jpeg;

Alternatively the less strict we should just check the first two bytes of the file:

if (bytes.Length >= 2 && bytes[0] == 255 && bytes[1] == 216)
    return ImageFormat.jpeg;

All JPEG files start with the Start of Image (SOI) marker: FF D8.
The next bytes (FF XX) vary depending on metadata, camera manufacturer, or embedded profiles (EXIF, ICC, etc.), but the first two bytes are always FF D8.
(Source: CoPilot - note - I have verified the defect and the fix with image linked above - so there is no doubt that at least alternative one above works and solve the defect of not being able to identify the image above as a jpeg).

I'll see if i figure out how to contribute this change...

/ Johan