rawproc 1.0 Is Released on Github

I finally decided to call what I’ve been futzing with over the past ten years 1.0:

From here on, I’m going to publish a periodic release with accumulated bug fixes and updated libraries, particularly Libraw for new cameras.

It now does all I need for raw processing, and thanks to PlayRaw it supports a large collection of cameras. I still have things to do to it, however:

  • ACES/OCIO support, of some sort…
  • librtprocess goodness: chromatic abberation correction, highlight recovery, and whatever else @heckflosse puts into this outstanding library offering
  • A better color saturation algorithm. The OKLab thread is one candidate for this.
  • Other things I can’t recall at the moment.

While rawproc is fully usable in a raw workflow, my main motivation for writing it was to provide a teaching tool, both to me individually and in dialogue with others. To that end, I 'm going to make a couple of videos, one touring the panels and menus, and another walking through the processing of a raw file into an image rendition. I’ve found the G’MIC-inspired toolchain approach to be profoundly instructive, laying explicit the steps needed to go from raw measurements to pleasing renditions.

Anyhoo, FWIW…

20 Likes

Is it a RAW editor? In github it’s not saying what it is/does. But since you post it here I presume it’s related to do something with (RAW) images :wink:

Woohoo congrats!! Just in time.for the new year!

Hello @ggbutcher

Thanks a lot. Just tried on Windows 10 :slight_smile:

I have noticed you are still using the wxWidgets.
In the past you wrote on this forum you were pondering about a possible move to QT for your GUIs

It is extremely interesting because your application is the “geekiest” one among a bunch of other very powerful open source softwares showcased in this forum: RawTherapee (ART), Darktable etc :slight_smile:

It would be extremely useful to watch some video tutorials about the ins and outs of this software of yours.

For instance, I didn’t find a way to choose the “method” (sorry for my layman language) to demosaic my NEFs files (Nikon D850): Amaze, RCD etc
With Rawpedia (the online manual of Rawtherapee) there is a short paragraph about their different usecase and by reading this forum it looks like RCD is currenlty among the best (even compared to Amaze).
I, for instance, always take all my macro pictures, at work, at 2850K (with an Elinchrom lamp in our plant pathology laboratory).

If I might also make a suggestion I would propose to add the version of Rawproc in the Title bar, on the upper left. It is useful when you take screenshots, to quickly visuallly report what version are you testing.

Anyway, happy new year 2021 and thanks a lot for your application!

Congrats @ggbutcher!

@ggbutcher probably wouldn’t mind you calling him a geek. :stuck_out_tongue:

You are correct. It is kind of hard to find things, which is partly why I haven’t latched on yet. That, and I have been waiting for this version. :wink:

Yep, this is one of the things I always pester people about.


PS
1 Image mouse over tool tip is a huge block of text. Disappears before I finish reading it. Maybe give user a quick shortcut (in the menu or from the keyboard) to access this info in help or an alert.

Edit: Maybe instead make tool tip toggle mean displaying tool tips permanently or not on hover. Right now, it just enables/disables tool tips. The thing about tool tips is that it doesn’t always show on hover, so it can be inconsistent and therefore confusing.

2 Include lens data in package from the start, or ask user to do so at launch. Doesn’t matter if it is out of date to being with. Give Data update… menu option a more descriptive name.

3 Add GUI access to define exiftool path. Consider including it in package, or ask user to do so at launch.

4 Rename blackwhitepoint:rgb,… or its corresponding menu option to match. Auto is kind of confusing. For Infinite Sticks, it goes to 0,13. Moreover, other values are between 0,1, make values consistent in this module: either 0,255 or 0,1.

5 A version_2 folder gets created in the same directory as the raw file being processed. It should be in rawproc’s instead.

6 Does rawproc only save JPGs? If so, batch should fill *.jpg in output field as default to avoid first time unspecific prompt :wink: because it is empty. Kill and dismiss, etc. aren’t necessary. :skull_and_crossbones: OK is friendlier.


Opened the jpg to see this.

image

This is a nice present to close this ugly year with.

Thanks Glenn and a happy 2021 for you and yours!

