XMP support

[Beep6581]

Originally reported on Google Code with ID 473

To get someday XMP support to RT I put one idea where to start.

CMakeLists.txt add:

option (WITH_EXIV2 "Build with Exiv2 support" ON)
if (WITH_EXIV2)
    add_definitions (-DEXIV2)
    pkg_check_modules (EXIV2    REQUIRED exiv2>=0.19)
endif (WITH_EXIV2)

Examples can found: http://www.exiv2.org/
Exiv2 looks use Adobe XMP toolkit source for decoding XMP data.

Reported by GreatBull69 on 2011-01-10 09:16:43

• Blocking: #1307, #1130

[Beep6581]

And 2 patchs for testing.

Add exif output with parameter -x imagefile

Reported by GreatBull69 on 2011-01-10 09:20:05

---

• Attachment: main.diff
• _Attachment: rtgui_CmakeList.txt.diff_

[Beep6581]

Add for reading xmp file add parameter -y filename
reading xmp file and rewriting with new name add parameter -z filename

Now RT have XMP support even it not do anything usefull.

Reported by GreatBull69 on 2011-01-10 11:37:03

---

• Attachment: mainv2.diff

[Beep6581]

This is a brilliant step forward! Thank you!

Reported by michaelezra000 on 2011-01-10 12:03:01

[Beep6581]

Sorry, I don't understand yet: what is a usage scenario for these command line parameters?

Reported by oduis@hotmail.com on 2011-01-10 14:02:24

[Beep6581]

I'm wondering if it's time to integrate exiv2 completely in RT (on default branch),
rejecting the current classes for reading EXIF/IPTC information... but adding also
XMP. (exif2 uses internally xmp sdk by Adobe)
I have to study better the code of exiv2 to judge the work of integration completely.
I'm a bit puzzled because I spent time to improve decoding of makernotes that are not
in exiv2.
I ask also "what is a usage scenario for these command line parameters?"

Reported by ffsup2@yahoo.it on 2011-01-10 18:52:07

[Beep6581]

command line parameter not have real RAW manipulation usage. (reason also for stupid
xyz names)

Or do you mean
rtstart -x image.cr2
rtstart -y image.xmp
rtstart -z image.xmp

x and y print to terminal (looks ugly)
z write new file image.xmp-new

Main purpose is be example code how read and write xmp and for testing purpose to test
is exiv2 working. 

These maybe can "leave" production code for debugging purpose. -z maybe good for testing
at RT will not lost XMP data. (image.xmp and image.xmp-new should be same)

#5 exiv2 for exif data.
I propose not to do (yet??). Reasons:

1) better study exiv2 in small area first. (easy to dump if find to be wrong/non optimal
direction)

2) Maybe first make some parallel system like 2nd Meta (exiv2) window for testing purpose.

3) I like have control to improve coding makernotes too. So I see 3 option. A) find
to way to add decodings top of exiv2 B) have current system top of exiv2 C) current
system. D) Add changes to exiv2. (I see A,B and C as option and hope A or B can use
and I feel B maybe best. Idea let exiv2 todo what it can and let RT to do rest).

4) exiv2 makernotes decoding looks quite limited currently

About D option yes changes should get exiv2 too but it maybe slow and not all stuff
accepted.

I didn't study exiv2 code, but I see it save lot of work if used wisely.

Reported by GreatBull69 on 2011-01-11 02:33:38

[Beep6581]

Great you work on some XMP! However, since the code is pretty much useless and more
an example for a developer, I would vote for not checkin it in.
Could you maybe build a usable feature of it, even if it's a tiny one for start?

Reported by oduis@hotmail.com on 2011-01-11 06:49:55

[Beep6581]

Good comment.

There is enough code for exiv2 evaluation which should be first issue and only issue
before exiv2 is accepted to RT. (checkin and 'acceptance' is not same. code can removed
if find it is not good)

Testers can participate evaluation. (I don't know is there any non-coder interested
XMP data quality). You can test you current XMP file with y and z parameters.

