mirrors/stb-imv
1
0
Fork 0
mirror of https://github.com/nothings/stb-imv synced 2024-11-21 13:01:31 +03:00
Code Issues Packages Projects Releases Wiki Activity

Merge pull request #23 from aras-p/patch-1

Browse Source 
Update readme for github-style markup
This commit is contained in:
Sean Barrett 2017-01-16 06:15:20 -05:00 committed by GitHub
commit 7bf439121a
1 changed files with 21 additions and 23 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

44
README.md
View File

@ -1,52 +1,50 @@
Project status: 1.02 release
=Information for Users=
# imv(stb)
*imv_(stb)_* is an extremely lightweight and fast image viewer/browser for the Windows platform. The current executable is about 70KB (without executable compression).
**imv(stb)** is an extremely lightweight and fast image viewer/browser for the Windows platform. The current executable is about 70KB (without executable compression).
==Features==
## Features
Inspired by [http://www.stereopsis.com/vjpeg/ vjpeg], *imv_(stb)_* offers a very simple, no-frills image viewer with a minimal interface. Each opened image is easy to drag and resize. A minimal border around the image makes it easy to see the contents of the edge of the image, and (compared to vjpeg) prevents you from confusing a screenshot of a windows application with the actual application.
Inspired by [vjpeg](http://www.stereopsis.com/vjpeg), *imv(stb)* offers a very simple, no-frills image viewer with a minimal interface. Each opened image is easy to drag and resize. A minimal border around the image makes it easy to see the contents of the edge of the image, and (compared to vjpeg) prevents you from confusing a screenshot of a windows application with the actual application.
Inspired by Windows Picture and Fax Viewer, *imv_(stb)_* lets you navigate through multiple images in the same directory in a single window. Unlike Windows Picture and Fax Viewer, you can have multiple *imv(stb)* browsers open simultaneously.
Inspired by Windows Picture and Fax Viewer, *imv(stb)* lets you navigate through multiple images in the same directory in a single window. Unlike Windows Picture and Fax Viewer, you can have multiple *imv(stb)* browsers open simultaneously.
Details of the latest changes can be found in the ReleaseNotes.
==Limitations==
## Limitations
It is not possible to zoom in on part of an image; in other words, you can't zoom to the point where you'd need scrollbars. (Well, you can if you get sneaky, but you don't get scrollbars.)
== Issues, Bugs, Feature Requests ==
## Issues, Bugs, Feature Requests
To submit a bug report, go here: [http://code.google.com/p/stb-imv/adminIssues Issues]
To submit a bug report, suggesions or a feature request, file an issue on github.
To submit a suggestion or a feature request, go here: FeatureRequests
## Information for Developers
=Information for Developers=
### Image Loading
==Image Loading==
*imv(stb)* is built around [stb_image.h](https://github.com/nothings/stb/blob/master/stb_image.h), a public domain, portable JPEG/PNG/BMP/TGA reader. stb_image has some limits; it doesn't handle progressive jpegs or interlaced PNGs, or 1bpp BMPs. To improve this, we dynamically load gdiplus if available (it supports many interesting file formats, and is available on most win32 machines), and dynamically load FreeImage if it's available (it supports many, many more file formats and isn't on most people's machines at all). We use stb_image first, although it's not necessary the fastest, to provide more testing bandwidth for stb_image.c, and because it's well-behaved and sometimes fast.
*imv(stb)* is built around http://nothings.org/stb_image.c, a public domain, portable JPEG/PNG/BMP/TGA reader. stb_image.c has some limits; it doesn't handle progressive jpegs or interlaced PNGs, or 1bpp BMPs. To improve this, we dynamically load gdiplus if available (it supports many interesting file formats, and is available on most win32 machines), and dynamically load FreeImage if it's available (it supports many, many more file formats and isn't on most people's machines at all). We use stb_image first, although it's not necessary the fastest, to provide more testing bandwidth for stb_image.c, and because it's well-behaved and sometimes fast.
It is also possible to improve stb_image.c or add new loaders for other types. Because Google Code does not support projects with a public domain (PD) "license", there is no Google Code project for stb_image.c. We do not generally want to fork stb_image.c, though, so changes to stb_image.c in this project should all be public domain; no changes that alter the copyright status of stb_image.c will be accepted. If you want to write new loaders that are GPL'd rather than PD'd, simply place them in separate files, and either make imv.c call them if stbi_load fails, or use stb_image's 'register a new loader' feature.
It is also possible to improve stb_image or add new loaders for other types. We do not generally want to fork stb_image, though, so changes to stb_image in this project should all be public domain; no changes that alter the copyright status of stb_image will be accepted. If you want to write new loaders that are GPL'd rather than PD'd, simply place them in separate files, and either make imv.c call them if stbi_load fails, or use stb_image's 'register a new loader' feature.
The current version of *imv(stb)* falls back to GDI+ and then to FreeImage if they can be dynamically loaded.
==Portability==
### Portability
*imv(stb)* itself is non-portable, offering a simple, flexible, highly-tuned user interface hard-coded to the windows platform. If you back to its earliest state it might be a reasonable starting place for a port.
The project is currently available with VC6 and VC7 project files for maximum compatibility. The automatic upgrade to VS2005 should just work.
==Performance==
### Performance
*imv(stb)* makes heavy use of threads. If you use it to browse images in a directory, it will read ahead (in either direction) by one image. Disk I/O is performed in one thread, jpeg/png decoding in a second thread, and a single image-resize operation is performed in parallel on one or more other threads (as many threads as you have processors). The main thread accepts input as fast as it can and manages the other threads (maintaining single-threaded ownership of most data but lending it as needed). For example, when you drag a corner to resize, image resize operations are "queued", but the window itself is not resized until the image resize operation completes.
The goals/ideals motivating the design are:
# Minimize the latency of the user experience
# Don't waste work
# Maximize the quality of the user experience
# If you've started doing something, finish it (corollary to 2)
1. Minimize the latency of the user experience
1. Don't waste work
1. Maximize the quality of the user experience
1. If you've started doing something, finish it (corollary to 2)
These principles lead to the following threading/performance design:
* Keep a cache of decoded images (1,2)
@ -73,17 +71,17 @@ This leads to the following behaviors:
The first of these, and a general 'see some full-sized, fully-decoded images if you scan too fast' were part of the initial design requirements that motivated the specifics of the implementation.
==Todo==
### Todo
* additional optimizations
* refactorings to reduce size
==Possible Todo==
### Possible Todo
* refresh current image, refresh directory list
* ReadDirectoryChangesW
If you want any of the features above, feel free to create an issue for it so we know there's interest.
==Done==
### Done
* build under VS2003
* UNICODE (currently we support non-8bit filenames that you iterate through in a directory, but only a very few open from the commandline, and none(?) from the open file dialog)
* Iterate through images recursively in subdirectories? (stb.h already includes a recursive readdir, so it would be trivial)