PDA

View Full Version : Radical Image Optimization Tool (RIOT) by Lucian Sabo



luciansabo
05.05.2008, 08:39 AM
Thank you 4eyes.

Hi Laurent,
Thank you for you great suggestions.
Some of them are already integrated before I was able to read this.

A new version is available at http://luci.criosweb.ro/riot . We are a step away from making Riot an IrfanView plugin. By testing riot.exe you can help creating a stable and useful IV plugin.

v0.1.2
-added jpeg chroma subsampling support (none,low 4:2:2,medium 4:2:0,high 4:1:1)
-added Dual view option in View menu (disabled shows only the optimized version)
-added edit fields for jpeg quality, gif and png number of colors, removed jpeg quality mask edit
-modified labels (image size is in the bottom displayed in bytes with separators, expressed in kilobytes also)
-improved error handling
-improved settings changed handling on Save
-code cleanup

The problem from capture 2 persists in the current version?
Good suggesion about the toolbar. I was thinking at the same thing. Future version will contain a toolbar.
You will have a Ctrl+F shortcut for fit in window
Good suggestion about the filename.

Laurent
05.05.2008, 06:54 PM
Lucian Sabo has submitted his Radical Image Optimization Tool (RIOT), with the possibility that in the future it becomes a plug-in for IrfanView. It is now available only as a standalone program and as a dll, so this section Off-topic > Software in the IrfanView forum is the best place to continue the discussion for interested persons.

