New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Poor image quality in epub files... #1833

Open
djalma2k opened this Issue Feb 18, 2016 · 15 comments

Comments

Projects
None yet
5 participants
@djalma2k

djalma2k commented Feb 18, 2016

Using Koreader 2015.11 stable and nightly-20160216
Device: Kobo Glo HD
Comparison between Sony PRS-T3 (left) and Kobo Glo HD using koreader (right):

Showing an image (epub) in normal mode
http://postimg.org/image/dzx7t739f
Showing an image (epub) in sleep mode:
http://postimg.org/image/ikje84myr

Using "nickel" in Kobo Glo HD:
Normal mode:
http://postimg.org/image/roht8kojn
Sleep mode:
http://postimg.org/image/8xfvyetz7

Seems some type of posterization (lack of dithering)... I don't know if it's a bug or maybe a setting to save cpu cycles when the image is rendered (nickel)....
Anyway, in case it's not a bug, how I could increase the image quality to a setting similar to Sony T3?
Regards and Thanks in advance!!!

@NiLuJe

This comment has been minimized.

Show comment
Hide comment
@NiLuJe

NiLuJe Feb 18, 2016

Member

Yup, no dithering, and the hardware 'dithering' is crappy.

Member

NiLuJe commented Feb 18, 2016

Yup, no dithering, and the hardware 'dithering' is crappy.

@djalma2k

This comment has been minimized.

Show comment
Hide comment
@djalma2k

djalma2k Feb 18, 2016

Well, I don't know if you are meaning that "hardware dithering" is crapp in a general sense or that it's the Kobo's hardware implementation? Surely you are right, I don't doubt that; but which is the crappy side of the "dithering": Bad side effects like ghosting or something like that? Because to me the"nickel" dithering seems good enough to my eyes or at least an improvement over the "naked"-raw image-limited_by_the_hardware; and sony's implementation seems almost perfect to me...
Anyway, as I asked before is there any setting in koreader/cr to enable it (hardware dithering or software if It could be possible)? My guess is not for your answer, but I appreciate you explain it to me.
Thanks in advance and Regards.

djalma2k commented Feb 18, 2016

Well, I don't know if you are meaning that "hardware dithering" is crapp in a general sense or that it's the Kobo's hardware implementation? Surely you are right, I don't doubt that; but which is the crappy side of the "dithering": Bad side effects like ghosting or something like that? Because to me the"nickel" dithering seems good enough to my eyes or at least an improvement over the "naked"-raw image-limited_by_the_hardware; and sony's implementation seems almost perfect to me...
Anyway, as I asked before is there any setting in koreader/cr to enable it (hardware dithering or software if It could be possible)? My guess is not for your answer, but I appreciate you explain it to me.
Thanks in advance and Regards.

@houqp

This comment has been minimized.

Show comment
Hide comment
@houqp

houqp Feb 18, 2016

Member

@chrox and @frankyifei knows more about CRengine. I am not aware of hardware dithering support. Can you upload the book or extract that image for us to test?

Member

houqp commented Feb 18, 2016

@chrox and @frankyifei knows more about CRengine. I am not aware of hardware dithering support. Can you upload the book or extract that image for us to test?

@djalma2k

This comment has been minimized.

Show comment
Hide comment
@djalma2k

djalma2k Feb 18, 2016

EDIT: Just removing the link to the book and using the original image instead.
cover

djalma2k commented Feb 18, 2016

EDIT: Just removing the link to the book and using the original image instead.
cover

@NiLuJe

This comment has been minimized.

Show comment
Hide comment
@NiLuJe

NiLuJe Feb 18, 2016

Member

By HW I meant what the eInk driver/controller does behind the scenes.

That's what gives you a lot of crappy banding, instead of the nice smooth gradients you'd have with proper dithering to the right palette ;).

Granted, CRe might be doing something weird on top of that, but, for the record, I'm not a fan of nickel's default behavior either ;) (there's a hidden flag that jumps around between versions that might try to do things right, or at least better, but I gave up bothering with it and I just do it on Calibre's side).

And, yeah, no surprise there, Sony did things right on that front.

Member

NiLuJe commented Feb 18, 2016

