MangaViewer - an opensource, standalone, python manga reader

[kiiller_man1]

I recently got a project I was working on to the point where I thought others could be able to use it. That project is MangaViewer.

I designed MangaViewer to be convenient and easy to control; you can select and navigate several manga using only the arrow keys.

There is a Windows executable in the Downloads section, and the python source is also available (I am looking into a way to make a Mac app). Also, please read the Readme section for controls, etc.

I hope you enjoy using it. I welcome any feedback and suggestion .

[pingryanime]

I think it's horrible. You should just go jump off a cliff or something. I hate it so much I can't even express it in words

Ohhey, I think it's really cool!


(it's k, guys. I know this dude irl)

[kitamesume]

make it an all around app instead of just a mangaviewer.

add in the ability to view images such as jpeg png gif etc. and can be set as the default viewer. the ability to navigate through folders drives etc. should be taken as a priority as well.

[Kyrdua]

make it an all around app instead of just a mangaviewer.

make it be able to play music, buy manga online, and surf the web while you're at it. 


though seriously. he's right, IMO the most important Features of a manga reader are:

• Reading within archives
  
  
• Navigating within archives
  
  
• Display options
  
  
• Resampling Algorithms
  
  
• Image Scale Options
  
  
• JPG/PNG/GIF support
  
  
• CBR/CBZ/ZIP/7Z/RAR Support
  
  
• Drag n Drop support
  
  
• Wide selection of file sorting options
  
  
• File Saving/Move/Extraction
  
  
• Small Filesize/Portable
  
  
• Not So Important Features
  
  
• Chapter Detection
  
  
• Thumbnail View
  
  
• Tree View
  
  
• Tabbed Reading
  
  

Yeah, demanding, I know. But hey, one can dream of all those feature being in one program.

[kiiller_man1]

make it an all around app instead of just a mangaviewer.

make it be able to play music, buy manga online, and surf the web while you're at it. 


though seriously. he's right, IMO the most important Features of a manga reader are:

• Reading within archives
  
  
• Navigating within archives
• CBR/CBZ/ZIP/7Z/RAR Support

Yep, I was hoping to add this feature soon.

• Display options
• Resampling Algorithms
  
  
• Image Scale Options
  
  

If you check the Readme, there are already these settings (but you have to edit the settings file). If you want a gui to change the settings, that's coming xD, but as for more resizing or scaling methods: I'm open to any suggestions.

• JPG/PNG/GIF support
  
  

Check .

• Drag n Drop support
  
  
• Wide selection of file sorting options
  
  

Sounds good . Just wondering what other ways to sort the files you would like though, perhaps by date?

• File Saving/Move/Extraction
  
  

Not exactly sure what would need saving, perhaps a list of what has been read already, or do you mean something else here?

• Small Filesize/Portable
  
  

Yep, that's one of my goals .

• Not So Important Features
  
  
• Chapter Detection
  
  
• Thumbnail View
  
  
• Tree View
  
  
• Tabbed Reading
  
  

Chapter Detection: This is a feature I do want to have, and plan of having. The only problem I have is that some scanlators enclude a whole volume in on folder, and so if you have folders where some are chapters, and some are volumes, there are probably going to be errors sometimes due to different naming schemes, etc in trying to figure out, volume (if any), manga name, and chapter.

Thumbnail view and tabbed reading makes sense, though I'm not sure what kind of thumnail view: "Zooming out", where you view a thumbnail of each image after already selecting the folder and can select which you want to start with?

Tree View: Do you mean, like tree view folder selection?

Yeah, demanding, I know. But hey, one can dream of all those feature being in one program.

Not at all , and I will try to create that program.

[Sosseres]

Question, if I have the viewer on c: how do I view something on e:?

[Kyrdua]

• Reading within archives
  
  
• Navigating within archives
• CBR/CBZ/ZIP/7Z/RAR Support

Yep, I was hoping to add this feature soon.

nice.

• Display options
• Resampling Algorithms
  
  
• Image Scale Options
  
  

If you check the Readme, there are already these settings (but you have to edit the settings file). If you want a gui to change the settings, that's coming xD, but as for more resizing or scaling methods: I'm open to any suggestions.

err. i haven't checked it yet.

as for scaling suggestions. the one's That will get most usage would probably be.

• Original image dimensions
• Scale to Window Width
• Scale to Window Height
• Manual Scale

And I forgot, background customization is good too. checkered background is nice  but color change would probably suffice.
as for the gui. seeing as it's python it's probably easy enough to configure. a well written html help file explaining what each algorithm does would be enough.

• Drag n Drop support
  
  
• Wide selection of file sorting options
  
  

Sounds good . Just wondering what other ways to sort the files you would like though, perhaps by date?

yeah.

• File Saving/Move/Extraction
  
  

Not exactly sure what would need saving, perhaps a list of what has been read already, or do you mean something else here?

I mean something else. It's to extract/move/save the page you are reading to a separate folder.

Chapter Detection: This is a feature I do want to have, and plan of having. The only problem I have is that some scanlators enclude a whole volume in on folder, and so if you have folders where some are chapters, and some are volumes, there are probably going to be errors sometimes due to different naming schemes, etc in trying to figure out, volume (if any), manga name, and chapter.

Yeah, I kinda had that in mind when i said that. now that i think of it. it's implausible... 三 (lll´ⅴ｀)
Actually scratch that. even if you could spend some time perfecting it, it would be useless as most
groups just opt in putting all the pages in and not bother numbering them by chapters.

Thumbnail view and tabbed reading makes sense, though I'm not sure what kind of thumnail view: "Zooming out", where you view a thumbnail of each image after already selecting the folder and can select which you want to start with?

yeah, that. also the regular folder thumbnails like in windows explorer.

Tree View: Do you mean, like tree view folder selection?

if you mean like the one in explorer. yes.

Yeah, demanding, I know. But hey, one can dream of all those feature being in one program.

Not at all , and I will try to create that program.

cool. 

I'll download the proggie now and try it out and see if i can give more suggestions.

[kiiller_man1]

Question, if I have the viewer on c: how do I view something on e:?

Currently the only way is to edit the settings.json file, and change the path to the new drive (Make sure you change every \ to a \\, read the readme for a further explanation of the settings file: https://github.com/msm595/MangaViewer, at the bottom)

[Kyrdua]

Hmm. lack of mouse navigation aside. It's controls are pretty simple.

and oh. thought of a few more suggestions

• lancoz filter for resampling
• smooth scrolling
• boss key (lol)

[AnimeJanai]

Before you go further on a standalone project, consider making your viewer as a PLUGIN for existing popular software.   For example, you could make it as a plugin for Irfanview.  That way, your manga viewing interface as well as manga viewing functions can re-use Irfanview's existing software routines for saving images in different formats, creating slideshows, batch renaming, batch conversion, manipulating images and palettes, etcetera.  Another advantage is that other software tools have existing name recognition and thus you have a much better chance to get your tool into use by many people.

Your other alternative is to look at the various software tools already existing for databases either online or in the PC and have your tool interface to them.  That way, you will have added image matching, sorting, and searching for other titles that have similar images.    If your doujin/manga viewer is compatible with the Mugimugi doujinshi database, that would be exceptionally useful to many doujin collectors.

[Freedom Kira]

In addition to plugin operability, I greatly value efficiency. You would have my props if you manage to code this (efficiently) in C instead of scripting it in Python, which is very computation-intensive. I know that it's easy to script stuff in Python (haven't actually tried it before though), but it comes at a pretty big price computation-wise.

Now THAT should give you something to work on. Yay segmentation faults!

[Ultra_Magnus]

A comic viewer doesn't need efficiency.... this isn't 1995.

Its nice to have simple, dedicated apps, that just do what they are supposed to and aren't feature creep nightmares.  I will be interested to compare it to simple comic when you release a mac .app.

[Kyrdua]

A comic viewer doesn't need efficiency.... this isn't 1995.

are you kidding? even if that's true don't you think it's a waste of cpu/ram to run a very intensive comic reader?

[Ultra_Magnus]

A comic viewer doesn't need efficiency.... this isn't 1995.

are you kidding? even if that's true don't you think it's a waste of cpu/ram to run a very intensive comic reader?

Most people have buckets of CPU cycles and RAM to waste these days.

If this was for a microcontroller or other embedded system I would agree with you, but on PCs portability and speed of development are more important.

[Sosseres]

That is why java is great. Runs on most platforms without all that much fuss.

[kiiller_man1]

In addition to plugin operability, I greatly value efficiency. You would have my props if you manage to code this (efficiently) in C instead of scripting it in Python, which is very computation-intensive. I know that it's easy to script stuff in Python (haven't actually tried it before though), but it comes at a pretty big price computation-wise.