I think better leave 'little' features for future because it could distract focus to
main issue. Is exiv2 way to go or not (maybe someone invent better way)

Checkin or not? I think depend who is wanted to make evaluation (and when).

Personally I am not smooth with patching yet so I test only checked code.

Ok, evaluation can do other way too.

PS1. I think there will be only 2 features read XMP file and write XMP file which replace
or coexist with current read/write sidecarfile.  (ok also create XMP data if not exist).
Conversion internal data missing. Maybe somewhere should start discussion how to map
data from/to XMP.

PS2. Just show  how easy write RT data to XMP addition of profile txt file. Only 2
parameter added. If someone have any clue of RT files changing them to XMP is very
easy (almost no coding skills needed). (XMP parameter naming is different story) (DO
NOT checkin this example)
http://www.exiv2.org/example5.html

Reported by GreatBull69 on 2011-01-11 14:27:58

---

• Attachment: procparams.diff

[Beep6581]

> (checkin and 'acceptance' is not same. code can removed if find it is not good)
From my experience useless temporary codes unfortunately tend to live forever. When
the initial developers leaves, noone knows what it's for, and therefore noone removes
it. It's even maintained all the way, because maybe a user uses it for whatever reason
;-)

If you don't want to make a intermediate little feature, how about making a branch
where you can work on the XMP integration till it's ready? Emil does it currently with
the float engine, there have been branches e.g. for vignette features, too.

Reported by oduis@hotmail.com on 2011-01-11 18:36:12

[Beep6581]

I agree no checking useless code 

I try just try figure out what is best way to XMP support go next level.

Maybe we just wait some developer interest make it ready.

I didn't plan develop code further (I solved my problem much simpler way, This was
just accidental side product). My interest publish this is attract new developers,
help old one and increase interest of metadata in RT community. 

Problem of branch is nobody not use/test code.

Reported by GreatBull69 on 2011-01-12 02:50:27

[Beep6581]

Here is discussion about XMP format in RT: http://www.rawtherapee.com/forum/viewtopic.php?t=2580

Reported by GreatBull69 on 2011-01-13 08:47:00

[Beep6581]

Update: Engine2 branch have working XMP code. (At least looks very good).
Currently GUI missing in engine2 branch so it can't compile.

