Rawtherapee: Roadmap for 5.3

Created on 27 Jul 2017  路  47Comments  路  Source: Beep6581/RawTherapee

As suggested by @agriggio it would probably be good to release 5.2.1 with the camconst.json updates and whatever other updates soon.

I'm thinking we give it a week or two. Maybe some bugs will surface in the meanwhile.

@iliasg are there any other changes pending?

@benitoite could you try git tag -a "5.2.1" -m "test" on your end, then run ./tools/generateReleaseInfo and then your macOS scripts, to see if anything breaks with the x.y.z version scheme?

roadmap

All 47 comments

@Beep6581
Yes, some changes are pending for the next week

  • regarding Pentax DNG files. We have to put some changes in dcraw.cc so that the WL reported by Pentax DNGs is ingnored. We have to do this because Pentax uses a non standard WL (reports the WL after BL subtraction)
  • some refinements in camconst.json

We have to put some changes in dcraw.cc so that the WL reported by Pentax DNGs is ingnored.

I won't be able to do that before August 6th

@heckflosse I can give it a try if @iliasg tells me what to do exactly

@Beep6581 x.y.z scheme worked fine.

Thanks for testing @Benitoite !

I'm personally not keen on rushing for a new release (lots of work at work + I need a vacation, starting to feel burned out). If you want to start work on one of the major issues (use Exiv2 for metadata #3801, consolidate the pipelines #3897, painting on canvas maybe #2239, integrate rawspeed, etc.) then of course we can make a 5.2.1 release with cherry-picked bug fixes. Until such work is started, I'm happy to wait and see what smaller fixes find their way into dev.

Before exploring Exiv2 for metadata, let me commit my patch for multiframe handling that touch the Exif handling part. Will do that tomorrow or today in a separate branch.

Changelog so far:

Features:

  • CIECAM02 module enhanced.
  • camconst.json updates.
  • New human perception-friendly theme "TooWaGrey - Average Surround" added.
  • RawTherapee GIMP plugin more user-friendly,

Fixes:

  • macOS text issues fixed.
  • Add/Set fixed.
  • Navigator panning fixed.
  • Canon PowerShot G5 crash fixed.
  • Lanczos resizing crash fixed.
  • Theme improvements.

Could we include cacorrect_speedup @heckflosse and multiframe-handling @Hombre57 ?

Then there are some open branches whose status is unclear:

  • [x] ciecamtest @Desmis
  • [x] coverity-fixes @heckflosse
  • [x] valgrind_fixes @heckflosse
  • [x] remote-app @heckflosse
  • [x] options-save-raise-exception-on-failure @agriggio

I will try to focus on testing waveletnew over the next few days.

@Beep6581 I guess that my branch is sufficiently stable to be merged, however I prefer that @heckflosse give it a try and agreed on the merge. He's returning from holidays this Sunday, so I expect to have an answer by Wednesday.

@Beep6581
ciecamtest : I can merge this small change when you want :)

There is no changes in waveletnew, since long time...more than 1 year ....except a modification in Retinex (not retinex for wavelet), I add chroma.
It is difficult to keep up to date this branch (about 50 events!)

Probably I think there will be a general agreement for functions such as "retinex in wavelet" and "sharp mask and clarity"
For other additions "Merge files and watermark"?? It is always possible to disable GUI...If there is no global agreement :)

There is probably some functions which work poorly due to numerous updates !

@Beep6581
I have extend commit june 2017, to "double" ( commit 1e5382a)

Then I just delete branch ciecamtest
Jacques

Thank you @Desmis

I liked some of the additions in "newwavelet" when I tested it a long time ago, but there were also some issues and I didn't have time to investigate them. I will try to find time to do that, so that waveletnew can go into 5.3.

I have a small feature that could go in 5.2.1 if there is interest. it allows the user to save the expanded/collapsed status of tools "by hand", instead of having RT remember the status on exit. I find this extremely useful and have been running it for a couple of months now. if that's ok, I'll create a pr tomorrow

There was user interest in a such a feature, why not.

@Beep6581

Could we include cacorrect_speedup?

As I'm back home now I will make some tests again on my main machine. If these tests are ok and I get another ok from at least one dev (@Desmis for example) that the differences in output are ok, I'm fine with merging

@heckflosse
I just test with and without patch, no differences (or very very small...)

God job
Jacques

options-save-raise-exception-on-failure @agriggio

I think this can be merged. Shall I do it or would you @Beep6581 ?

@agriggio go ahead. Btw please see https://github.com/Beep6581/RawTherapee/issues/4010

@Hombre57

I just built and tested multiframe-handling. I cleared the cache and all the pixelshift thumbs have a beautiful new PS indicator which is great :)

However, there are some issues:

1) when I try to open a PS PEF file I get this. PS DNG works fine

terminate called after throwing an instance of 'std::out_of_range'
  what():  vector::_M_range_check: __n (which is 3) >= this->size() (which is 3)

2) The info of PS DNG files shows this

