Bug 406830

Summary: Render Animation Image Sequence work only on PNGs
Product: [Applications] krita Reporter: Tiar <tamtamy.tymona>
Component: AnimationAssignee: Dmitry Kazakov <dimula73>
Severity: normal CC: halla, tamtamy.tymona
Priority: NOR    
Version: nightly build (please specify the git hash!)   
Target Milestone: ---   
Platform: Microsoft Windows   
OS: Microsoft Windows   
Latest Commit: Version Fixed In:
Attachments: Comparison between the source and the saved frame

Description Tiar 2019-04-23 20:38:39 UTC
Render Animation -> Image Sequence show a lot of options, but whatever you choose (even when you set format-specific options in [...] dialog), pngs will be rendered.

1. Make an animation.
2. Use Render Animation -> Image Sequence option. Choose something other than PNG, for example OpenEXR.

Rendered frames are saved as PNGs.

Either rendered frames are saved in the chosen format, or you can't choose anything other than PNG

Please reenable saving frames as different formats than PNG, at least for now. For example, I wanted to export frames as OpenEXR because I was making HDR animation, and since Krita doesn't have LUT baking yet, I wanted to use external program to do it (Luminance HDR in this case). The external program however doesn't recognize PNGs as HDR format, it does however recognize OpenEXRs and tiffs. It worked in Krita 4.1.7, but it doesn't work now and it was disabled before HDR was introduced, so there is no version that supports both HDR and exporting frames as something else than PNGs.

Krita version: 4.2.0-pre-alpha (git fb08951)
Windows: 10
Qt Version: 5.12.2
Comment 1 Halla Rempt 2019-04-23 20:39:49 UTC
This should work... But in any case, Krita does support rendering to extended PNG which supports HDR so it's possible to generate hdr animations with Krita. Let's ask Dmitry tomorrow about details.
Comment 2 Tiar 2019-04-23 22:22:58 UTC
Yes, but some other programs (open source pfstools or Luminance HDR that is based on it) don't support PNGs with HDR (they assume all PNGs are SDR), that's why I needed another format. Also as I read through what google shows me, it's always either OpenEXR, tiff or Radiance HDR which has HDR support. PNG extended might be less known, I guess.

Rendering animation works correctly, rendering PNG image sequences also works as far as I remember.
Comment 3 Dmitry Kazakov 2019-04-24 20:55:32 UTC
Git commit bbfb59f5bcfe1e8232287c70010d3604a4ff14ac by Dmitry Kazakov.
Committed on 24/04/2019 at 20:55.
Pushed by dkazakov into branch 'master'.

Fix exporting animation frames into EXR format

The patch fixes two problems:

1) DlgAnimationRenderer didn't initialize frames' mimetype correctly,
   so exporting always happened into PNG format.

2) DlgAnimationRenderer should correctly initialize saving format
   settings from the default cfg.exportConfiguration(). Using the
   same settings for both, animation rendering and normal image save
   is a disputable approach, but that  is how we do it for ages.

3) EXRConverter shouldn't call any blocking functions on the image
   (and shouldn't change the state of the image as well). So it should
   convert non-16f/32f layers on the fly.

M  +12   -3    libs/ui/KisDocument.cpp
M  +5    -0    libs/ui/KisDocument.h
M  +12   -15   plugins/extensions/animationrenderer/DlgAnimationRenderer.cpp
M  +1    -2    plugins/extensions/animationrenderer/DlgAnimationRenderer.h
M  +41   -38   plugins/impex/exr/exr_converter.cc

Comment 4 Tiar 2019-04-25 08:59:35 UTC
Created attachment 119624 [details]
Comparison between the source and the saved frame

If you just render image sequence and open EXR file in Krita, it will have wrong colors. The attached screenshot shows that. Krita reports color profile as sRBG-elle-v2-g10.icc .

When I assign R2020-elle-v4-g10.icc profile (without converting), colors are correct.

Sidenote: sRBG-elle-v2-g10.icc displays as HDR (doesn't follow the usual SDR rules). I thought it was SDR format, just 16bit/float. Is it that expected or another bug?
Comment 5 Tiar 2019-04-26 22:20:25 UTC
The problem I was talking above is unrelated to Image Sequence, I reported it in another bug report: bug 406939.