I case someone is interested XMP part is quite separated so maybe it is easy transfer
to default branch too. (I almost planned to do it, but didn't do it)

Reported by GreatBull69 on 2011-02-15 03:15:37

[Beep6581]

The last time I checked the "xmp support" of engine2 it was just "kill existing XMP
sidecar files with the usual RT processing params in proprietary XMP that no other
program understands".
Very simple to do, but for practically work useless, since it doesn't implement all
the things that make it so complex: parsing existing XMP from within RAW or Sidecar,
leveraging and merging data like tags etc. from other programs space etc., pass to
final JPG etc.
On the contrary: if you'd have a XMP sidecar e.g. from Adobe Bridge it would have been
destroyed with the rtengine2 code I saw. Hope it has been developed more meanwhile.

Reported by oduis@hotmail.com on 2011-02-15 06:16:17

[Beep6581]

first version destroy old XMP. but there is fix for that is already in code.
There is code for read Exif, xmp and Iptc data from RAW and write a to final image.
Modifying data looks like missing but that is GUI part.

Good reason get code run is find out is it destroy/lost data or not. (Looks like DigiKam
do same)
2nd reason is start looking stuff related other program spaces. Different people have
different needs so having something running may help development.

But I think engine2 will be "ready" before 3.0 so I plan wait for that.

Reported by GreatBull69 on 2011-02-16 01:02:00

[Beep6581]

Interaction to other programs some hints can be found here:
http://lxr.kde.org/source/extragear/graphics/digikam/libs/dmetadata/dmetadata.cpp

Reported by GreatBull69 on 2011-02-16 01:51:08

[Beep6581]

XMP sidecar in digiKam-2.0:
http://scribblesandsnaps.wordpress.com/2011/05/12/new-features-in-digikam-2-0-xmp-sidecar/

Reported by entertheyoni on 2011-05-21 22:27:26

• Labels added: Type-Enhancement, OpSys-All, Usability
• Labels removed: Type-Defect

[Beep6581]

Here is a very first change to start discussing about real code.
RT loads/writes params in xmp sidecar, but not all path are complete (and also array
are not saved like curves)
I tried to divide params in a future looking modular way, but this can be discussed:I
accept suggestions.
PS: I had to use libgcc_s_sjlj-1.dll from minGW to work; GTK provided does't work (crashes).

Reported by ffsup2@yahoo.it on 2011-08-16 08:59:45

---

• Attachment: xmp1.patch

[Beep6581]

Hi Fabio,

Thanks for the work, as outlined in the other discussion threads I think the critical
(and most difficult) topic is the reuse of common XMP areas. A patch like this is relatively
simple, but just replaces one proprietary format (pp3) that no other program understands
by another proprietary format that no other program understands (RT-specific XMP).
On the contrary, if I understand this correctly the patch seems to destroy existing
XMPs with information written by other programs.

Besides the merging with existing data like crops and or rankings (which is more complicated
than it sounds, because the programs sometimes write different XMP areas here), the
second issues is the source. So JPGs and DNGs typically have XMP embedded within the
file (other RAW can also have XMP embedded, but not as widely used I think). Programs
like Adobe can handle all this this (priorities, reading them out, merging with sidecar
etc.), but it’s not trivial.

Olli

Reported by oduis@hotmail.com on 2011-08-16 15:31:49

[Beep6581]

Update:
Full support for saving/reading current parameters.
Multiple snapshot support.
Ranking (stars + rejected is joined now)
Color labelling: compatibility for Bridge. (To discuss)

Oduis, I don't understand your comment; I started working on this (most wanted) feature,
and you complain it is difficult,it is not trivial. I only asked for comments about
real code, because even in simple solution there could be different point of view.
Attached is an updated patch and a sidecar xmp for reviewing data format.

Reported by ffsup2@yahoo.it on 2011-08-19 18:36:04

• Status changed: Started

---

• Attachment: xmp2.patch
• Attachment: DSC05805.xmp

[Beep6581]

Fabio, this is great, thanks for this contribution. Interesting handling of labels.

Ultimately, preferences window should allow user to override the label text (to match
that of Bridge, for example). Also interesting, what will happen if there is a mismatch
of label string - will it be ignored? 

I will try to test/review tonight and over the weekend.

Reported by michaelezra000 on 2011-08-19 19:13:59

[Beep6581]

> Oduis, I don't understand your comment
Seems like you already took care of some of my comments, thanks. :-)
Just asked to not overwrite existing XMPs (=destroy other apps taggings) but merge
with them (is this in the 2. patch?), and use common areas instead of RT specific ones.

Reported by oduis@hotmail.com on 2011-08-19 19:27:29

[Beep6581]