By HW I meant what the eInk driver/controller does behind the scenes.

That's what gives you a lot of crappy banding, instead of the nice smooth gradients you'd have with proper dithering to the right palette ;).

Granted, CRe might be doing something weird on top of that, but, for the record, I'm not a fan of nickel's default behavior either ;) (there's a hidden flag that jumps around between versions that might try to do things right, or at least better, but I gave up bothering with it and I just do it on Calibre's side).

And, yeah, no surprise there, Sony did things right on that front.

@frankyifei

This comment has been minimized.

Show comment
Hide comment
@frankyifei

frankyifei Feb 19, 2016

Contributor

The original image is 24bit image.
opened the epub in emulator, looks not bad.
opened on my kindle, it looks like no dithering. then I did a screenshot and opened it on computer, the screenshot is a normal 8bit grayscale image and looks not bad. The "no dithering" look is like a 32 color image. I converted the original image to a 32 color grayscale one. they look very similar.
-The following is the converted 32 color image.
cover2
-and the screenshot
reader_2016-feb-19_234326

The CRE works well here since the screenshot is a nice 8bit 256 color image. But why does it look like a 4bit 32 color image when displaced in real device?

Contributor

frankyifei commented Feb 19, 2016

The original image is 24bit image.
opened the epub in emulator, looks not bad.
opened on my kindle, it looks like no dithering. then I did a screenshot and opened it on computer, the screenshot is a normal 8bit grayscale image and looks not bad. The "no dithering" look is like a 32 color image. I converted the original image to a 32 color grayscale one. they look very similar.
-The following is the converted 32 color image.
cover2
-and the screenshot
reader_2016-feb-19_234326

The CRE works well here since the screenshot is a nice 8bit 256 color image. But why does it look like a 4bit 32 color image when displaced in real device?

@NiLuJe

This comment has been minimized.

Show comment
Hide comment
@NiLuJe

NiLuJe Feb 19, 2016

Member

Because real eInk devices have a much more limited palette (16 shades of grey), and unless you do something about it, it looks terrible ;).

And gradients and play with shadows are a very nice example to test this, as you've seen :).

Member

NiLuJe commented Feb 19, 2016

Because real eInk devices have a much more limited palette (16 shades of grey), and unless you do something about it, it looks terrible ;).

And gradients and play with shadows are a very nice example to test this, as you've seen :).

@pkb

This comment has been minimized.

Show comment
Hide comment
@pkb

pkb Feb 20, 2016

Below is screenshot of CoolReader with 4 bit gray buffer:
amante

pkb commented Feb 20, 2016

Below is screenshot of CoolReader with 4 bit gray buffer:
amante

@houqp

This comment has been minimized.

Show comment
Hide comment
@houqp

houqp Feb 20, 2016

Member

Yeah, looks like we are using crengine wrong. drawCurrentPage always set it to 8bpp. We need to set the BPP according to the underlining device screen. Time to do an audit and make sure it's done for djvulibre and mupdf too :-/

Member

houqp commented Feb 20, 2016

Yeah, looks like we are using crengine wrong. drawCurrentPage always set it to 8bpp. We need to set the BPP according to the underlining device screen. Time to do an audit and make sure it's done for djvulibre and mupdf too :-/

@djalma2k

This comment has been minimized.

Show comment
Hide comment
@djalma2k

djalma2k Feb 20, 2016

@houqp I know that probably it isn't a relief but with coolreader by vlasovsoft is happening the same, at least to me :/
Anyway, I did 2 battery test using gimp and using an imagemagick's command: "mogrify" to apply "software dithering" to an images and see the results shown in a real eink device.
Test1 (8bits images transformed using gimp):
http://postimg.org/gallery/3331zw9ss/

