Incorrect handling of HDR files

Tumist writes on the Gyroflow Discord:

In the last version plugin breaks HDR playback on Macbook 2021. In the previous there was no such thing. In both cases I'm loading the same Gyroflow project. On the screenshots they look identical without and with effect enabled, but on the screen it really looks like this.

I think it might be a similar issue to what we discovered with BRAW Toolbox, and had to use HDR Tools AFTER the BRAW Toolbox effect in Final Cut Pro to correct (see: https://brawtoolbox.io/hdr-workflow/).

There's a long GitHub discussion about BRAW Toolbox's HDR workflow here.

In theory, Gyroflow Toolbox shouldn't be changing colours at all - we just pass the inputTexture and outputTexture MTLTexture's from FxPlug4 to Gyroflow's Render Engine, which just "repositions" the pixels - it shouldn't do any colour processing.

The FxPlug4 render code is here.

However, I did try and by-pass gyroflow_core completely, by using a blit command encoder to copy the input texture to the output texture (i.e. no processing), and the image stays the same - so it could be gyroflow_core "clipping" the HDR data somehow. This is the code I added at the top of renderDestinationImage:sourceImages:pluginState:atTime:error::

{
        MetalDeviceCache* deviceCache       = [MetalDeviceCache deviceCache];
        id<MTLDevice> inputDevice           = [deviceCache deviceWithRegistryID:sourceImages[0].deviceRegistryID];
        id<MTLTexture> sourceTexture        = [sourceImages[0] metalTextureForDevice:inputDevice];
        id<MTLTexture> destinationTexture   = [destinationImage metalTextureForDevice:[deviceCache deviceWithRegistryID:destinationImage.deviceRegistryID]];

        // Assuming device, sourceTexture, and dest
![PXL_20230804_141501187 MP](https://github.com/latenitefilms/GyroflowToolbox/assets/22286696/0041eefd-5359-4712-8cc6-11ff7f6e42d6)
inationTexture are already set up.

        // Ensure both textures have the same dimensions and format.
        if (sourceTexture.width != destinationTexture.width ||
            sourceTexture.height != destinationTexture.height ||
            sourceTexture.pixelFormat != destinationTexture.pixelFormat) {
            NSLog(@"Textures are not compatible for copying!");
            return NO;
        }

        // Obtain a command buffer from your command queue.
        id<MTLCommandBuffer> commandBuffer = [inputDevice.newCommandQueue commandBuffer];

        // Create a blit command encoder.
        id<MTLBlitCommandEncoder> blitEncoder = [commandBuffer blitCommandEncoder];

        // Specify the regions of the textures that you want to copy.
        // Here, we're copying the whole texture.
        MTLOrigin origin = {0, 0, 0};
        MTLSize size = {sourceTexture.width, sourceTexture.height, 1}; // Assuming 2D texture.

        [blitEncoder copyFromTexture:sourceTexture
                         sourceSlice:0
                         sourceLevel:0
                        sourceOrigin:origin
                          sourceSize:size
                           toTexture:destinationTexture
                    destinationSlice:0
                    destinationLevel:0
                   destinationOrigin:origin];

        // End the blit encoding.
        [blitEncoder endEncoding];

        // Commit the command buffer to perform the copy.
        [commandBuffer commit];

        // Optionally, if you want to wait for the operation to complete before proceeding:
        [commandBuffer waitUntilCompleted];
        return YES;
}

I also tried changing this to kFxImageColorInfo_RGB_GAMMA_VIDEO, but it had no impact:

        //---------------------------------------------------------
        // @const      kFxPropertyKey_DesiredProcessingColorInfo
        // @abstract   Key for properties dictionary
        // @discussion The value for this key is an NSNumber indicating the colorspace
        //             that the plug-in would like to process in. This color space is
        //             expressed as an FxImageColorInfo enum. If a plug-in specifies this,
        //             and the host supports it, all inputs will be in this colorspace,
        //             and the output must also be in this colorspace. This may not
        //             be supported by all hosts, so the plug-in should still check
        //             the colorInfo of its input and output images.
        //---------------------------------------------------------
        kFxPropertyKey_DesiredProcessingColorInfo : [NSNumber numberWithInt:kFxImageColorInfo_RGB_LINEAR],

However, I was able to get the images to look correctly by doing this:

..but again, this seems like a bit of a hack/workaround. However, the fact this works, makes me think it is actually just a metadata tagging issue - rather than any actual image data being clipped or lost.

I've tried playing with the Color Processing and Override FCP Color Space settings in the Motion Template, but like BRAW Toolbox, they don't seem to do what we need.

I've reached out to the Final Cut Pro team for ideas.

latenitefilms / GyroflowToolbox

Incorrect handling of HDR files #23