Now THAT should give you something to work on. Yay segmentation faults!

I'd say coding stuff in any language is easy (excluding brainf*ck-esque languages), but coding things well takes more skill. I appreciate that you look for efficiency, I highly value it too. I am much less confident in my skills as a C programmer though, as I started learning it much later than most of the other language I know. Therefore I am much more worried that I will do something inefficiently in C that could cause memory leaks. I am much more secure in all of the other languages I know.

In terms of efficiency though, I beg to differ. My code utilizes Tkinter, which are Tk bindings for Python. Tk is a lightweight and fast gui toolkit, so no problems there. To manipulate images, my code uses PIL, or the Python Imaging Library, which is actually a C library for python and should be fast as well. I don't see much that could be slow, and I don't think I've ever seen the memory usage go about 20mb.

That is why java is great. Runs on most platforms without all that much fuss.

I have done a lot in java, but I had wanted to do something in python (plus I don't really like doing gui's in java).

Hmm. lack of mouse navigation aside. It's controls are pretty simple.

and oh. thought of a few more suggestions

• lancoz filter for resampling
• smooth scrolling
• boss key (lol)

I really like the background customization idea, that is something I will likely implement. After doing some research, I have found that the "antialias" setting for resizing actually uses lancoz filtering . Smooth scrolling is something I was playing with before I refactored my code, I just need to get it right. And who's to say there isn't already a boss key? XD.