$ identify *
color_index_optimum_palete_16.jpg JPEG 600x900 600x900+0+0 8-bit sRGB 126KB 0.000u 0:00.000
color_index_optimum_palete_16_with_dither_2.jpg[1] JPEG 600x900 600x900+0+0 8-bit sRGB 122KB 0.000u 0:00.000
color_index_optimum_palete_16_with_dither_3.jpg[2] JPEG 600x900 600x900+0+0 8-bit sRGB 129KB 0.000u 0:00.000
color_index_optimum_palete_16_with_dither_3_transparency_on.jpg[3] JPEG 600x900 600x900+0+0 8-bit sRGB 129KB 0.000u 0:00.000
color_index_optimum_palete_16_with_normal_dither.jpg[4] JPEG 600x900 600x900+0+0 8-bit sRGB 124KB 0.000u 0:00.000
cover.jpg[5] JPEG 600x900 600x900+0+0 8-bit sRGB 138KB 0.000u 0:00.000
grey_scale_16.jpg[6] JPEG 600x900 600x900+0+0 8-bit Gray 256c 134KB 0.000u 0:00.000
grey_scale_full.jpg[7] JPEG 600x900 600x900+0+0 8-bit Gray 256c 121KB 0.000u 0:00.000
grey_scale_index_1_bit_with_dither_3_transparency_on.jpg[8] JPEG 600x900 600x900+0+0 8-bit sRGB 128KB 0.000u 0:00.000
grey_scale_index_1_bit_with_dither_normal.jpg[9] JPEG 600x900 600x900+0+0 8-bit sRGB 125KB 0.000u 0:00.000
grey_scale_index_palete_16.jpg[10] JPEG 600x900 600x900+0+0 8-bit sRGB 124KB 0.000u 0:00.000
grey_scale_index_palete_16_with_dither_2.jpg[11] JPEG 600x900 600x900+0+0 8-bit sRGB 126KB 0.000u 0:00.000
grey_scale_index_palete_16_with_dither_3.jpg[12] JPEG 600x900 600x900+0+0 8-bit sRGB 125KB 0.000u 0:00.000
grey_scale_index_palete_16_with_dither_3_transparency_on.jpg[13] JPEG 600x900 600x900+0+0 8-bit sRGB 125KB 0.000u 0:00.000
grey_scale_index_palete_16_with_dither_normal.jpg[14] JPEG 600x900 600x900+0+0 8-bit sRGB 126KB 0.000u 0:00.000
rgb_16.jpg[15] JPEG 600x900 600x900+0+0 8-bit sRGB 134KB 0.000u 0:00.000

Only looks good images with dither applied. (except images with 1bit(black-white)).
Test2 (Applying over this images the following command: "mogrify -colors 16 *") (Seems like mogrify apply auto dithering with some parameters and probably colors is one of them)
With Test2 the original cover image and the "grayscale full" image look good in the eink. device.
Test3: "mogrify -depth 4 *" (~16 levels) with bad results...
Regards.
PS: grey_scale_16 means that the original image is posterized to a 16 levels of gray.
PS2: [O/T] Could be interesting add as a feature a "picture viewer"...I almost died checking all the images. :/ hahaha :P (Its a joke, "first thing first" :P )
PS3: I did this thinking in the possibility of a properly formatted image was converted by the system driver module (fbdev?¿?) in a "dithered image". I'm thinking this because I don't know why kobo(nickel) is applying dither only to images in the "proper or real reader". In sleep mode and in thumbnails in the home screen isn't applied. Why could be this behaviour? To save cpu cycles (battery)? Or is using nickel a different video module in the same way like in a desktop linux system: a module for virtual console, another one for X? Or probably they dont bother with other "formats" excepts their own "ecosytem"...

djalma2k commented Feb 20, 2016

@houqp I know that probably it isn't a relief but with coolreader by vlasovsoft is happening the same, at least to me :/
Anyway, I did 2 battery test using gimp and using an imagemagick's command: "mogrify" to apply "software dithering" to an images and see the results shown in a real eink device.
Test1 (8bits images transformed using gimp):
http://postimg.org/gallery/3331zw9ss/

