Project

General

Profile

Bug #10200

Wrong JPG exportation when big mask pattern used

Added by Pol van der Fielden about 5 years ago. Updated about 5 years ago.

Status:
In Progress
Priority:
Low
Assignee:
-
Category:
-
Target version:
Start date:
11/19/2014
Due date:
% Done:

50%

Estimated time:
Affected Version:
git development version
System:
other GNU/Linux
bitness:
64-bit
hardware architecture:
amd64/x86

Description

When exporting to JPG a file with a complex mask in the exposure module, it generates the desired JPG file plus another file with wrong extension (seems like a beginning of a JPG file). Just like this:

112119 12 -rwxrwxrwx 1 root root 11466 nov 19 12:00 20141022114756_oly_pep3_PA227968_dt_20141119-115810.jpg2480
112118 6676 -rwxrwxrwx 1 root root 6833473 nov 19 12:00 20141022114756_oly_pep3_PA227968_dt_20141119-115810.jpg

OS: Linux Mint 17 Qiana x64

Link to the ORF file, XMP and exported JPG:

https://www.dropbox.com/s/g2g9a2wecli62qy/20141022114756_oly_pep3_PA227968_dt_20141119-115810.zip?dl=0

History

#1 Updated by Ulrich Pegelow about 5 years ago

  • % Done changed from 0 to 10
  • Status changed from New to Confirmed

Interesting - I've never seen such a "second" JPEG before. Most likely it's caused by the fact that the xmp block which darktable tries to embed into the JPEG gets too big. There is a factual limit of 64k due to exiv2, which your xmp exceeds in this case. This limitation is documented here: [[http://www.darktable.org/usermanual/ch02s03s12.html.php]]. As darktable has no program code (AFAIK) to write this second file, I assume the file is generated somewhere in exiv2.

In the case of your example image I'd recommend that you generate the mask by using a path shape. The brush shape slows down rendering speed - besides of generating huge XMP files.

#2 Updated by Pol van der Fielden about 5 years ago

Ulrich Pegelow wrote:

In the case of your example image I'd recommend that you generate the mask by using a path shape. The brush shape slows down rendering speed - besides of generating huge XMP files.

I'll try to do that next time.

Anyway maybe Dartktable shouldn't be embedding the shape...

#3 Updated by Ulrich Pegelow about 5 years ago

  • % Done changed from 10 to 50
  • Target version set to Future
  • Status changed from Confirmed to In Progress

The shape data is part of the history stack (XMP) - it would not make sense to eliminate only the shape from that.

Generally the embedded XMP data come in handy if you happen to lose your XMP file by some disaster. In that case you would be able to fully reconstruct your work with only your raw file plus an exported JPEG.

I am considering to add a config option to disabled embedding XMP data into output files. Might be that some users do not want to disclose their darktable workflow when they distribute a JPEG. This change will certainly only happen after the 1.6 release.

#4 Updated by Pol van der Fielden about 5 years ago

Ulrich Pegelow wrote:

I am considering to add a config option to disabled embedding XMP data into output files. Might be that some users do not want to disclose their darktable workflow when they distribute a JPEG. This change will certainly only happen after the 1.6 release.

That makes sense, it's a good idea!

#5 Updated by Tobias Ellinghaus about 5 years ago

There are already some feature requests (they are triaged and accepted, just not implemented) to add some selector to specify what level of metadata gets written. However, the details of that have to be discussed first.

Also available in: Atom PDF

Go to top