SUMMARY The video import dialog has options to set the color space for the new document will take. This could impress on the user that this allows you to select the color space in which the video is imported. It does not. Videos right now are always imported as sRGB, because that's the kind of PNGs ffmpeg generates. I propose we get rid of these dropdowns before string freeze in the name of UI simplification (and we might also get rid of the width and height... and set the resolution to 72 by default). (I have some code for determining the color profile based on the color_primaries and color_transfer stream data, but it needs a lot more testing and may not be done before stringfreeze.)
Hey Wolthera, I'm confused by this because setting the import settings to GRAYA does seem to change the colorspace of the imported animation to grayscale correctly. The frames themselves are extracted as sRGB, but Krita seems to be correctly converting these frames to the desired color space upon new document creation. Is the issue here that there's technically some data loss when a video is rendered in a color space, exported as sRGB behind the scenes by ffmpeg, and reimported back as a specific color space? As for the width and the height -- I think I might agree since it doesn't seem to do much outside of adding a bunch of white space around an animation. At some point, it might be nice to let users upscale their animations.
Created attachment 138675 [details] WIP for detecting colorspace. > I'm confused by this because setting the import settings to GRAYA does seem to change the colorspace of the imported animation to grayscale correctly. It's not, the document created is Grayscale, but the layer colorspace is sRGB. You can tell by looking at the layer properties. This is mostly an issue when trying to reimport an hdr clip generated with krita, we'd expect it to be loaded as the rec 2020 smpte 2048 colorspace. It will also be an issue when trying to import any other color-primaries/color-transfer/color-space tagged video file, because a user might try to import them as the appropriate profile, but instead they will be loaded as sRGB. > The frames themselves are extracted as sRGB, but Krita seems to be correctly converting these frames to the desired color space upon new document creation. The frames are extracted as 'untagged', Krita always interprets this as sRGB. I was wrong about the bitdepth though, that's 16 or 8bit depending on the input video file. I'm attaching my WIP patch that can detect the color profile from the video data and then find or create the appropriate icc file (reusing the work I did for heif... kinda. hybrid-log gamma and st. 428 need special treatment, and that will right now be very heavy for importing video, we might need to put in a warning there that we can't open these kinds of files correctly...?) The patch as is is kinda broken, because it creates a layer of the appropriate colorspace, while what should actually happen is that we create a layer, fill it with frames, and then *assign* the appropriate profile, to avoid Krita trying to helpfully convert the colorspace. Only after that we need to create the document that the animated layer is part of. I am currently skeptical of my ability to finish it before the string freeze, and attaching it so I can communicate better what I think needs to be done.
Ok I understand the problem now... I think that the color-space of the layer probably is the most important task, and we can worry about the sizing later. I think that letting people decide a total size without scaling is fine for now and may actually help in some circumstances (for example, pixel art animations that might be atlased, etc.) Perhaps go ahead and create a merge request for this task with the posted diff as work in progress. We can kind of work on this collaboratively, if you don't mind. If we need to, we can manually add the strings with i18n before the functionality is fully implemented so that they will at least be present in the localization files for translators for the string freeze.
https://invent.kde.org/graphics/krita/-/merge_requests/864
I have resolved this, the document color space settings are no more!!!