$ identify *
color_index_optimum_palete_16.jpg JPEG 600x900 600x900+0+0 8-bit sRGB 126KB 0.000u 0:00.000
color_index_optimum_palete_16_with_dither_2.jpg[1] JPEG 600x900 600x900+0+0 8-bit sRGB 122KB 0.000u 0:00.000
color_index_optimum_palete_16_with_dither_3.jpg[2] JPEG 600x900 600x900+0+0 8-bit sRGB 129KB 0.000u 0:00.000
color_index_optimum_palete_16_with_dither_3_transparency_on.jpg[3] JPEG 600x900 600x900+0+0 8-bit sRGB 129KB 0.000u 0:00.000
color_index_optimum_palete_16_with_normal_dither.jpg[4] JPEG 600x900 600x900+0+0 8-bit sRGB 124KB 0.000u 0:00.000
cover.jpg[5] JPEG 600x900 600x900+0+0 8-bit sRGB 138KB 0.000u 0:00.000
grey_scale_16.jpg[6] JPEG 600x900 600x900+0+0 8-bit Gray 256c 134KB 0.000u 0:00.000
grey_scale_full.jpg[7] JPEG 600x900 600x900+0+0 8-bit Gray 256c 121KB 0.000u 0:00.000
grey_scale_index_1_bit_with_dither_3_transparency_on.jpg[8] JPEG 600x900 600x900+0+0 8-bit sRGB 128KB 0.000u 0:00.000
grey_scale_index_1_bit_with_dither_normal.jpg[9] JPEG 600x900 600x900+0+0 8-bit sRGB 125KB 0.000u 0:00.000
grey_scale_index_palete_16.jpg[10] JPEG 600x900 600x900+0+0 8-bit sRGB 124KB 0.000u 0:00.000
grey_scale_index_palete_16_with_dither_2.jpg[11] JPEG 600x900 600x900+0+0 8-bit sRGB 126KB 0.000u 0:00.000
grey_scale_index_palete_16_with_dither_3.jpg[12] JPEG 600x900 600x900+0+0 8-bit sRGB 125KB 0.000u 0:00.000
grey_scale_index_palete_16_with_dither_3_transparency_on.jpg[13] JPEG 600x900 600x900+0+0 8-bit sRGB 125KB 0.000u 0:00.000
grey_scale_index_palete_16_with_dither_normal.jpg[14] JPEG 600x900 600x900+0+0 8-bit sRGB 126KB 0.000u 0:00.000
rgb_16.jpg[15] JPEG 600x900 600x900+0+0 8-bit sRGB 134KB 0.000u 0:00.000

Only looks good images with dither applied. (except images with 1bit(black-white)).
Test2 (Applying over this images the following command: "mogrify -colors 16 *") (Seems like mogrify apply auto dithering with some parameters and probably colors is one of them)
With Test2 the original cover image and the "grayscale full" image look good in the eink. device.
Test3: "mogrify -depth 4 *" (~16 levels) with bad results...
Regards.
PS: grey_scale_16 means that the original image is posterized to a 16 levels of gray.
PS2: [O/T] Could be interesting add as a feature a "picture viewer"...I almost died checking all the images. :/ hahaha :P (Its a joke, "first thing first" :P )
PS3: I did this thinking in the possibility of a properly formatted image was converted by the system driver module (fbdev?¿?) in a "dithered image". I'm thinking this because I don't know why kobo(nickel) is applying dither only to images in the "proper or real reader". In sleep mode and in thumbnails in the home screen isn't applied. Why could be this behaviour? To save cpu cycles (battery)? Or is using nickel a different video module in the same way like in a desktop linux system: a module for virtual console, another one for X? Or probably they dont bother with other "formats" excepts their own "ecosytem"...

@houqp

This comment has been minimized.

Show comment
Hide comment
@houqp

houqp Feb 20, 2016

Member

I just tried forcing CREngine to do 4bpp rendering on my kobo and the result looks way better than 8bpp :) @djalma2k were you running coolreader in 4bpp mode?

Member

houqp commented Feb 20, 2016

I just tried forcing CREngine to do 4bpp rendering on my kobo and the result looks way better than 8bpp :) @djalma2k were you running coolreader in 4bpp mode?

@djalma2k

This comment has been minimized.

Show comment
Hide comment
@djalma2k

djalma2k Feb 20, 2016

@houqp No, no, no, sorry about confusion, I was talking about the standar mode (8 bits I suppose). I dont know how to set it to 4 bits :/ If it's easy let me know how to set it (not crosscompile or something like this :)