[kureshii]

You would have my props if you manage to code this (efficiently) in C instead of scripting it in Python, which is very computation-intensive.

Eh, why wuss out with the pursuit of efficiency; just write it in asm and save CPU cycles like you've never done before! :V

[Ultra_Magnus]

Obligatory xkcd:

[kureshii]

Also relevant.

[Freedom Kira]

<3 xkcd. I remember that Emacs one (I hate Emacs with the passion), good memories.

I'd say coding stuff in any language is easy (excluding brainf*ck-esque languages), but coding things well takes more skill. I appreciate that you look for efficiency, I highly value it too. I am much less confident in my skills as a C programmer though, as I started learning it much later than most of the other language I know. Therefore I am much more worried that I will do something inefficiently in C that could cause memory leaks. I am much more secure in all of the other languages I know.

In terms of efficiency though, I beg to differ. My code utilizes Tkinter, which are Tk bindings for Python. Tk is a lightweight and fast gui toolkit, so no problems there. To manipulate images, my code uses PIL, or the Python Imaging Library, which is actually a C library for python and should be fast as well. I don't see much that could be slow, and I don't think I've ever seen the memory usage go about 20mb.

Heh, I admit I haven't actually tried Python scripting before. I'm learning Ruby right now for a course. Learned very basic bash scripting a couple years ago but I can't say I really took anything away from the experience. Ruby is quite a beautiful language, and I imagine Python is very similar, as they are both advanced scripting languages.

C would be the third language I learned, after Java (although C++ was the first, and the kind of C++ I was doing was very much like C because it lacked class definitions etc. that really differentiates C++ from C). The nice thing about ANSI C is that you can often get away with workarounds that will avoid the possibility of a memory leak. After a couple years of sporadic practice with C, I can code about as fast as a beginner Ruby scripter (task-wise, I mean, not line-wise).

I guess 20MB is not that much if you look at mainstream computers now, but a computer that's, say, 7-ish years old would find that to be about 5-10% of the RAM. That's a lot for an image viewer. But if you think about it, the only reason why uTorrent 1.8.5 is still fairly popular is because it's so much more lightweight than the newer versions of uTorrent. There's really nothing else saving it.