pswrong

3) non PS files info dialog is also broken as shown in this arw example

nonpswrong

nonpscorrect

3983 should be done for 5.2.1.

I'll try to fix both tonight.

@heckflosse Please comment on the Multi-frame handling in issue #4008. I'll answer there.

As this next release will have some new features (hooray!) I wouldn't mind calling it "5.3", as "5.2.1" would imply only bugfixes. What are your thoughts?

@Beep6581 calling it 5.3 is fine for me :+1:

You could even call it 5.3.0

calling it 5.3 is fine for me too

no problem for 5.3

Fine for me too for 5.3.

Could you add #4014 to the list for 5.3 ? It's a serious flaw in the GUI and I'm almost done with the fix.

Anything anyone wants to squeeze in for 5.3?

@iliasg are we fine on the camconst side?

As for myself, I will update rtexif using ExifTool-10.61 this week (#4055), then I'm happy to release.

afaik @Hombre57 is still working at #4008 multiframe-handling

I have a last-minute request. I'd do it myself, but I'm just not skilled enough to :cry:
I'd like to have a dedicated button for "fast export" in the bottom toolbar of the editor window, next to the "normal" export one. Of course, adding a button is trivial, but the tricky part for me is designing the icon... I was thinking of a "fast moving" version of the two gears we use for the export action, for example by adding some motion lines, similarly to the "moving" RT logo we use for the "processing profile operations" context menu.

What do you think about this? Is there anyone that would be willing (and able :-) to provide the icon? Once I have that, I'll take care of the coding part.

No problem with the icon, I can take care of that, but we've seen new users mistake the "fast export" feature for being the actual export method, and adding a fast-export button under the preview would only reinforce this - how would we handle that? And adding a new button there would further increase RawTherapee's required minimum width, which on my no-scaling 10pt-font screen currently is 1627px in the Editor tab with the left and right panels visible - see #4035.

On a side note, what do you use fast export for? I ask because I've never used it and wonder whether I'm missing out on something...

Ok if you think this is a usability problem -- I can live with the current behaviour.

For the record, I use the new fast-export (i.e. the one that works by resizing early in the pipeline rather than disabling expensive steps) quite a lot when I have to process many "non-critical" shots on my old laptop (whatever that means -- none of my shots is actually critical :wink: -- but think e.g. some family snapshots or parties with friends etc.). It is a real time saver (up to 5x faster, depending on the tools that are enabled) and the quality is very close for my normal workflow.

I'm with @agriggio. Since there's this new fast export, I use it a lot to instantly batch process images to web size. It's faster, and I appreciate the fact that the export size is not written to the pp3.
I would appreciate a dedicated button, because it is faster than using the right click context menu, and also because I often click on the regular export by mistake in this context menu.

I've nothing against this and I will help with the icon if you want to go forward with it, but then we really need to either commit #4035 or have someone more skilled implement something better than my manual checkbox (i.e. automatically re-flow the contents of the iops panel if the requested width cannot be allocated - and the same goes for the editor panel at the top).

@agriggio @Beep6581 For the fast export, the fast solution would be to use a modifier key (e.g. CTRL) to do a fast export instead of an export. That won't be visible to the user (excepted in the tooltip), but would be perfectly usable w/o requiring more space.

@Beep6581 I'm 98% done with my patch of multi-frame image support. However you can edit rtexif, or edit the one of the multi-image branch if you don't mind (I'll update rtexif.cc in an hour or so, still one bug to crush).

I like the modifier-key idea.

@Hombre57 I will wait for the merge before updating rtexif.

well, the modifier has been there since 5.1 :-) ctrl+shift+b does fast export. I still think this deserves its own button, but as I said it's no big deal

Time is running out. I will branch off a feature-frozen 5.3-rc1 (release candidate 1) tomorrow, followed by 5.3 final later in the week if no serious issues arise.

Latest updates and fixes from dev merged into release-5.3-rc1
There will be at least one more update with some DCPs tomorrow.

I made a Windows 64 build from the release-5.3-rc1 branch (the bundle includes the lensfun database).
Download link and discussion here: https://discuss.pixls.us/t/win64-rawtherapee-5-3-release-candidate-1-for-testing/5194

I will tag 5.3 in a few hours, if anyone has any requests now is the time.

Sorry for not opening a new issue .. Just a small request (I hope ..) .. because the code for X-A10 in dcraw.cc https://github.com/Beep6581/RawTherapee/blob/dev/rtengine/dcraw.cc#L9063 failed to do the job

if (!strncmp(model,"X-A10",5)) {
+        raw_width = 4912;
+        raw_height = 3278;
+    }

I think we have to add

+        width = 4912;
+        height = 3278;

Sorry, I'm not touching dcraw code just before a release, and Ingo is on the road.

As far as I know all issues are resolved, so I will tag 5.3 in an hour or two.

RawTherapee 5.3 is released!

Was this page helpful?
0 / 5 - 0 ratings