djalma2k commented Feb 20, 2016

@houqp No, no, no, sorry about confusion, I was talking about the standar mode (8 bits I suppose). I dont know how to set it to 4 bits :/ If it's easy let me know how to set it (not crosscompile or something like this :)

@houqp

This comment has been minimized.

Show comment
Hide comment
@houqp

houqp Feb 20, 2016

Member

Nice, let's implement the dynamic BPP settings first then ;)

Member

houqp commented Feb 20, 2016

Nice, let's implement the dynamic BPP settings first then ;)

@NiLuJe

This comment has been minimized.

Show comment
Hide comment
@NiLuJe

NiLuJe Feb 20, 2016

Member

Yep, I can clearly see a standard ordered dithering pattern in that 4bpp screenshot, which is good, means CRe has a away to do it. (And while ordered dither isn't perfect, it's probably the cheapest method when you don't know the exact target palette... Which, technically, we do here, which is why doing it the right way via ImageMagick [which is what I do for the ScreenSavers hack on Kindles, and on Calibre's side for my Kobo] looks even better). But since dithering is a fairly expensive process, ordered is still probably a good compromise.

@djalma2k: Like I mentioned, nickel has a hidden readersetting (the exact name of which changes depending on the FW version) which happens to do dithering properly in more places.
It's been mentioned a couple of times on MR in the FW threads.

FWIW, here's what I do when I process stuff w/ IM:

for file in *.png ; do ; convert ${file} -filter LanczosSharp -resize 758x1024 -background black -gravity center -extent 758x1024 -colorspace Gray -dither FloydSteinberg -remap ~SVN/Configs/trunk/Kindle/Touch_Hacks/ScreenSavers/src/linkss/etc/kindle_colors.gif -quality 75 -define png:color-type=0 -define png:bit-depth=8 dithered_${file} ; done

And here's the palette.

NOTE: There's a resize + letterboxing step in there, so if you only want to do dithering, you can zap a bunch of things from there, and basically only keep colorspace, dither & remap (plus the png options to make the Kindle framework happy, eventually) ;).

Member

NiLuJe commented Feb 20, 2016

Yep, I can clearly see a standard ordered dithering pattern in that 4bpp screenshot, which is good, means CRe has a away to do it. (And while ordered dither isn't perfect, it's probably the cheapest method when you don't know the exact target palette... Which, technically, we do here, which is why doing it the right way via ImageMagick [which is what I do for the ScreenSavers hack on Kindles, and on Calibre's side for my Kobo] looks even better). But since dithering is a fairly expensive process, ordered is still probably a good compromise.

@djalma2k: Like I mentioned, nickel has a hidden readersetting (the exact name of which changes depending on the FW version) which happens to do dithering properly in more places.
It's been mentioned a couple of times on MR in the FW threads.

FWIW, here's what I do when I process stuff w/ IM:

for file in *.png ; do ; convert ${file} -filter LanczosSharp -resize 758x1024 -background black -gravity center -extent 758x1024 -colorspace Gray -dither FloydSteinberg -remap ~SVN/Configs/trunk/Kindle/Touch_Hacks/ScreenSavers/src/linkss/etc/kindle_colors.gif -quality 75 -define png:color-type=0 -define png:bit-depth=8 dithered_${file} ; done

And here's the palette.

NOTE: There's a resize + letterboxing step in there, so if you only want to do dithering, you can zap a bunch of things from there, and basically only keep colorspace, dither & remap (plus the png options to make the Kindle framework happy, eventually) ;).

@houqp houqp added this to the next stable release milestone Mar 8, 2016

@houqp houqp added the enhancement label Mar 14, 2016

@djalma2k

This comment has been minimized.

Show comment
Hide comment
@djalma2k

djalma2k Mar 18, 2016

@NiLuJe Thanks 4 your explanation and your IM batch (and bash :P ) processing script. 👍 You probably save me a lot of time of checking this in the future... :)))
Regards.

djalma2k commented Mar 18, 2016

@NiLuJe Thanks 4 your explanation and your IM batch (and bash :P ) processing script. 👍 You probably save me a lot of time of checking this in the future... :)))
Regards.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment