Bug 413993 - Krita always uses a default profile instead of the correct one
Summary: Krita always uses a default profile instead of the correct one
Status: RESOLVED FIXED
Alias: None
Product: krita
Classification: Applications
Component: Color models (show other bugs)
Version: unspecified
Platform: Other Linux
: NOR normal
Target Milestone: ---
Assignee: Dmitry Kazakov
URL:
Keywords: regression, release_blocker
Depends on:
Blocks:
 
Reported: 2019-11-10 02:10 UTC by Tiar
Modified: 2019-11-11 10:25 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Test file with SMPTE profile (755.68 KB, application/x-krita)
2019-11-10 02:15 UTC, Tiar
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Tiar 2019-11-10 02:10:04 UTC
SUMMARY
Both krita/4.2 and master now can't open files any other profile than the default one. I'm pretty sure the reason is somewhere inside Dmitry's recent commits about converting and loading color spaces and profiles.


STEPS TO REPRODUCE
1. Open the test file using 4.2.7.1 and the stable version (Krita Plus).

OBSERVED RESULT
4.2.7.1 version says the profile is SMTP, the Krita Plus version says it's elle-v2-g10.
The picture looks differently: in 4.2.7.1. the background is orange (which is expected).

EXPECTED RESULT
Both says it's SMTP. In both background is orange.


SOFTWARE/OS VERSIONS
Krita

 Version: 4.3.0-prealpha (git bda22a0)
 Languages: pl
 Hidpi: true

Qt

  Version (compiled): 5.11.1
  Version (loaded): 5.11.1

OS Information

  Build ABI: x86_64-little_endian-lp64
  Build CPU: x86_64
  CPU: x86_64
  Kernel Type: linux
  Kernel Version: 5.3.7-050307-generic
  Pretty Productname: Linux Mint 19.2
  Product Type: linuxmint
  Product Version: 19.2

OpenGL Info
 
  Vendor:  "Intel Open Source Technology Center" 
  Renderer:  "Mesa DRI Intel(R) Iris(R) Plus Graphics (Ice Lake 8x8 GT2) " 
  Version:  "3.0 Mesa 19.0.8" 
  Shading language:  "1.30" 
  Requested format:  QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, colorSpace QSurfaceFormat::ColorSpace(DefaultColorSpace), profile  QSurfaceFormat::OpenGLContextProfile(CompatibilityProfile)) 
  Current format:    QSurfaceFormat(version 3.0, options QFlags<QSurfaceFormat::FormatOption>(DeprecatedFunctions), depthBufferSize 24, redBufferSize 8, greenBufferSize 8, blueBufferSize 8, alphaBufferSize 8, stencilBufferSize 8, samples -1, swapBehavior QSurfaceFormat::SwapBehavior(DoubleBuffer), swapInterval 0, colorSpace QSurfaceFormat::ColorSpace(DefaultColorSpace), profile  QSurfaceFormat::OpenGLContextProfile(NoProfile)) 
     Version: 3.0
     Supports deprecated functions true 
     is OpenGL ES: false 

QPA OpenGL Detection Info 
  supportsDesktopGL: true 
  supportsOpenGLES: true 
  isQtPreferOpenGLES: false 

Hardware Information

  GPU Acceleration: auto
  Memory: 15633 Mb
  Number of Cores: 8
  Swap Location: /tmp

Current Settings

	Current Swap Location: /tmp
	Undo Enabled: 1
	Undo Stack Limit: 30
	Use OpenGL: 1
	Use OpenGL Texture Buffer: 1
	Use AMD Vectorization Workaround: 0
	Canvas State: OPENGL_SUCCESS
	Autosave Interval: 1260
	Use Backup Files: 1
	Number of Backups Kept: 1
	Backup File Suffix: ~
	Backup Location: Same Folder as the File
	Use Win8 Pointer Input: 0
	Use RightMiddleTabletButton Workaround: 0
	Levels of Detail Enabled: 1
	Use Zip64: 0
Comment 1 Tiar 2019-11-10 02:15:13 UTC
Created attachment 123816 [details]
Test file with SMPTE profile

It is SMPTE, not SMTP, but whatever.
Comment 2 Tiar 2019-11-10 02:20:12 UTC
Dmitry, assigning you, since (1) it's probably your code (considering the amount of commits you made recently near this topic),  (2) even if not, you probably knows best, (3) you deal with release blockers and I generally think this is one? It seems pretty important. Unless Boud overrides my decision to tag it this way, of course.
Comment 3 Halla Rempt 2019-11-10 09:03:31 UTC
I suspect something like 

commit 179649cf5a83efbb8c8cda2e20b0c36fcc568462
Author: Dmitry Kazakov <dimula73@gmail.com>
Date:   Tue Oct 15 20:06:12 2019 +0300

    Fix regression (deadlock) when loading .kra with non-default color prfofile
    
    KisKraLoader works under ubdatesBlocked(), so to ensure waitForDone()
    doesn't deadlock, we should guarantee that no updates are issued in
    a process of profile setting. And we shouldn't issue updates anyway,
    because loading process will emit initialRefreshGraph() anyway.


So, yes, needs to be assigned to Dmitry.
Comment 4 Dmitry Kazakov 2019-11-11 10:24:05 UTC
Git commit e2eb135674f0d32eec1927922a524f4f748899be by Dmitry Kazakov.
Committed on 11/11/2019 at 10:23.
Pushed by dkazakov into branch 'master'.

Fix profile when loading image with non-default profiles

It looks like the image's profile may be initialized on some
earlier stages, so we should check if the profile is already set
on layers a bit earlier.

M  +13   -1    libs/image/kis_image.cc

https://invent.kde.org/kde/krita/commit/e2eb135674f0d32eec1927922a524f4f748899be
Comment 5 Dmitry Kazakov 2019-11-11 10:25:02 UTC
Git commit 20568345bdd23acee5340360d6012f016eb48fce by Dmitry Kazakov.
Committed on 11/11/2019 at 10:24.
Pushed by dkazakov into branch 'krita/4.2'.

Fix profile when loading image with non-default profiles

It looks like the image's profile may be initialized on some
earlier stages, so we should check if the profile is already set
on layers a bit earlier.

M  +13   -1    libs/image/kis_image.cc

https://invent.kde.org/kde/krita/commit/20568345bdd23acee5340360d6012f016eb48fce