EDIT - Just a heads-up for those that might run into this:

  • I’m on Debian (10.7/Buster) which means that the glibc in use is version 2.28 and this is too old for the appimage, which needs 2.29 or better.
  • I’m not able to build the rawproc-1.0.tar.gz version. It complains about icc_profile.h not being present. Not sure if this is me or something else.

But:

  • Cloning and building, including all the requisites and goodies, using git works like a charm though!

I do see this message when loading an image, which isn’t a showstopper when the ‘Show this dialog…’ is disabled:

And in the terminal I see many of these:

/home/jade/.local/git/wxWidgets-3.1.2/include/wx/strvararg.h(445): assert “(argtype & (wxFormatStringSpecifier::value)) == argtype” failed in wxArgNormalizer(): format specifier doesn’t match argument type

Good show Glenn!

Just FYI, I chose to install the Windows .exe in a folder other than c:\Program FIles, it installed itself in c:\Program FIles anyways (and .dat and uninstall files in the location I indicated) but then it couldn’t find itself :slight_smile:

RawProc Error

It did run after clicking rawproc.exe a couple of times in the ‘wrong’ location.

Oh, I love it!

All the comments and suggestions are goodness; one can stare and stare at what works for them, and never fully understand how it really works until others give it a go. I’m going to be a little tied up until Monday, getting our son out the door and on the way to the South Pole, but I’m probably going to roll a v1.1 in the next couple of weeks to address what I just skimmed through in your comments. I will try to post specific feedback, to get folk going soonest.

I really don’t expect anyone to make rawproc their primary raw processor; it’s a lot harder to use than any of the other tools we discuss here. But, I encourage using it to experiment, as I’ve found there’s nothing more poignant in learning this business than explicitly stacking the operators yourself, to see what they’ll do for good or ill…

Thanks!

Thanks for that. I changed the subject line recently to emphasize that the program can also be used for other images, but it looks like it lost the primary emphasis on raw files. rawproc is first and foremost a raw processor. No alpha channels, no pallettes, and all that.

In the Commands pane at top-left, click on the demosaic tool, then look in the Parameters pane at bottom-left, and you’ll find all the available demosaics for the camera that made the loaded raw file. I see ‘half’ is selected in your screenshot; scroll down the paramters a bit and you’ll find rcd.

Danged .h files; they just work without having to put them in the automake input, until something like this.

Regarding the AppImage, I’m using a script that downloads the library exclusion list from AppImage HQ, and it probably doesn’t realize the current reality. After reading the DisplayCal python woes in the other thread, I’m thinking of abandoning the exclusion list altogether, but it’ll make a much larger AppImage…

Jack, you might be better-served with the .zip file. Thing is, you’ll then have to do a few other things to make it work right, particularly with setting the PATH environment variable and setting up a directory for the .conf and data files.

After some inspection, figured out that this is due to some cuteness I wrote into the wininstaller file to accomodate 32-bit vs 64-bit variants. I’m dumping the 32-bit one, so I’ll be rewriting that file to be a lot simpler and more compliant with what Inno Setup expects.

Right now, I have to recommend not changing the installer-specified install path. Also, if you want img to work without manual path shenanigans, let the installer add the path to the executables to the PATH variable.

1 Like

I too am interested in this decision.

RAF file type unknown.

xtran_ should be xtrans_

Hmm, in the linux rawproc I’m opening all the .RAFs I can find. Can you post the wayward RAF? Also, what OS…?

Cripes, it’s in the command/tool syntax. I’ll probably alias it.

I did mostly reading up on Qt until I decided to focus on fleshing out a complete toolset and workflow support. I’m probably in a better situation now to consider a UI change because I’ve re-factored the image library access to a text-string command interface, so now the command line program (img) and the GUI program (rawproc) both use it.

Thing is, I’m a long-time wxWidgets programmer. Written things for both personal and professional objectives, and I can pretty well whip out an application shell by memory. And, there’s no user-facing angst about cross-platform; it just works consistently in both Linux and Windows. I can statically link it, so one might notice there’s no (well, not as much as it would be…) library bloat in the AppImage.

Now that I have in rawproc a tool that supports my shooting and workflow, I’ll return to considering it…

1 Like

As far as Qt and bloat are concerned, Filmulator is a scant one megabyte bigger in terms of appimage.

1 Like