I'm not able to build ART anymore (Linux)

Software ART
1

Hi all,
today I tried to build art (with build-art script, as usual) and the script not worked.
The output of the script is:

[ 45%] Building CXX object rtgui/CMakeFiles/rth-cli.dir/options.cc.o
/home/sysop/programs/code-art/rtgui/main-cli.cc: In function ‘int processLineParams(int, char**)’:
/home/sysop/programs/code-art/rtgui/main-cli.cc:863:87: error: no matching function for call to ‘rtengine::procparams::ProcParams::saveEmbedded(Glib::ustring&)’
                 if (!options.params_out_embed || currentParams.saveEmbedded(outputFile) != 0) {
                                                                                       ^
In file included from /home/sysop/programs/code-art/rtgui/../rtengine/rtengine.h:25:0,
                 from /home/sysop/programs/code-art/rtgui/options.h:25,
                 from /home/sysop/programs/code-art/rtgui/main-cli.cc:34:
/home/sysop/programs/code-art/rtgui/../rtengine/procparams.h:1577:9: note: candidate: int rtengine::procparams::ProcParams::saveEmbedded(rtengine::ProgressListener*, const Glib::ustring&)
     int saveEmbedded(ProgressListener *pl, const Glib::ustring &fname);
         ^~~~~~~~~~~~
/home/sysop/programs/code-art/rtgui/../rtengine/procparams.h:1577:9: note:   candidate expects 2 arguments, 1 provided
[ 45%] Building CXX object rtgui/CMakeFiles/rth.dir/adjuster.cc.o
[ 45%] Building CXX object rtgui/CMakeFiles/rth-cli.dir/paramsedited.cc.o
rtgui/CMakeFiles/rth-cli.dir/build.make:110: recipe for target 'rtgui/CMakeFiles/rth-cli.dir/main-cli.cc.o' failed
make[2]: *** [rtgui/CMakeFiles/rth-cli.dir/main-cli.cc.o] Error 1
make[2]: *** Waiting for unfinished jobs....
[ 46%] Building CXX object rtgui/CMakeFiles/rth.dir/alignedmalloc.cc.o
[ 46%] Building CXX object rtgui/CMakeFiles/rth.dir/batchqueue.cc.o
[ 47%] Building CXX object rtgui/CMakeFiles/rth.dir/batchqueuebuttonset.cc.o
[ 47%] Building CXX object rtgui/CMakeFiles/rth.dir/batchqueueentry.cc.o
[ 47%] Building CXX object rtgui/CMakeFiles/rth.dir/batchqueuepanel.cc.o
[ 48%] Building CXX object rtgui/CMakeFiles/rth.dir/bayerpreprocess.cc.o
CMakeFiles/Makefile2:180: recipe for target 'rtgui/CMakeFiles/rth-cli.dir/all' failed
make[1]: *** [rtgui/CMakeFiles/rth-cli.dir/all] Error 2

The last version I built without error is: 1.4-14-g88ad2581a

Thanks for help

2

Sorry, my bad. I’ll push a fix asap

3

should be fixed now – sorry for the inconvenience!

BTW, this was due to a new feature that I’ve just added, i.e. the option to store the processing parameters in the output image metadata. This is enabled by selecting this (in the preferences):

Screenshot from 2020-08-08 19.26.38
Screenshot from 2020-08-08 19.26.38958×428 45.2 KB

when using this (in the queue and/or save dialog):

Screenshot from 2020-08-08 19.27.01
Screenshot from 2020-08-08 19.27.01812×171 16.1 KB

I much prefer this over having sidecar files for each output image generated – hopefully it might be useful for somebody else too…

1 Like
4

Continuing this off-topic for a moment.

Hi Alberto, @agriggio. Cool! Without inspecting your source, do you compress the processing parameters? I have some pp3 files of 15 kB, and iirc there is a 64 kB size limit for Exif. Adding 15 kB is quite a hefty addition. Also, in which tag do you store it? Can you also extract it again somehow?

5

Hi,

Zip compressed and base64 encoded, then stored in a custom xmp tag.

Well yes, otherwise there wouldn’t be much point I think… Anyway, you can just use the output image as a sidecar (I.e. when you load the parameters from file, if you select a jpg with embedded arp, it will be extracted and used). This is not new btw, at least darktable and iirc rawproc do something similar (and possibly also other tools)

2 Likes
6

Lovely! :smile:

7

Does the output jpg with the embedded Metadata have to be in the same folder as the raw file if you want to use it instead of a sidecar file for editing the raw file?

8

Here’s one! Welcome addition, thanks.

9

It’s not used automatically. The parameters are still saved in the arp sidecar for raw files. But you can use the jpg by loading it explicitly. It’s meant to replace the arp files that are generated on output, not the master arp for raw files. That is not going away…

1 Like
10

That makes sense thanks.

11

Salut Alberto,

I just noticed that when I say ‘Save processing parameters with image’ and I save a raw file twice as jpg and 16-bit tiff, the last one lacks a lot of exif info (shutter speed, aperture, etc.).

12

Hi,
Thanks, I’ll take a look. Two questions:

  • how did you check?

  • does it work if you don’t embed the parameters?

13

I checked that in gThumb and Geeqie. It works normally when I don’t embed the parameters (just like before).

14

Ok thanks. Can you share the raw and arp?

15

I noticed a second thing. I switched off ‘Save param in image’ in the Save dialog and saved as tiff again. No arp to be seen. Then I said in Prefs | Im.Proc ‘Save as a sidecar file’ (was still at save in img). Saved again, again no arp file.
So no need to upload a raw at this point I guess.

16

Hi,

As you wish…

17

Hello, let’s drop this for the moment, after a restart it seems to work fine, sorry for the noise.

18

Me again. The exif data gets truncated when you say in Prefs ‘Save metadata in image’ AND you say in the Save dialog the same AND you save as 16-bit tiff. JPG is okay. Repeatable.

Second, in the Save dialog I was confused by the option ‘Save proc. param. with image’, I thought it would embed these data into the image. But that’s not the case. Better change the description to 'Save proc. param. next to image.

You stil want a NEF?

Regards, Paul.

19

Hi,

It’s really simple: the easier it is for me to reproduce, the higher are the chances to get this fixed quickly. Unless you are absolutely certain that it has happens for all raw file types, for all camera models, and for all processing parameters, the yes, I do want your nef and arp. If you are uncomfortable with sharing something sensitive, you just send me a dark frame, as long as it triggers the problem. Thanks!

This has been like that for a number of years, and it has always produced an extra sidecar file…

20

I know that, but the confusion arised from the new option in Prefs. My fault.

DSC_6506.aRGB.NEF (18.8 MB)

And the arp
DSC_6506.prefs.off.save.off-1.tif.out.arp (12.3 KB)