[fix] DjVu gamma correction #921
Conversation
The existing implementation only worked in 8-bit mode. By using the `ddjvu_format_set_gamma()` function that comes with djvulibre it suddenly and attractively becomes Not Our Problem™. I noticed this after doing a quick experiment with a custom power function `#ifdef __ANDROID_API__` like in https://stackoverflow.com/a/19488271/2470572 (For example, if Android define a custom power function, else `#define power(x, y) pow(x, y)`.) I believe the proper way to go about it would probably be to ignore document-specific implementations and to do it in the blitbuffer, but this is quicker. As a side effect, this fixes koreader/koreader#3493.
|
Illustration of the problem (because pixels are 24 bits here instead of 8):
|
| @@ -654,6 +656,20 @@ static int drawPage(lua_State *L) { | |||
| BlitBuffer *bb = (BlitBuffer*) lua_topointer(L, 3); | |||
| ddjvu_render_mode_t djvu_render_mode = (int) luaL_checkint(L, 6); | |||
| ddjvu_rect_t pagerect, renderrect; | |||
| // map KOReader gamma to djvulibre gamma | |||
| // djvulibre goes from 0.5 to 5.0 | |||
There was a problem hiding this comment.
What happens when you give it < 0.5 or > 5.0 ? which can happen if one hacked koptoptions.lua to extend boundary values.
Which it seems I once did, I have that in my own patch:
name_text = S.CONTRAST,
buttonprogress = true,
- values = {1/0.8, 1/1.0, 1/1.5, 1/2.0, 1/3.0, 1/4.0, 1/6.0, 1/9.0},
+ -- for pdf reflowing mode (kopt_contrast):
+ values = {1/0.8, 1/1.0, 1/1.5, 1/2.0, 1/4.0, 1/6.0, 1/10.0, 1/50.0},
default_pos = 2,
default_value = DKOPTREADER_CONFIG_CONTRAST,
event = "GammaUpdate",
- args = {0.8, 1.0, 1.5, 2.0, 3.0, 4.0, 6.0, 9.0},
- labels = {0.8, 1.0, 1.5, 2.0, 3.0, 4.0, 6.0, 9.0},
+ -- for pdf non-reflowing mode (mupdf):
+ args = {0.8, 1.0, 1.5, 2.0, 4.0, 6.0, 10.0, 50.0},
+ labels = {0.8, 1.0, 1.5, 2.0, 4.0, 6.0, 10.0, 50.0},
+ -- see https://github.com/koreader/koreader/issues/1299#issuecomment-65183895
name_text_hold_callback = optionsutil.showValues,There was a problem hiding this comment.
(I mean: I don't mind having my higher values limited and causing no change from previous values - just want to be sure there could be no crash or strange things.)
There was a problem hiding this comment.
djvulibre ignores out of bound values.
(One wonders if it wouldn't make more sense to cap them instead of to ignore them completely, but that aside.)
There was a problem hiding this comment.
it wouldn't make more sense to cap them instead of to ignore them
I think you should cap them, after your gamma = A - B*gamma s, as they could give out of bound values, so better to have them capped that suddenly getting back with no gamma change.
See koreader/koreader-base#921 for details. Fixes koreader#3493 as a side effect.
See koreader/koreader-base#921 for details. Fixes #3493 as a side effect.
See koreader/koreader-base#921 for details. Fixes koreader#3493 as a side effect.
The existing implementation only worked in 8-bit mode. By using the
ddjvu_format_set_gamma()function that comes with djvulibre it suddenly and attractively becomes Not Our Problem™.I noticed this after doing a quick experiment with a custom power function
#ifdef __ANDROID_API__like in https://stackoverflow.com/a/19488271/2470572(For example, if Android define a custom power function, else
#define power(x, y) pow(x, y).)I believe the proper way to go about it would probably be to ignore document-specific implementations and to do it in the blitbuffer, but this is quicker to implement.
As a side effect, this fixes koreader/koreader#3493.