@Michael
Color labelling is performed in Bridge using standard xmp tag "Label": Bridge has a
table translating Labels to Colors. I did the same. It is a rather convoluted solution,
but works. As you said ultimaltely there should be in preferences the way to redefine
them ( I used Italian label per default, but if someone tell me standard english translation
I'll put in). If there is a mismatch, the result is "no Label" or "Other".
All other programs? I don't know. If anyone kindly comments in this regard, I'll try
to accomodate. I read that digikam uses (in 2.0 not yet stable) a proprietary solution;
why the hell? (tag xmp.digikam.ColorLabel)

@Oduis
Sidecar xmp is read "as is", if already present; rt adds its proper tags for procparams.
If xmp sidecar is not present, rt first looks for sidecar .pp3 and read it ( well I
din't change that code yet, so don't know what changes 3.0-3.1-4.0 would be usefull).
RT then creates a new xmp, inserting exif and iptc extracted from original file ( I
trusted the exiv2 library function: have to test how good is the transposition).
Now, I don't know how to manage RT changes to EXIF/IPTC, should we discard it and use
only xmp tags?
Then the output part: how and what to put in output file. I don't think to put processing
parameters in.

Reported by ffsup2@yahoo.it on 2011-08-19 20:14:52

[Beep6581]

Great, sounds like a smart approach to me.

>I don't know how to manage RT changes to EXIF/IPTC, should we discard it and use only
xmp tags?
Sorry, don’t understand at what stage?  To output file or when RT reads a new one?

> Then the output part: how and what to put in output file. I don't think to
> put processing parameters in.
+1 for not adding processing params in output. 

I guess the merging of params will become interesting, as it’s not only digikam who
has it’s own e.g. “rating” tag, also ACDSee and Microsoft among others. How about if
RT updates them all (at least the most popular vendors), but only if they existed before
or something?

> All other programs? I don't know.
Here is a good list of what XMP tags are floating around these days:
http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/XMP.html

PS: Is the custom profiles builder still called? Would be great, I'll adjust the sample
then to fit the new XMP format.

Reported by oduis@hotmail.com on 2011-08-19 20:42:35

[Beep6581]

Fabio, could you please share the exiv2 libraries necessary for RT compilation?
I am getting errors when compiling exiv2-0.21.1:

In file included from basicio.hpp:34:0,
                 from basicio.cpp:39:
types.hpp:97:13: error: 'uint8_t' does not name a type
types.hpp:100:23: error: 'uint32_t' was not declared in this scope
types.hpp:100:33: error: 'uint32_t' was not declared in this scope
types.hpp:100:41: error: template argument 1 is invalid
types.hpp:100:41: error: template argument 2 is invalid
types.hpp:100:52: error: invalid type in declaration before ';' token
.... etc....

In FileBrowser::fromTrashRequested and toTrashRequested you commented code for color
labels - I am curious, why

Reported by michaelezra000 on 2011-08-20 00:36:55

[Beep6581]

Here is the Adobe Bridge CS5 default for labels:
http://adobeclass.files.wordpress.com/2010/11/picture-31.png

May be it is better to go with spelling of the actual color for default?

Reported by michaelezra000 on 2011-08-20 01:16:29

[Beep6581]

here is more info on labels:
http://adobeclass.wordpress.com/2010/11/09/applying-metadata-changing-labels-in-bridge/

Reported by michaelezra000 on 2011-08-20 01:17:58

[Beep6581]

options.cc line 37: Glib::ustring paramFileExtension = ".pp3";

FileCatalog::copyMoveRequested will, for example, copy/move param file based on paramFileExtension.
For this purpose paramFileExtension should be ".xmp" going forward.

if after pp3->xmp conversion pp3 is preserved this gets more complicated as copy/move
and rename need to handle more files types...

Reported by michaelezra000 on 2011-08-20 02:46:16

[Beep6581]

@Oduis:
>>I don't know how to manage RT changes to EXIF/IPTC, should we discard it and use
only xmp tags?
>Sorry, don’t understand at what stage?  To output file or when RT reads a new one?
RT can add some IPTC and EXIF tags to the image (they are seved in procparams).
should we revert to use only xmp tags (in this case they would be written alone in
every format output file), or continue to let user edit either old EXIF,IPTC AND new
XMP.
In practice there would be a new tab XMP next to already present EXIF and IPTC

About tag: RT could support some ways, but not all contemporary, as each program seems
to use different ways and not compatible with others. I started with Bridge because
it's the one only installed in my PC, (and it seems it's more similar in the way colors
are already coded.) Digikam uses more colors and furthermore has other tagging "pick",
and it's not released yet. (There is no 2.0 binary for windows available yet)
ACDsee: I must try. How is it in this regard?

