Project

General

Profile

Bug #12390

high quality export

Added by jean-luc Le Corre 9 months ago. Updated 9 months ago.

Status:
Fixed
Priority:
Low
Assignee:
-
Category:
-
Target version:
Start date:
11/03/2018
Due date:
% Done:

100%

Affected Version:
git master branch
System:
all
bitness:
64-bit
hardware architecture:
amd64/x86

Description

Hi,

It seems the last commit in pixelpipe_hb.c broke export with high_quality on : I got a full magenta jpeg.

If I revert to gamma instead of colorout : it works again.

DSC01405_02.jpg (1.96 MB) Aurélien PIERRE, 11/04/2018 02:16 PM

DSC01420.jp2 - non HQ jp2000 (1.13 MB) jean-luc Le Corre, 11/04/2018 10:00 PM

DSC01420_01.jpg - gamma + colorout disabled (401 KB) jean-luc Le Corre, 11/04/2018 10:01 PM

Associated revisions

Revision 7ef5a49e
Added by Aurélien PIERRE 9 months ago

Bug fix #12390 : broken HQ export

The fix I introduced for the color pixcker broke the HQ export. This revert it. Anyway, it didn't work with LittleCMS, so it was probably not a real fix

History

#1 Updated by Aurélien PIERRE 9 months ago

That function is not called during export, it only affects the color picker. Is Little CMS on ?

If true, it means the color management in dt is a bigger clusterfuck that I thought.

#2 Updated by Aurélien PIERRE 9 months ago

I believe your error rather came from my change on gamma.c, it should be fixed with the last version.

#3 Updated by jean-luc Le Corre 9 months ago

Hello,

Still error with darktable 2.5.0+766~g3d77882b1

It occurs with or without little CMS when high quality export is on.

#4 Updated by Aurélien PIERRE 9 months ago

Could you send the picture ? I'm not able to reproduce.

#5 Updated by jean-luc Le Corre 9 months ago

Here the link to the files (raw + xmp + jpeg without and with hq set to on) : https://www.dropbox.com/s/4di38odl9r6rol3/DSC01405.tar.xz?dl=0

I noticed that the called modules differs at the end of the export:

no HQ :
87,141387 [dev_pixelpipe] took 0,003 secs (0,000 CPU) processed `niveaux' on GPU, blended on GPU [export]
87,146483 [dev_pixelpipe] took 0,005 secs (0,001 CPU) processed `profil de couleur de sortie ' on GPU, blended on GPU [export]
87,164386 [dev_pixelpipe] took 0,018 secs (0,069 CPU) processed `gamma' on CPU, blended on CPU [export]

HQ :
62,802617 [dev_pixelpipe] took 0,014 secs (0,037 CPU) processed `niveaux' on GPU, blended on GPU [export]
62,832292 [dev_pixelpipe] took 0,030 secs (0,025 CPU) processed `redimensionne à la taille finale' on GPU, blended on GPU [export]
62,851648 [dev_pixelpipe] took 0,019 secs (0,069 CPU) processed `gamma' on CPU, blended on CPU [export]

#6 Updated by Aurélien PIERRE 9 months ago

The point of the HQ export is to process the whole picture and resize it at the last step. LQ export resizes first for performance. So what you see is normal.

#7 Updated by Aurélien PIERRE 9 months ago

I'm sorry, I have tested with/without LittleCMS, OpenCL and HQ export, I get a perfectly normal image. Maybe try to clean the build and /opt/darktable directories, and try a fresh git pull ?

#8 Updated by jean-luc Le Corre 9 months ago

To be sure : I build a new repository (git clone) - same result. So I don't understand why it's working for you and not for me - any idea ?
In fact I was not surprised by the resize but by the missing 'profil de couleur de sortie' in HQ

#9 Updated by jean-luc Le Corre 9 months ago

More information:

I had a look a the code :
The dt_dev_pixelpipe_process_no_gamma function in pixelpipe_hb.c is called in 2 cases :

HQ export and export in non 8bpp format => I tested with png 16 and jpeg 2000 : I also got artifacts (without HQ export) - see attached. With gamma module disabled no artifact. So I think the gamma module should stay disabled by that function.

For fun I tried to disable both gamma and colorout : I got a strange result - see attached.

#10 Updated by Aurélien PIERRE 9 months ago

Ok I will revert that commit then. Sorry for the trouble.

#11 Updated by Aurélien PIERRE 9 months ago

  • Status changed from New to Patch attached
  • % Done changed from 0 to 70

#12 Updated by Anonymous 9 months ago

  • % Done changed from 70 to 100
  • Status changed from Patch attached to Fixed

Also available in: Atom PDF