Bugs export color

Yes hello, I have a big bugs the result between what the application shows does the photo show after recording is completely different, a solution to correct this problem or to reboot?Capture

It’s probably a colour management issue. Perhaps your photo viewer lacks support for colour management or is configured to use a different profile?

Perhaps the above makes no sense to you but image editing and viewing software should apply a sort of filter to adapt to your screen. If these filters/profiles are misconfigured in either software you’ll end up with them looking different.

1 Like

The problem is that yesterday and this morning the software worked very well and with zoom the colors return to normal so I do not see why without zoom it’s like that, it’s still really annoying to have to all the time zoom, after there is no way to reset the whole application?

Yes, there’s a bit crude way of resetting the application, but first you may wish to start processing again your image by applying a Neutral profile, which will reset all the tools (not the application).

And as always, it is a good idea reading RawPedia, specially the Editor page

I already know how to use neutral profiles

I found the bug is due to the “dynamic range compression” which is almost full, so it must do too much calculation for my pc

1 Like

@Renardina Two things can be happening here:

  1. All tools with the icon 1:1 in RawTherapee can only be accurately previewed at 100% zoom level. This is because it would cost too much computational power otherwise.
  2. Windows Photo Viewer (which you seem to use) may not be properly colour managed (as @nosle mentioned).

Both of these can be the cause of the different colours.

1 Like

With your 1:1 icon tool theory, a good way to test that would be a comparison screenshot with both Rawtherapee and the image viewer at 100% view.

From my experience, it seems most probable that this is the Dynamic Range Compression tool in action here, given the nonlocal tonemapped appearance of the photo viewer render, relative to the Rawtherapee preview.

It seems like the best way to fix that discrepancy would be to either use a different tone mapping operator that is to do the DRC on the whole preview low res image with appropriately scaled parameters to roughly match the lower size of details relative to output render. Also, a computationally cheaper for preview at less than 1:1 tonemapping operator could be used or make the output of dynamic range range compression be approximately histogram matched to the input. This third option would also have the side benefit of making DRC more suitable for video raw processing use, by increasing the temporal stability.