About xmp tags: RT will never be a complete solution to read/edit tags: there are several
other better programs to do it. We must choose only a few properties that RT will manage
in the best way: I think Rank and Labelling are a must. 
I'd personally avoid custom namespace reading, because we have no control over other
programs ( like CameraRaw, digikam, acdsee etc )
CustomeProfilebuilder is called (not tried): it could generate a new sidecar .xmp,
or even an old .pp3 should work.

@Michael:
Sent you libs by email.
Trash no-trash has nothing to do with labels, so why updating? Also, maybe the call
to updatecache() is reduntant, it is enough saveXMP(). The relative tags are not in
procparams, as they (Rank and Labelling) are global properties of the thumbnail and
saved as global tags in xmp.
>Glib::ustring paramFileExtension = ".pp3";
Thank you for pointing out, I'll check. There are several implications of this change;
extension is only a part. But for this case and going on I'll consider only .xmp. .pp3
is read only the first time the thumbnail is found by RT, IF there is no .xmp file
already.

Work is in progress... thank you all for suggestions.

Reported by ffsup2@yahoo.it on 2011-08-20 13:00:35

[Beep6581]

Very good, thanks.

> should we revert to use only xmp tags 
Since many program mostly understand EXIF/IPTC I guess it would be sensible to write
both, so IPTC as normal tag and XMLified in the XMP tag. However since they should
be in sync, guess it would be good to have just one UI input field for IPTCs and copy
it to both.

> CustomeProfilebuilder is called (not tried): it could generate a new sidecar .xmp,

> or even an old .pp3 should work.
Great, I'll update it then.

Reported by oduis@hotmail.com on 2011-08-20 15:27:03

[Beep6581]

Parameters (.pp3) saving is currently done:
1 - when an image is added into the batch queue, to save the work to be done. Developing
parameters are saved in a .PP3 file to recover in case of closure of RT.
2 - When an image is developed if proper option is enabled (save parameters next to
output file), either for batch queue, for single saving, or through command line.
3 - When a profile is saved with dedicated button.
4 - When a thumb is developed the parameters are saved in cache.
With the move to sidecar xmp, some changes would occurs:
1- is not important the format, but I'd rather use now xmp, maybe the same sidecar
xmp with a special snapshot for queue.
2- this option is superfluous IMHO, and other files of parameters next to output are
no needed, but we need a snapshot of the parameters saved into the sidecar .xmp
3 - Processing profiles should become xmp ! ?
4 - Do we really need a cache for parameters if there is already a sidecar xmp?

Reported by ffsup2@yahoo.it on 2011-08-24 21:32:17

[Beep6581]

Agree 1, 3, 4 (I'd vote for throwing out the params cache completely)

2 - Why should the sidecar XMP not be saved when an image is saved? The way it is now
sound reasonible to me.

Reported by oduis@hotmail.com on 2011-08-25 06:06:04

[Beep6581]

2)I explain better. Now, the processing parameters used to develop a shot are saved
in a pp3 file next to output file; there is no other place where to save them!
My proposal is to save the processed parameters inside a snapshot of the sidecar .xmp
(next to original raw).
I usually move all jpeg processed from the output directory to other places, and find
not very usefull the .pp3 files linked to output file (if present in output dir).
One cannot reproduce the same output with them (directly), but only if .pp3 are copied
next to original raw when openint RT, or user has to browse disk and load that profile.

So if you vote for not including whole original xmp into output file, the same way,
I think it's better leave these parameters inside "source" xmp.

Reported by ffsup2@yahoo.it on 2011-08-25 07:20:52

[Beep6581]

I agree with comment 33 - keep snapshot of last developed params in the *SINGLE* XMP
file next to orig image. 

I also don't see much use of XMP in cache

Reported by michaelezra000 on 2011-08-25 11:30:42

[Beep6581]

I am very happy to see progress of XMP feature.

Some comments (different as usual).

1) XMP next to RAW only (no cache).
How about editting files in DVD or other read-only directories? Where sidecar is stored?
I feel cache is still needed, but I think it should named differently. I feel it like
internal database.
Operation: 1) Read both, newer (or next to RAW) have higher priority 2) write both
if possible
Plus side there will "backup" of XMP file.