Follow this link to go to the original thread (http://en.irfanview-forum.de/vb/showthread.php?t=1985). You'll find a description of the program and a link to the official website for RIOT.

When a plug-in for IrfanView becomes available, a new thread will be created in the Program > Plugins and add-ons section.

Laurent

Sam_Zen
06.05.2008, 02:51 AM
This looks like the right way for development. I will report my experiences.

I've updated riot.exe to v0.1.2. I assigned it in IV as external editor via Shift+E.
So I opened a bitmap with IV and used the command.
Although the right directory-environment was detected, the relevant bitmap wasn't immediately shown in the opened dialog.
I had to select it a second time in the 'open frame.

In this standalone app I noticed some elements which are of course valid for a standalone, like 'mirror', 'flip' etc.,
but are not necessary needed if this app is used as a plugin for IV.
Because then, those functions already are available, so the plugin could be trimmed to the specific optimization functions.

luciansabo
06.05.2008, 10:08 AM
the relevant bitmap wasn't immediately shown in the opened dialog.
RIOT (0.1.2) currently does not support command line parameters. So it will not function as an external editor. Future version will contain support for command line parameters.


Because then, those functions already are available, so the plugin could be trimmed to the specific optimization functions.
Unfortunatelly for those that don't want enhanced functionality, all functions that I will consider relevant for the optimization task will become part of RIOT (part of them of the Lite plugin).

Usually users want more functions, not strip ones that are present.

Even if IV has flip, rotate, these are common and useful tools and it will remain there. Look this as an extension, not as a component that has the functions IV has not.
In fact PNGOut saves PNGs independently and does a good job. You noticed that IV already saves PNGs... but pngout is not using any of IV components ?

Sam_Zen
07.05.2008, 01:42 AM
You've got some points there.
IVPaint also has an add-text fuction, while the basic IV has something like that already.

Laurent
07.05.2008, 02:08 AM
Hi Lucian,

As you see on the capture below, there is still an overlap problem with the file name. The error message appeared when I tried to open a PNG file crated with IrfanView. It opens normally in other programs. Not all PNGs raise an error, but I am unable to say which ones do.

Laurent

luciansabo
07.05.2008, 08:12 AM
It seems that you are using a large font DPI (120 DPI). This causes the fonts to enlarge. and that's why labels are overlapped. With 96 DPI settings the text fits.
You can change the DPI from Control Panel. Your setting is unusual and may cause other text-fit problems with other applications designed for 96 DPI.
By resizing/maximizing the window the labels will be set apart.

It seems you are trying to open a 48 bit image. I did not tested this format. Though RIOT can open 48 bit PNG images I must test the handling of such format.
Another PNG feature that is not handled yet is 16 bit grayscale. RIOT opens, but cannot save such files.

later edit: I confirm that RIOT has a problem with handling 48 bit images.
I will investigate this problem.

Laurent
07.05.2008, 10:55 AM
Hi Lucian,

For the 120 dpi font, you are right. I use it because at 96 dpi text is difficult to read on the screen (15,4" @ 1680 x 1050). I don't see the same problem with other programs, only with web pages (browser also configured to use a font bigger than the default one).

For the PNG, it was created with IrfanView from a BMP. IrfanView says it is a 24 bpp, not a 48 bpp. See attachment.

Laurent

luciansabo
07.05.2008, 12:11 PM
No, in fact this is a 48 bit image.
From Irfan View's properties:
Original colors: 16,7 Millions (48 BitsPerPixel)
Current colors: 16,7 Millions (24 BitsPerPixel)

IV actually works with 24 bit DIBs. The 48 bit image is transparently converted to 24 bits per pixel.


I don't see the same problem with other programs,
You may see this king of problems in programs where labels are near, and they are positioned absolute or relatively to window size.
To make it display properly with 120 DPI:
1. I can make font size smaller (difficult to read for the vast majority of users - that use 96 dpi screen font)
2. I can make the window bigger, but those with 800x600 will have problems
3. I can reposition the labels, move them a line bellow "Initial image" and "Optimized image"

Laurent
07.05.2008, 01:59 PM
Hi Lucian,

You are absolutely right: it is a 48 bpp image. I didn't look at first at the image properties, only at the display in the status bar in IrfanView. I don't know what I may have done to get this.

For the fontsize problem, I agree that points 1 and 2 aren't acceptable solutions.

Laurent

luciansabo
08.05.2008, 09:56 AM
A new version is avaible (0.1.3) that adds support for non-standard type images.

Changelog:
v.0.1.3
-fixed some memory leaks when opening new files
-added support for non standard type images (up to 128 BPP, integer and floating point. EX: hdr images, 16 bit grayscale, etc)
-added tone mapping option for BPP >= 48 bit. An Adaptive logarithmic mapping algorithm is used (Drago'2003)
-the opened filename is shown in the title bar now. For DIBs in memory a special message is shown
-added Ctrl + F shortcut for Fit in window
-decreased top label sizes for 120 DPI setting compatibility
-added HDR image type to the open dialog
-hottrack type page control (provides visual feedback when mouse is over tab)

High bit depths images can be HDR images, but it's not a rule.
For example your 48 bit PNG is not a HDR image.



high dynamic range imaging (HDRI) is a set of techniques that allows a greater dynamic range of exposures (the range of values between light and dark areas) than normal digital imaging techniques.
To produce a high dynamic range image a set of photographs taken with a range of exposures is used.

Information stored in high dynamic range images usually corresponds to the physical values of luminance or radiance that can be observed in the real world. This is different from traditional digital images, which represent colors that should appear on a monitor or a paper print.

This composite technique is different from (and may be of lesser or greater quality than) the production of an image from a single exposure of a sensor that has a native high dynamic range.

One problem with HDR has always been in viewing the images. Mundane CRTs, LCDs, prints, and other methods of displaying images only have a limited dynamic range. Thus various methods of converting HDR images into a viewable format have been developed, generally called "tone mapping".


For HDR images, RIOT can apply a tone mapping algorithm that will produce nice results. For example IV and most programs don't have such tone mapping capabilities.

I am attaching a PNG 48 bit hdr image.
Riot Lite will not contain tone mapping support.

luciansabo
08.05.2008, 10:04 AM
sample 96 bit HDR images
http://www.debevec.org/probes/

Sam_Zen
09.05.2008, 12:51 AM
Riot Lite ?
Well, this one is quite light indeed.
I opened "no_tonemapping.jpg" - nothing changed - nothing could be optimised.

EDIT: Although I must admit that "with_tonemapping.jpg" is an excellent result.

luciansabo
09.05.2008, 09:03 AM
RIOT Lite will be in fact the future IV plugin. It will contain reduced functionality of the full version.
Striipped functions are:
-opening many graphics formats
-tone mapping

You said nothing happend with no_tonemapping.jpg
What you expected to happen'?
no_tonemapping.jpg and with_tonemapping.jpg are samples to show you the differnce between applying tonemapping and not applying it.
By opening no_tonemapping.jpg you get a common jpeg file that you can optimize just like another jpeg file.

PS: I'm working at v. 0.1.4 with improved zoom function and some other fixes.

What do you think are the must have features for v.0.2 ?

Sam_Zen
10.05.2008, 12:36 AM
RIOT Lite will be in fact the future IV plugin.
I see.

By opening no_tonemapping.jpg you get a common jpeg file that you can optimize just like another jpeg file.
And that's the thing, just opening a common 24bpp JPG, then I get in both views the same, and I can't find any tool for optimization.
Apart from filesize. But maybe I expected that tone-mapping.
At the PNG tab : 'color quantization algorithm' is disabled. Is this the 'tone-mapping' part ?

A practical question : with version 0.1.2 the file "Riot.dll" came along. The 0.1.3 package doesn't contain that file.
Should I remove it, or what ?

The addition of the preview, with the dimension-values, in the open-dialog is very nice.
I'll have to do more practice with the app, before having any sensible request for v.0.2.

luciansabo
10.05.2008, 09:20 AM
Tone mapping can make HDR images look better. And that's it.
It does not apply to images with a bit depth lower than 32.

You should read more about tone mapping and HDR to understand what it is.

http://en.wikipedia.org/wiki/Tone_mapping
http://en.wikipedia.org/wiki/High_dynamic_range_imaging


At the PNG tab : 'color quantization algorithm' is disabled. Is this the 'tone-mapping' part ?

Color quantization is disabled because True Color is selected by default for PNG.
Color quantization is a method to reduce colors used to obtain paletized images (<8 bit).
Try choosing a preset (ex: Optimal 256 color palette), then color quantization will be enabled. Quantization is not applied for true color images.


with version 0.1.2 the file "Riot.dll" came along. The 0.1.3 package doesn't contain that file.
Should I remove it, or what ?
Yes, you can safely remove it. Riot.dll is the full version plugin for developers.

Sam_Zen
11.05.2008, 12:24 AM
You should read more about tone mapping and HDR to understand what it is.
I did and got an idea about the concept. And I suspect my vintage system not being able to handle the HDR format.

Color quantization is a method to reduce colors used to obtain paletized images (<8 bit).
I should have known. This is cool.
I will use this a lot, because, due to my work, I often have to publish pictures on the web.
So I'm always searching for the smallest size still having the required quality.
For example most screencaptures don't need 24Bpp. They can often do with 16 colors or so.
With the PNG format this can be done more precisely than with JPG.
RIOT is an excellent monitor during this kind of modification.

I've made RIOT an extenal editor within IV (Shift+E).
Usually I start IV by activating an associated file.
I don't expect RIOT to detect this file automatically after Shift+E, but at least the open-dialog starts in that file-dir. Nice.

luciansabo
11.05.2008, 10:31 AM
I don't expect RIOT to detect this file automatically after Shift+E, but at least the open-dialog starts in that file-dir.
I'm working on a new version that supports opening the file directly from IV's Shift+E, when set as 1st external editor.

luciansabo
15.05.2008, 06:41 PM
Hello,

I'm proud to announce the release of the first stable candidate (v. 0.1.4).
Note that Irfan tested my lite plugin and is waiting for a stable version to include in the next version if IV.
So, please test this release by finding any logical errors. Only bugfixes will be applied to this version, no new features will be added.
Requests for new features will be taken into consideration for the next stable version.

Changelog:
v.0.1.4
-changed main icon
-added "Compress to size" for JPEG, GIF and PNG
-files can now be opened by passing them as command line parameters
-some menu items (from View) were not disabled by default (fixed), and enabled when necessary
-improved zoom: center images in scrollbox by default; when the image is moved, the zoom follows what's in the center point of the scrollbox.
-after opening images are resized 1:1 now by default
-improved Convert from non-standard type handling when fails
-bugfix: size in KB was formatted wrong for decimals with leading zeros. ex: 99 bytes was formated 0.9 KB, not 0.09 KB. Fixed!
-transparent files are now handled properly (8bit and 32bit supported) - works only on initialy transparent images.
Does not work with quantization. Transparent images are displayed against a checkerboard background.

I remind you the official website: http://luci.criosweb.ro/riot and I am waiting for your feedback.
The future RIOT plugin for IrfanView will not contain:
-support for anything else than BMP, JPEG, GIF, PNG and DIBs in memory
-tone mapping images with BPP > 32

Sam_Zen
16.05.2008, 05:27 AM
Thanks for the nice work. I will monitor this and report if relevant.

Since Irfan is considering this option, it's becoming on the same level as IVPaint.
So, if it becomes a plugin, I propose as a shortcut for this function : Shift+F12

Bhikkhu Pesala
16.05.2008, 08:26 AM
There seems to be some basic problems with viewing images.

1. Newly loaded images are displayed offset with a margin. Fit to window might be better.

2. Zoom 1:1 prevents the image from being scrolled to the edges. The user can view only a portion of the image in its centre.

luciansabo
16.05.2008, 08:45 AM
Thanks,
It seems it's a small problem with the scrollbox range. Also I've noted the mouse scroll event is locked for zooming only. I should fix these bugs.

Forgot to mention in the changelog the new status bar with the zoom level. For transparent images the text "transparent" is displayed in the status bar.

Bhikkhu Pesala
16.05.2008, 10:24 AM
The attached images are both transparent, but neither shows as transparent in Riot. They are less than full colour. Both get bigger and lose their transparency when saved with Riot.

There doesn't seem to be any option to add transparency if an image lacks it, which IV can do when saving.

luciansabo
16.05.2008, 10:56 AM
Those images have 4 bits per pixel.
RIOT does not support 4 BPP image transparency, neither saving as 4 BPP yet. It can open such images, but it converts them to a minimum of 8 bits per pixel, as 8 bit is the minimum bit depth supported for saving now.
The filesize is larger because of 8 bit conversion.


There doesn't seem to be any option to add transparency if an image lacks it
As I wrote in the website, there is no support for choosing transparent color yet. Transparency is kept for 8 bit and 32 bit images already containing transparency information. Reducing colors of a transparent 8 bit image will lead to the loss of transparent information.

Here is a 32 bit PNG image with alpha transparency.

luciansabo
22.05.2008, 09:50 AM
new stable candidate release:
http://criosweb.ro/software/download.php?sid=riot

v0.1.5 (stable candidate #2)
-scrollboxes are now dragging areas. Image is not allowed to be dragged outside the dragging area.
Top left and bottom right points cannot pass the center point
-new Esc shortcut for exit
-Fit in window improvements, fixes
-minor code cleanup
-added link to official website in the menu and in the about box

Use dragging for moving the image inside the former scrollbox.

Laurent
23.05.2008, 10:18 PM
Hi Lucian,

Nice work, again.

Due to the bigger font I use, there is still a minor problem in the display (see capture).

About dragging the images, as you can see on the capture too, it is possible to drag so much that margins do appear. I don't believe they are useful.
I also noticed that with a right click the mouse cursor becomes a four arrows, as if the image could be dragged, but in fact it can't (only left click enables to drag).
I wonder if it wouldn't be interesting to be able to move the image with the keyboard arrows and/or with horizontal and vertical cursors too.

Laurent

luciansabo
24.05.2008, 09:07 AM
Due to the bigger font I use, there is still a minor problem in the display (see capture).
I shall correct this.


it is possible to drag so much that margins do appear
Actually this is a feature. Dragging is allowed just to the middle of the dragging area. This help zooming what's in the center, not like other scrolling areas where you cannot zoom a corner. This way you can zoom easily every area of the image, including corners.

About moving the image with the arrow keys... I don't know if I should capture these keys since they are usefull for other controls (listboxes, scrollbars, etc).

I am working at a new version that will let you choose to remove or not metadata information. Currently all known metadata is kept.
Then a stable release will be made available to Irfan.

Future plans:
-jpeg smoothening support
-transparency choosing support
-crop tool
-basic image processing
-png multipass optimizer (similar to pngout)
-improved user interface

Laurent
24.05.2008, 10:22 AM
Hi Lucian,


Actually this is a feature. Dragging is allowed just to the middle of the dragging area. This help zooming what's in the center, not like other scrolling areas where you cannot zoom a corner. This way you can zoom easily every area of the image, including corners.
I understand this.

Some other points:
- The process might be a degradation of an image (decreasing color depth, using a large JPEG compression), so the title "Optimized image" is not necessarily the best one. Maybe something like "Processed image" or "Input image" / "Output image"?
- When RIOT opens, the two image windows have different sizes and remain with their sizes once an image is loaded. I would expect they have the same size and see the same part of the initial / optimized image.
- When I choose GIF output, the Color quantization algorithm box is not fully displayed. Is this a problem due to big font too?
- The tooltip displayed when the mouse is over a control disappears after 2 s. This is far too short for me to read some explanations. Is it possible they remain displayed as long as the mouse is over (and maybe a setting in the configuration to enable/disable tooltips)?
- The first shortcut in the View menu is not correctly aligned with te others.

- Not about RIOT (so a bit out of topic): As you can see in the capture, the names of the shortcuts for zooming are written in Dutch. I have the same problem with OpenOffice.org. I believe this is related to Windows language version. But I had ordered my new computer with a french version of Windows. I guess Dell installed a dutch version and modified some files so that it seems to be french, but they missed something. Do you know which file I should replace with the french version (on another PC I have a real french version).

Thanks.
Laurent

Laurent
24.05.2008, 10:53 AM
Lucian,

I just saw some other things:
- No need of a semicolon under the left image between size in B and size in kB.
- The official symbol ("Système International") for "kilo" is a "k" in lowercase.
- Strange behaviour when scrolling an image: when margins appear, the scroll happens to lock, as if the maximum scroll was reached, but when I release the button and try to scroll further it is still possible, but by very little steps (some pixels). Locks again, release the mouse, click and scroll again. I can't get the corner in the center of the window. As you wrote, this would be a problem for zooming the corners.


Laurent

luciansabo
24.05.2008, 10:59 AM
The optimization process does not reffer to a quality tweak, but to a optimal filesize for the web. This is a common term: optimizing images for web.


- When RIOT opens, the two image windows have different sizes and remain with their sizes once an image is loaded. I would expect they have the same size and see the same part of the initial / optimized image.

- When I choose GIF output, the Color quantization algorithm box is not fully displayed. Is this a problem due to big font too?


I did not see this problem until now. They should be equal. It is caused by your 120 dpi setting. The is not fix for that. All your controls are bigger, and they cannot fit in that window.
The only thing I can do is maximize the window automatically for your font settings.


The tooltip displayed when the mouse is over a control disappears after 2 s
For me is ~4s. I will increase this to 7s


The first shortcut in the View menu is not correctly aligned with te others.
It is not alligned because it does not have an icon.

About your problem. I don't know exactly what is the file. It may be from your keyboard layout file. (KBDNE.DLL)
Try to install french keyboard layout from regional settings.
KBDFR.DLL French Keyboard Layout
KBDSF.DLL Swiss French Keyboard Layout

luciansabo
24.05.2008, 11:11 AM
The official symbol ("Système International") for "kilo" is a "k" in lowercase.
You are right. It should be kB for kilobytes. kb is kilobits.


Strange behaviour when scrolling an image: when margins appear, the scroll happens to lock, as if the maximum scroll was reached,
Sorry, but strange things can happen if the scrollareas are not equal. Maximize the window tben see if they are equal.

MItaly
24.05.2008, 05:20 PM
You are right. It should be kB for kilobytes. kb is kilobits.

Actually if you for kilobyte mean 1024 byte (as every program does) it should be KiB (http://en.wikipedia.org/wiki/KiB).

Laurent
24.05.2008, 07:34 PM
Hi Lucian,


Sorry, but strange things can happen if the scrollareas are not equal. Maximize the window tben see if they are equal.

Just to test, I have restored the normal font (96 dpi). RIOT opens then with two images windows of equal size. Then I load an image. I noticed that the stange behaviour has nothing to do with font size or scrollareas.

1. I drag the image right until there is a left magin having half the width of the scrollareas. Then it is not possible to drag the image vertically, except by some pixels at a time (click mouse, drag a bit, release mouse ans so on).

2. Same behaviour when RIOT is maximized.

3. If RIOT is maximized and if I drag the image carefully so that is is in lower right quarter of the scrollareas, then when I restore the original size of the application, the image is totally outside of the scrollareas.

4. Right click of the mouse has no effect. But when I right click on the image it becomes a double arrow. If moreover I release the button outside the image it remains so.

Laurent

luciansabo
25.05.2008, 09:02 AM
it should be KiB.
I sincerely never heard of this kibibyte until now. As I learned in school and as everyone uses, the common abbreviation for 1024 bytes is KB.

After furher readings:

1024 bytes: This definition is used when expressing quantities which are based on powers of two, such as memory chip capacities. Most software also uses it to express storage capacity. This definition has been expressly forbidden by the SI standard[1] and other standards organisations. To indicate a quantity of 1024 bytes, the term kibibyte (KiB) has been recommended instead.[2][3] This term is starting to be adopted by some software, such as a few BitTorrent clients and the Linux kernel.

http://en.wikipedia.org/wiki/Kilobyte

So MItaly is right. I will chage to KiB, but I will still use the word kilobyte to reffer 1024 bytes as I am used to.


1. I drag the image right until there is a left magin having half the width of the scrollareas. Then it is not possible to drag the image vertically, except by some pixels at a time (click mouse, drag a bit, release mouse ans so on).
You can easily drag the image moving the mouse vertically or a bit towards left in this situation. Your problem happends probably because you don't drag it vertically and towards right you hit the limitation.


3. If RIOT is maximized and if I drag the image carefully so that is is in lower right quarter of the scrollareas, then when I restore the original size of the application, the image is totally outside of the scrollareas.
I know about this problem and I fixed this by applying Fit to window on form resize.

A number of small fixes were made based on your suggestions. Thank you very much for you great help.
I will release a next version in 1-2 days.

Laurent
25.05.2008, 09:44 AM
Hi Lucian,

I just read the article on Wikipedia. As I understood, either you divide the number of bytes by 1000 and the unit is named "kilobyte" with symbol kB, or you divide by 1024 and the unit is named "kibibyte" with symbol KiB.
My preference is 1024 (more usual), but are there many people who know and will understand "KiB" and "kibi"?

About scrolling, I think it is not normal to have to slightly move the image in one direction towards center to be able to scroll it in the perpendicular direction. This is not user-friendly. You wanted to make zooming more easy, but the consequence is that scrolling is more difficult (and less intuitive).

What about a zoom with the mouse wheel (or +/- keys) that holds the pixel under the mouse cursor at its position in the scrollarea? If the zone of interest goes outside, it is easy to bring it back with the mouse. And no need to be able to drag the corner of the image towards the center of the scrollarea :)

Laurent

luciansabo
25.05.2008, 06:00 PM
either you divide the number of bytes by 1000 and the unit is named "kilobyte" with symbol kB, or you divide by 1024 and the unit is named "kibibyte" with symbol KiB.
Let's clear things out. I respect IEC recomendation, but in computing everyone that went to school learned that 1 byte has 8 bits. 1024 bytes is 1 kilobyte (short kB or KB). 1000 bytes is not 1 KB in computing. This confusion is made by people that did not learned in school or read it elsewhere. Anyhow is normal te clear out this confusion because kilo is for every unit 1000, not 1024 so is correct to change his name, but too late I think. Everyone uses kilobytes to refer 1024 bytes and this kibi-bibi or what it's name will not catch I think.
Most applications display KB not kiB.
Anyhow I will use KiB for now, but if confuses people, I will change it back to kB.


I think it is not normal to have to slightly move the image in one direction towards center to be able to scroll it in the perpendicular direction.
I really don't have problems dragging the image. You just have to drag it exactly vertically in your case not towards left or right. But I will try to improve it because some users may find it annoying.

luciansabo
25.05.2008, 06:02 PM
What about a zoom with the mouse wheel (or +/- keys) that holds the pixel under the mouse cursor at its position in the scrollarea?

Zooming with mousescroll is already supported. Keep Ctrl key pressed and scroll the mosue wheel.
+/- keys are already supported for zoom.
Zooming already keeps the position of the point of interest (center point).

Bhikkhu Pesala
25.05.2008, 06:36 PM
Keeping the pixel under the mouse cursor in the same place while zooming is very useful. IrfanView doesn't quite succeed in doing this. Serif PagePlus does it very well.

It is also worth implementing a modifier such as Shift + Scroll-wheel to scroll horizontally.

Laurent
25.05.2008, 06:51 PM
Lucian,


I really don't have problems dragging the image. You just have to drag it exactly vertically in your case not towards left or right. But I will try to improve it because some users may find it annoying.

I believe the problem may be that I am scrolling in a particular way. If I want to drag the upper left corner towards the center of the scrollarea and if the image has already benn dragged to the as much possible to the left, then I try to drag it down and slightly to the left so that it remains to the left as it was before.

Laurent

Laurent
25.05.2008, 07:03 PM
Lucian,


Zooming with mousescroll is already supported. Keep Ctrl key pressed and scroll the mosue wheel.
+/- keys are already supported for zoom.
Zooming already keeps the position of the point of interest (center point).

Thanks for the tip. I didn't know or I forgot to press Ctrl.

On my laptop, the usual +/- keys don't work, only their equivalent on a numeric keypad (I have to hit Fn= for '+' and FnM for '-'). It would be nice if both worked.

The point of interest is not always the center of the scrollarea. The interest of the programmer may differ from the interest of the user ;)

Laurent

Sam_Zen
26.05.2008, 01:39 AM
I agree with Lucian from a practical point of view about using the 'KiB' string. It's just too late for that.
What's left is the educational side, to tell people that Kilo means 1000 if meters, but on a PC it means 1024 as unit.
Due to the structure of powers of 2. So not a decimal-based structure.
If users would know about the binary base of things, they would understand the default range of used colors in a bitmap.

I think 'Compress to size' is a nice option, because on forums there are often restrictions about filesize, e.g. avatars.
I have a luxury request : A transferred filename to the 'Save as' dialog.

luciansabo
26.05.2008, 08:30 AM
The point of interest is not always the center of the scrollarea. The interest of the programmer may differ from the interest of the user
I don't look this from the programmer's side. The center point usually is what you want to see. So to scroll to a certain point you just have to drag the image to put that point in the middle. I avoid making zoom's default behaviour zoom to mouse point insteaf of zoom to center point, because users may put the mouse accidentally over the image in different points and wonder why zooming is so strange.
It's hard to move into center what you want to zoom? I don't think so.
I came out with an ideea to improve dragging. I will work on it today :)


I have a luxury request : A transferred filename to the 'Save as' dialog.
I don't understand.

Bhikkhu Pesala
26.05.2008, 04:00 PM
I don't understand.
If I open a file named "Scanner.png" in IrfanView and click the SaveAs.. icon the filename is already in the dialogue box, so it will be saved as "Scanner.jpg", "Scanner.gif", etc., — I don't need to type in the filename unless I wish to change it. I wouldn't regard this as luxury, but as a basic feature. It is much more efficient since more often than not, when converting files I wish to retain the file name. Even when resizing files, I wish to append to the original filename, e.g. Scanner Small.png.

Having the filename already in the dialogue field saves time and reduces errors. Of course, it also introduces the possibility that some users will overwrite their original files with the resized one, so a warning dialogue is needed on overwriting files of the same name. I suspect that you already have that.

Laurent
26.05.2008, 08:58 PM
Hi Sam_Zen,

I believe it is indeed something very useful to have the original filename as the default Save as filename (except the extension of course).

Laurent

Sam_Zen
27.05.2008, 01:35 AM
Of course.
Sure there is the danger of overwriting the original, but I have the habit of adding e.g. a 's' trailing the existing filename.
If that danger exists. As indication of a small version. It still saves typing again the full filename.

Afterwards, one can judge if the new version is ok, remove the original, and then remove the 's' again of the new file.

luciansabo
27.05.2008, 07:17 AM
Hm... I understand now. I shall implement this. Good suggestion ! I've completelly forgot about this.
There is a overwrite confirmation dialog. So the user is warned about overwriting and he decides.

luciansabo
27.05.2008, 09:37 AM
A new stable candidate release is available

Here are the modifications. Many thank for your great suggestions !

v.0.1.6
-known metadata can now be removed or kept by model
(unknown or unsupported metadata is automatically dropped - exif is dropped)
Lite version supports only choosing to keep comments. Other metadata is removed
-image dragging improvements
-minimum form size is now 681x389
-on form resize the image is centered
-default Filename in Save Picture Dialog is now the opened filename without extension
if the source image is a DIB from memory (loaded from Clipboard, Resampled) the default Save as filename is "Untitled"
-the allocated DIBs are freed now OnDestroy, not OnClose

minor fixes:

-default tooltip HidePause is now 7 seconds
-kilobyte (1024 bytes) symbol is now KiB, as IEC recommends
-removed semicolon from original image size label
-right-click on image does not show a sizeAll cursor anymore
large dpi font size bugfixes:
-form is now resized for large screen dpi (>96) to fit controls
-scrolling areas were shown with different sizes. Now they are equal
-top label about optimized file (ex: 24 bit JPEG...) position is now correctly calculated
-first status bar panel (with zoom display) resized to fit text with 120dpi font settings
-minor changes in DLL interface

PS: I've noticed that the image is positioned wrong by opening with Open button instead of dropping the file on the window.
Small notes:
-metadata is automatically removed for 8 bit images.
-the Compress to Size function has a smart binary-search-type algorithm that finds the closest value with minimum trial steps (usually 4-5).

Sam_Zen
28.05.2008, 12:51 AM
Very nice work.

Maybe it could be useful, when having a new stable version, to add the link to http://luci.criosweb.ro/riot again at the bottom of the post.
Now, I had to go back to page one of this thread to find it.

4eyes
28.05.2008, 11:34 AM
Great program!
The only thing I miss in the standalone version is a crop tool.
Off course this is not an issue when the IV plugin is made.

Bhikkhu Pesala
28.05.2008, 12:48 PM
There is still an issue with the position of images on loading as reported in this post (http://en.irfanview-forum.de/vb/showpost.php?p=9497&postcount=21).

1:1 is the best choice for seeing the effects of optimizing, but fit to window is the best option to show the whole image on loading. Then the user can zoom in to the area of greatest interest (e.g. a face) before adjusting the image.

It is very unlikely that the important part of the image will be shown on loading, and I don't see the need for the large border around the image — 5 or 10 pixels would be sufficient just to indicate where the edge is.

The positioning of different images seems to be random.

luciansabo
28.05.2008, 08:20 PM
I was aware of this error few hours after the last release. A corrected version is now available:

http://luci.criosweb.ro/riot/

v.0.1.7 (stable candidate #4)
-Fit to window is now applied on open
-after resample image was not centered. Fixed
-added option in View menu: Fit in window only big images.
-change resample form tab order
-minor code cleanup

Future plans include a crop tool.

Sam_Zen
29.05.2008, 01:57 AM
As a standalone version I could understand adding a crop function, but not as a IV-plugin.
But is cropping still part of the 'optimizing' concept ? I doubt that.

By the way, Lucian.
I've added your application on my webite, not only with the site-link, but also with a stand-alone DL of the recent file.
You can check the construction here (http://www.xs4all.nl/~samzen/links.html#graph).
If you have any objection to this, let me know.

luciansabo
29.05.2008, 08:08 AM
RIOT will come in 3 flavours:
-a full standalone application
-a full DLL for developers
-a lite plugin DLL for Irfan View

The plugin for IV will not contain the crop tool as neither the full version contains it.
Missing features of the lite version are:
-tone mapping HDR images
-open other formats different from bmp, jpeg, gif and png
-choose to keep or remove IPTC and XMP info metadata

As cropping is a basic operation in image processing the full version will have a crop tool. Basic image processing functions will be implemented as well (channel, gamma, brightness, contrast, saturation).
The IV plugin will concentrate for now on optimizing images for web.

If cropping is part of the process it's a good question. I think it is. I use cropping daily. Without the crop tool RIOT is not complete for me. It it not a mandatory part of the optimization, indeed, but it is a necesary step often.

Those that need enhanced functionality that the full version will provide can download later the full DLL from my website and overwrite the lite one.

PS: I am attaching a file with metadata information for testing.


I've added your application on my webite, not only with the site-link, but also with a stand-alone DL of the recent file.
Thank you for your support, but I have a couple of suggestions:
-this is not RIOT Lite. His name is just RIOT. Lite is only the future IV plugin that you cannot test without a future IrfanView version.
-the link points to my homepage. The official website for RIOT is http://luci.criosweb.ro/riot/ , so users arrive directly to the application website. My homepage is in romanian and it is unlikely someone to find the RIOT link. :)

luciansabo
29.05.2008, 09:25 AM
I've noticed that after resampling the images have the same size (even if they are resampled) due to fit in window setting. Don't you think after resample I should automatically call 1:1 to show the original size?

Later edit: I think after resample the first thing a user wants to see is how the image looks in its original size. I made automatic actual view(1:1) and centering after resample in a pre-release build.

I am waiting for other bug reports or corrections to include into 0.1.7
Hopefully this will be the last version of branch 0.1, finally in a 'stable' state.
build 0.1.7.2
-fixes in Fit to Window
-actual view is applied after resample

luciansabo
29.05.2008, 07:46 PM
New pre-release:

build 0.1.7.3
-drawing speed ups (up to 5 times faster displaying of optimized images)
-flicker reduced on drawing
-minor fixes

Sam_Zen
30.05.2008, 02:45 AM
Thanks for your suggestions. I have corrected this on my page.

Bhikkhu Pesala
30.05.2008, 08:24 AM
Why can't small programs open big images? See also this thread (http://en.irfanview-forum.de/vb/showthread.php?t=2180)

RIOT failed to open a large image — IrfanView did too — but it is not that big. CorelPhotoPaint 9 (©2001) can open it just fine (image information from PhotoPaint attached). I have 1 Gbyte of RAM.

It seems that modern software is not as good as the old stuff. Micrografx Picture Publisher is even better than PhotoPaint for working on big images.

luciansabo
30.05.2008, 09:08 AM
You have a huge image.

It does not fit in your memory.
Working with huge DIBs in memory requires a big quantity of RAM.
Just to make you a calculation:

DIB filesize ~ = headersize + rowsize * height
where rowsize = 4 * (((n*width)+31)/32)

so
in your case
n = 24 (24 bits per pixel)
width = 19843
height = 28063

rowsize ~= 59532
filesize ~= 54 + (59532 * 28063) = 1.670.671.125 bytes
This requires 1593 Megabytes and you have only 1000

Maybe PhotoPaint and Micrografx Picture Publisher are designed to work with big images, caching parts of it or the whole image on disk. But programs that use memory to store images (like IV or RIOT) cannot do it if you don't have enough RAM.

DIBs require RAM.
On the other hand, DDBs require graphic card memory.

RIOT was not designed for this kind of utilization you ask for.
I tested it with a 9000x9000 image on my 2 GB machine and it works.
At peak time memory goes up to 1.5 GB and idle at 980 MB. More RAM, bigger files it can handle.

Bhikkhu Pesala
30.05.2008, 10:05 AM
Micrografx Picture Publisher couldn't load it either, but it managed OK when loading a smaller image (NASA's Whirlpool Galaxy: 5739 x 3983 Pixels). Then I could resize that image 200% in a fraction of the time taken by IrfanView. Riot almost gave up.

Time to resize 200% to 11478 x 7966 pixels

Picture Publisher with Smart Sizing: 3 seconds
Irfan View with Lanczos (slowest): 50 seconds
Riot with Bilinear (fast good): 150 seconds.
Riot with Lanczos3 (slow very good): 160 seconds.
Serif™ PhotoPlus 11 Lanzcos3: 170 seconds
PhotoPaint with Antialias: 30 seconds

I don't know what algorithm Picture Publisher is using, but it is not just a simple resize operation. Whatever it is doing, its design is far better than IrfanView. Riot is clearly doing something very wrong to take so long. I realise that most users won't be resizing huge images, but 6 megapixel cameras are pretty much standard nowadays.

You can use the SmartSizing option to maintain most of the detail of an image when you change the size or resolution. When the size or resolution decreases, pixels are discarded. Most other programs discard or replicate pixels, regardless of color value. With SmartSizing, each pixel that remains is newly generated from the color values of the discarded neighboring pixels. Each of the pixels in the original image contributes to the pixels in the new image.

When image size or resolution increases, new pixels are created by sampling the neighboring pixel values. Although it takes a little longer for Picture Publisher to process the changes, SmartSizing helps the image to retain the best possible quality after resizing.

Copyright © 1995 by Micrografx, Inc.

luciansabo
30.05.2008, 10:40 AM
lanczos3 is the slowest.
Yuu tested with RIOT's bilinear implementation, that is slightly slower than Box filter, that is the fastest.

Resample with RIOT is aparently slow, but for large images the time for resize quite good (~few seconds). You wait so much because of the preview. Opposite to IV or Micrographics RIOT is also saving the image, then loading from memory, then converting into windows DIB, and that's why it takes so much.

For example with a 6000x4000 image, resample with box filter takes only 5 seconds on my machine (lanczos about 8), then few more seconds for loading. The time consuming part is SAVING. You can see the moment when it starts to preview when the busy cursor appears.

PS: It seems from the description that Nearest Neighbour is implemented in Micrographics, that is the same as Box filter.
Actually it's funny you mentioned, but IV has a very slow resampling. The fastest resample filter is very sloow.

Sam_Zen
09.06.2008, 12:20 AM
I wanted to make a GIF button, having transparency, a bit smaller.
If I open the file with RIOT it shows the transparency neatly in both frames with the grey chessboard.
After doing a resize, the left view shows a 32-bit DIB version, still with the transparent indication.
But the preview at the right has lost the transparency, and so does the resulting file after a 'save as'.
If I do the same routine in IrfanView, the transparent mode is still preserved.
I don't even have to select that color again in the saving dialog.

luciansabo
16.06.2008, 09:08 AM
What's wrong with this forum ? It was down for days...


After doing a resize, the left view shows a 32-bit DIB version, still with the transparent indication.
But the preview at the right has lost the transparency
This is a known issue.
Transparency is lost after color quantization.

After resample 16-bit RGB bitmap are returned as 24-bit. Palettized and 4-bit bitmap are returned as 8-bit palettized images, using an internal conversion to 24-bit followed by a color quantization, or are returned as 32-bit if they contain transparency.
Resampling refers to changing the pixel dimensions (and therefore display size) of an image. When you downsample (or decrease the number of pixels), information is deleted from the image. When you upsample (or increase the number of pixels), new pixels are added based on color values of existing pixels. You specify an interpolation filter to determine how pixels are added or deleted.
The following filters can be used as resampling filters:

Box, pulse, Fourier window, 1st order (constant) B-Spline
Bilinear filter
4th order (cubic) B-Spline
Mitchell and Netravali's two-param cubic filter
Catmull-Rom spline, Overhauser spline
Lanczos-windowed sinc filter

In your case, resampling a 8 bit transparent image results in a 32 bit RGBA image. GIF cannot contain 32 bit data, thus it is quantized to 8bit/256 colors.
Automatic color quantization is applied, and the color quantization algorithm does not maintain transparency for now.

For a transparent 8 bit image source, you can see a transparent 8 bit gif result, but reducing colors will lose transparency.
The same for a 32 bit transparent PNG. If you leave it True Color it will stay transparent. If you reduce colors, the transparency is lost.

A new version is available
Here is the changelog:

v.0.1.7 (stable candidate #4)
-after resample image was not centered. Fixed
-Fit to window is now applied on open
-added option in View menu: Fit in window only big images.
-change resample form tab order
-minor code cleanup
-fixes in Fit to Window
-actual view is applied after resample
-drawing speed ups (up to 5 times faster displaying of optimized images)
-changed about box
-decreased memory usage.
-flicker effect on zoom, moving or displaying eliminated
-new ckeckbox for JPEG and PNG: remove embedded ICC profile
-MetadataHandler rewrote
-dragging fix when the mouse cursor is over the other image
-speed optimizations for Riot Full. Lite version is slightly slower than the full version.
-compiler optimizations
-RIOT full is now capable of displaying jpeg and bmp in the small preview area of the open dialog
Lite version supports only bmp preview
-removed emf and wmf from the supported file types for now
-on high resolution images (>=4 MegaPixels) the user is asked if he wants to resize.
This comes as a loading speed-up aid, as most of users need to resample anyway.
-program status (loading, processing, displaying, etc) is displayed now in the status bar
-fixed a bug when images with a BPP other than 1,8, 24 and 32 cannot be rotated
-small display speedups after rotate, flip. Image loading speed-up for BPP smaller than 24
-fixes for paste from clipboard
-metadata is now always kept
-default resample filter is now Catmull Rom (very good results and decent speed)

Download from RIOT website: http://luci.criosweb.ro/riot/

You can also test the first release of the Lite plugin that will become an IV plugin. I've compiled a sample application that will let you test the plugin.
The method used within IV will be Load from DIB.
Download it from here: http://www.criosweb.ro/software/Riot_Lite.rar

PS: Iv does not keep transparency at all. You have to choose it again.
It does not keep it even on the same file with no modifications :)

Verywierd
21.08.2008, 12:13 PM
Hi,

I just downloaded both the full dll and stand alone versions of RIOT and in both cases, the metadata options are greyed out (and ticked) when I open a jpeg. Is there something I'm missing or doing wrong? Being able to adjust for web without going into Photoshop would be very usefull, but I need the ICC profiles retained. TIA

luciansabo
26.08.2008, 03:07 PM
Try this:
-Open a JPEG picture with embedded ICC profile using the program.
-if ICC checkbox is disabled it means no ICC profile exists.
-if not disabled you may choose to keep or remove the ICC profile