2) XMP next to RAW/next JPG
When generating two different output file from one RAW, both processing parameter are
saved if put in next JPG.
Or in input RAW output parameter are saved based on output file (several processing
parameter in one file).
I feel original idea is good (not lost processing parameters), but maybe this can solved
more clever/simpler/usefull way.

3) Need clear plan/requirements when add feature in production.

Example:
Mandatory
A) Dont break existing XMP. (OK)
B) No loss existing information PP3 -> XMP. See point 2
C) XMP saved safely. See point 1
D) reset XMP. maybe reread from RAW and overwrite XMP data.
E) Rank compatible with Bridge 
F) labeling compatible with Bridge 

Optional
G) read EXIF/IPTC and XMP to write XMP
H) write EXIF/IPTC (write both places)
Future
I) Rank and labeling compatible other programs
J) other fields
K) History/Snapshot saving 

I feel above is about plan already when I read comments I just like to see list.

4) Saving processing parameters to XMP sound OK to me.

Reported by GreatBull69 on 2011-08-28 07:01:45

[Beep6581]

New update on this development: I refined management of RT data in snapshots.
Now Add and Delete bookmark should works... let's talk.
Profiles are now in xmp form: RT loads only xmp from profiles directory, but can load
a single .pp3 and convert it.
I'd like an opinion on disk icon presence on thumbnail, as actual is not... meaningfull
I stress we must have a review on properties persistence: there is default and neutral
for example.

Reported by ffsup2@yahoo.it on 2011-09-08 22:59:11

---

• Attachment: xmp3Patch.zip

[Beep6581]

> I stress we must have a review on properties persistence: there is default and neutral
for example.

Do you mean display of embedded thumb vs default profile?
If so, embedded thumb does not have "edited" green checkmark.

I'd like an opinion on disk icon presence on thumbnail, as actual is not... meaningfull
I do find that little icon useful, it helps me filter out images that I have/not converted/saved.
I suppose you imply that once image is adjusted again icon is removed. I think it is
OK, as long as is is clearly mentioned "Saved (converted/exported) *after the last
adjustment*" (possibly in the tool-tip on the corresponding filter?)

Unfortunately I could not yet compile 64 bit dependencies to test this.

Reported by michaelezra000 on 2011-09-09 02:16:23

[Beep6581]

I try patch but it failed (see attachment).
I read code but I lost when I try figure out what is value of kXmpProcessing.
"disk icon presence on thumbnail". Check mark processed and not processed? (how about:
red: not done, none: done)
Some comments in neutral.xmp file.

Reported by GreatBull69 on 2011-09-09 02:39:33

---

• Attachment: [patch failed.txt](https://storage.googleapis.com/google-code-attachments/rawtherapee/issue-473/comment-38/patch failed.txt)
• Attachment: neutral.xmp

[Beep6581]

Disk Icon reflects if last edited changes are saved (this property is now saved in cache
file). But inside xmp there could be several changeset: each changeset has the property
"Saved" and "outputFile". When a shot is processed and saved a new snapshot is created
with that properties (also for queued batch processed items). For example, you can
edit a photo, save two snapshot, and exit; then reopen the photo and do some changes
again, but not save: then current behaviour do NOT show disk icon even if there are
2 version of the photo processed and saved (you can recall their parameters).
A different implementation could search for saved snapshots and show Disk icon if there
are any,(maybe also check presence of output jpeg?)

@Michael I didn't try to compile exiv2 64 bit yet. Can I help you?

Sorry rtXmp.h is lacking: (I'll repack this evening)

@GreatBull
kXmpProcessing = "Processing" as all other labels kXmpxxx used, are constant.
About neutral.xmp: thank you for comments! This is the kind of help I was requesting.

Properties saved are subdivided into groups a little differently than in pp3: the idea
is to group by "tools", in  future looking manner when we'll revise architecture in
modules. It's important to do a good job now with this new format because it will be
hard to change in future. I'd insert for each tool the property "Enabled", maybe also
for Exposure tools?.

>!! Use profilename?
Do you mean assigning a user name different from filename or a description?

>Capitalization for properties: right! It should be consistent. I didn't find a "must"
rule in specification, but I saw all are first capital letter.

>!! EnableSaturationLimit/SaturationLimitEnabled ?
SaturationLimitEnabled

>!! UnderGeometry?
CoarseGeo is a different tool than Geometry, so this is why I put there.
Maybe Rotate could be "Angle" or "Degree" in each (I have to check the meaninig of
those parameters)

>!! CenterX ??? instead of X
OK.

Please note:
I divided current raw parameters into different sections.
Section Crop, not all props are saved ( discussion in other issue )

Reported by ffsup2@yahoo.it on 2011-09-09 07:28:03

[Beep6581]

Some explanation of my comments:

>Properties saved are subdivided into groups a little differently than in pp3: the
idea is to group by "tools", in  future looking manner when we'll revise architecture
in modules.
>>!! UnderGeometry?
>CoarseGeo is a different tool than Geometry, so this is why I put there.
I was thinking if possible have "higher" level definition then tool. I see tools can
change and tools related to gui. This case I like see them in same group because both
related same attribute "rotation-> geometry". Maybe my idea came too complicated so
better to stay in tool level.

>>!! Use profilename?
>Do you mean assigning a user name different from filename or a description?
filename. Some reason I think it can use refer back to file and
I was thinking at identify profiles by name so all profiles can be in one file. I don't
know is this good idea. Separate files is easy to manage but maybe there is other reason
to save them with image as used "base" profile.

Better idea maybe have
-Short name (used in selection)
-Tool Tip (Short description used in tool tip)
-Description (maybe future can show user long description what/why/how etc.)

Reported by GreatBull69 on 2011-09-09 12:32:11

[Beep6581]

Updated patch.

Reported by ffsup2@yahoo.it on 2011-09-09 18:27:14

---

• Attachment: xmp4.patch

[Beep6581]

Looks nice.

Output of exiftool in attached file. That is much easier to read then xml file. Good
also to person how want give comment but not like read xml.  
File generated:
exiftool filename.xmp

Looking output "Processing" should change to "RT".
Then there are parameters like:
Processing RAW Denoise Line Denoise -> ?

Processing RAW Arithmetic Flat Field Blur Type -> RT Flat Field Blur Type?
Processing RAW Arithmetic Dark Frame: -> enable???

Processing Color Management Apply Gamma Before Input Profile -> long but ??

Processing Color Management Gammafree: default
Processing Color Management Freegamma: False

Reported by GreatBull69 on 2011-09-10 04:28:16

---

• _Attachment: exiftool_output.txt_

[Beep6581]

Instead of prepending "RT" to every entry, does XMP allow putting all of them in a RT
sectioon without having  to prepend each?

Please don't capitalize "RAW", it should be "Raw" or "raw", just like you would write
"Processed" or "Cooked".

Reported by entertheyoni on 2011-09-10 06:35:04

[Beep6581]

Maybe this clarify:
clip from XMP:
...
   <rt:Processing>
    <rdf:Bag>
     <rdf:li>
      <rdf:Description
       rt:SnapshotName="####"
       rt:SnapshotId="1858721860"
       rt:Version="300">
      <rt:ExposureRGB
       rt:Auto="False"
       rt:Clip="0.001"
       rt:Compensation="0"
...
My comment was should
   <rt:Processing>
change to
   <rt:RT>
because then exiftool output looks better (my view). I think better repeat RT then
Processing (or RT processing). One line change in XMP. 

Reported by GreatBull69 on 2011-09-10 07:21:11

[Beep6581]

And maybe this need explained too:
"rt:" is related definition: see line:
    xmlns:rt="http://www.rawtherapee.com/1.0/"

And it looks OK for me. It looks same as exif.

XMP Start:
<?xpacket begin="" id="W5M0MpCehiHzreSzNTczkc9d"?>
<x:xmpmeta xmlns:x="adobe:ns:meta/" x:xmptk="XMP Core 4.4.0-Exiv2">
 <rdf:RDF xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#">
  <rdf:Description rdf:about=""
    xmlns:tiff="http://ns.adobe.com/tiff/1.0/"
    xmlns:exif="http://ns.adobe.com/exif/1.0/"
    xmlns:xmp="http://ns.adobe.com/xap/1.0/"
    xmlns:dc="http://purl.org/dc/elements/1.1/"
    xmlns:aux="http://ns.adobe.com/exif/1.0/aux/"
    xmlns:photoshop="http://ns.adobe.com/photoshop/1.0/"
    xmlns:xapRights="http://ns.adobe.com/xap/1.0/rights/"
    xmlns:Iptc4xmpCore="http://iptc.org/std/Iptc4xmpCore/1.0/xmlns/"
    xmlns:crs="http://ns.adobe.com/camera-raw-settings/1.0/"
    xmlns:rt="http://www.rawtherapee.com/1.0/"
   tiff:Make="Canon"
..
   <exif:ISOSpeedRatings>
    <rdf:Seq>
     <rdf:li>100</rdf:li>
    </rdf:Seq>
   </exif:ISOSpeedRatings>
   <exif:Flash
    exif:Fired="False"
    exif:Return="0"
    exif:Mode="2"
    exif:Function="False"
    exif:RedEyeMode="False"/>

Reported by GreatBull69 on 2011-09-10 07:48:36

[Beep6581]

Processing is A property of rt namespace (actually an array of structs) like Version
or Model, so don't agree to name it RT; it stands for "Processing Parameters", RT would
be too generic. Anyway, I don't think users would read often parameters in a file.
( do you read .pp3 often?) If you want a shorter name maybe "Process"?

OK for RAW -> Raw (sorry I'm always wrong)

Reported by ffsup2@yahoo.it on 2011-09-10 11:07:35

[Beep6581]

I use exiftool guite often. I don't look xmp much. I dont search short name. Just try
find correct one. Looks like "processing" can not removed. Process is much better then
processing.

This looks quite ok parameter name:
Process Exposure Lab Avoid Color Clipping: False

Reported by GreatBull69 on 2011-09-10 14:18:37

[Beep6581]

(Just some cheering from the sideline: I find this issue currently the most important
one and I am very thankful that you put so much effort into it!)

Reported by gyurko.david@e-arc.hu on 2011-09-10 15:39:48

[Beep6581]

Exiv2, built for win64bit.
I had a lot of troubles because a stupid tool searches for presence of the file libz.dll
instead of zlib1.dll! ( I had to copy it to hack)

Here is all (hope) is needed to compile.
http://www.4shared.com/file/1QFuSlUV/exiv2_0211_win64.html

Reported by ffsup2@yahoo.it on 2011-09-11 09:43:19

[Beep6581]

Applied xmp4.patch to 4.0.2.31, ran make clean and 
cmake -DCMAKE_BUILD_TYPE=release -DPROC_TARGET_NUMBER:STRING=1 -DCMAKE_INSTALL_PREFIX=rawtherapee
-DBUILD_BUNDLE=ON -DBINDIR=. -DDATADIR=. && make -j8 install
but fail during compilation:
http://paste2.org/p/1644634

Do I need to apply anything else? What are the dependencies?

Reported by entertheyoni on 2011-09-11 21:59:26

[Beep6581]

Well, there has been a little change after my patch was based on: gammaOnInput has been
removed, so you can comment following 2 lines in procparams.
/home/drslony/rawtherapee/rtengine/procparams.cc:417: error: 
/home/drslony/rawtherapee/rtengine/procparams.cc:643: error:  

I'm doing furher cleanups on this file, so I'll send an updated patch when finished.

Reported by ffsup2@yahoo.it on 2011-09-12 08:02:17