png (de)compression is very slow for large images. Would it seem in scope to support .ppm or some other mem-dump format with no CPU overhead?

I get dssim: src/dssim.c:663: to_dssim: Assertion ssim > 0' failed.` for a pair of handmade 320x320 test images, and apparently the choice of colors matters. I haven't tested any less garish colors, nor if the red border is in any way relevant.

$ ./bin/dssim  yellow_darkblue.png  green_blue.png 
dssim: src/dssim.c:663: to_dssim: Assertion `ssim > 0' failed.
Aborted (core dumped)
$ ./bin/dssim  blue_darkblue.png green_blue.png 
0.42122125      green_blue.png
$ ./bin/dssim  blue_darkblue.png yellow_darkblue.png 
0.49453378      yellow_darkblue.png

On certain JPEGs, I get the following message output: initImageAppleJPEG:1416: falling back to libJPEG

Should I be worried about this?

It should run on Windows 32 or 64 bits (tested on Seven 64 bits)
Download link: http://css-ig.net/tools/zip/dssim.zip

Here, it should be DEFAULT_WEIGHTS[0..5] (indexing is start:end-1).

Also it would be handy if it was possible to specify the number of scales from a command line.

Patch:

*** dssim.c-old    2017-01-19 12:06:20.330095015 +0100
--- ./dssim.c   2017-02-18 12:43:45.230141768 +0100
*************** dssim_image *dssim_create_image_float_ca
*** 579,584 ****
--- 579,585 ----
              chan_width /= 2;
              chan_height /= 2;
              if (chan_width < 8 || chan_height < 8) {
+                 ++s;
                  break;
              }
          }

For integration with Homebrew (Mac) it would be useful to have a valid "install" target in the Makefile.

See: Homebrew/homebrew-core#1004 (comment)

LAB space is non-linear, so I'm not sure if subsampling of AB components makes sense.

Pooling done by taking a maximum error of each 4 nearby samples and then averaging them improves TID 2008 score.

Probably this models an effect where big errors stand out and make correctness of area around them less relevant.

Compiling in MSYS2/MinGW using media-autobuild suite:

   Compiling dssim v2.11.1 (E:\MABS\build\dssim-git)
error[E0596]: cannot borrow `dst` as mutable, as it is not declared as mutable
   --> src\blur.rs:132:19
    |
118 |     pub fn do_blur(src: ImgRef<f32>, dst: ImgRefMut<f32>) {
    |                                      --- help: consider changing this to be mutable: `mut dst`
...
132 |         let dst = dst.buf_mut();
    |                   ^^^ cannot borrow as mutable

logs.zip collected by MABS

I have dssim.exe in the same directory as where I'm running my shells (root folder of VSCode project), & I keep getting the same error:
bash: dssim: command not found
& Powershell:

dssim : The term 'dssim' is not recognized as the name of a cmdlet, function, script file,    et, function, script file,                                                                t   
or operable program. Check the spelling of the name, or if a path was included, verify thah was included, verify that
the path is correct and try again.
At line:1 char:1
+ dssim                                                                                       
+ ~~~~~
    + CategoryInfo          : ObjectNotFound: (dssim:String) [], CommandNotFoundException  CommandNotFoundException
    + FullyQualifiedErrorId : CommandNotFoundException 

In cmd.exe, I get the expected help when I run dssim, & works great with actual PNGs.

v3.0.0 dssim, Win10, VSCode

assert(ssim > 0); in to_dssim() fails.

Commandline:
bin/dssim /tmp/crash-original.png /tmp/crash-modified.png

dssim segfaults on trying to compare images from archive.
https://dl.dropboxusercontent.com/u/35428589/Do%20not%20touch/sample.tar.gz

Hello, I get the following error message when I try to compile dssim:

# cargo build --release Compiling mozjpeg-sys v0.10.5 error: linking with gccfailed: exit code: 1 | = note: "gcc" "-fno-use-linker-plugin" "-Wl,--nxcompat" "-nostdlib" "-m64" "C:\\Users\\Pat Rick\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\dllcrt2.o" "C:\\Users\\Pat Rick\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsbegin.o" "-L" "C:\\Users\\Pat Rick\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "D:\\Download\\m-ab-s\\build\\dssim-git\\target\\release\\deps\\mozjpeg_sys-648e1100be522e84.mozjpeg_sys.5z8axcoy-cgu.0.rcgu.o" "-o" "D:\\Download\\m-ab-s\\build\\dssim-git\\target\\release\\deps\\mozjpeg_sys-648e1100be522e84.dll" "-Wl,--version-script=C:\\Users\\PATRIC~1\\AppData\\Local\\Temp\\rustcdT3FW4\\list" "D:\\Download\\m-ab-s\\build\\dssim-git\\target\\release\\deps\\mozjpeg_sys-648e1100be522e84.3ut8t4tviab954pf.rcgu.o" "-Wl,--gc-sections" "-nodefaultlibs" "-L" "D:\\Download\\m-ab-s\\build\\dssim-git\\target\\release\\deps" "-L" "D:\\Download\\m-ab-s\\build\\dssim-git\\target\\release\\build\\mozjpeg-sys-b5e493b230603ec9\\out" "-L" "C:\\Users\\Pat Rick\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib" "-Wl,-Bstatic" "-Wl,--whole-archive" "-lmozjpeg62" "-Wl,--no-whole-archive" "D:\\Download\\m-ab-s\\build\\dssim-git\\target\\release\\deps\\liblibc-9eeb32fa6e1507b1.rlib" "-Wl,--start-group" "C:\\Users\\Pat Rick\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libstd-2709d4b440f1e31a.rlib" "C:\\Users\\Pat Rick\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libpanic_unwind-a9004ff0947ef669.rlib" "C:\\Users\\Pat Rick\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libhashbrown-51ba26adca1c882c.rlib" "C:\\Users\\Pat Rick\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\librustc_std_workspace_alloc-845f51604911fcc4.rlib" "C:\\Users\\Pat Rick\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libbacktrace-de041ab5ae3894b3.rlib" "C:\\Users\\Pat Rick\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libbacktrace_sys-583b927240902ae3.rlib" "C:\\Users\\Pat Rick\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\librustc_demangle-dc3974e5e5ee3f1e.rlib" "C:\\Users\\Pat Rick\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libunwind-93e1dea24f969698.rlib" "C:\\Users\\Pat Rick\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcfg_if-59c69470ac86444e.rlib" "C:\\Users\\Pat Rick\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liblibc-5fe3f715aad021c1.rlib" "C:\\Users\\Pat Rick\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\liballoc-289552190fa6ddd0.rlib" "C:\\Users\\Pat Rick\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\librustc_std_workspace_core-663fc4811d41d373.rlib" "C:\\Users\\Pat Rick\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcore-985f2d98a138c88e.rlib" "-Wl,--end-group" "C:\\Users\\Pat Rick\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\libcompiler_builtins-8d584b80572e52da.rlib" "-Wl,-Bdynamic" "-ladvapi32" "-lws2_32" "-luserenv" "-Wl,-Bstatic" "-lgcc_eh" "-lpthread" "-shared" "-Wl,--out-implib,D:\\Download\\m-ab-s\\build\\dssim-git\\target\\release\\deps\\mozjpeg_sys-648e1100be522e84.dll.lib" "-Wl,-Bdynamic" "-lmingwex" "-lmingw32" "-lgcc" "-lmsvcrt" "-lmsvcrt" "-luser32" "-lkernel32" "C:\\Users\\Pat Rick\\.rustup\\toolchains\\stable-x86_64-pc-windows-gnu\\lib\\rustlib\\x86_64-pc-windows-gnu\\lib\\rsend.o" = note: D:\Download\m-ab-s\build\dssim-git\target\release\build\mozjpeg-sys-b5e493b230603ec9\out\libmozjpeg62.a(jcmaster.o):jcmaster.c:(.text$copy_buffer+0xd0): undefined reference to__imp___acrt_iob_func'
D:\Download\m-ab-s\build\dssim-git\target\release\build\mozjpeg-sys-b5e493b230603ec9\out\libmozjpeg62.a(jerror.o):jerror.c:(.text$output_message+0x1d): undefined reference to `__imp___acrt_iob_func'

error: aborting due to previous error

error: could not compile mozjpeg-sys.

To learn more, run the command again with --verbose.

I have no experience with Rust so it would be great if there's some guidance on how to intergrate dssim v2 with c++ codebase.

Hello,

This might be related to my currently installed version of libpng (cf #31), but I can't seem to be able to compare any two png files.

No matter what files I pass as parameters, dssim fails with the following message:

Can't read ./input.png

FWIW, here are the two files I used in my tests (hoping that uploading them to GitHub won't modify them too much):

(md5sum: e26f1b5fb954a82ce9e514026330a415 and ec0d02893bd1c92978527071f5505263)

I want to compare two images to check similarity between both if any one can provide me with the documentation regarding nodejs implementation I will be highly thankful

We've been using your tool to aid in evaluating quality of JPEGs, and are really happy with how helpful its been.

The only mention I could find on what threshold to base our evaluations on indicates that a score of 0.015 reflects that the image pair is typically indistinguishable from each other. However, their reference doesn't even mention anything about this (!).

Do you have any pointers to research done on this? Do you have any opinions on a useful threshold, and/or do you agree with a value of 0.015?

Thanks

Hello,

I've just tried to run make in the freshly cloned dssim directory but was greeted with the following answer:

make
cc -Wall -I. -DNDEBUG -O3 -fstrict-aliasing -ffast-math -funroll-loops -fomit-frame-pointer -ffinite-math-only -std=c99 `pkg-config libpng --cflags || pkg-config libpng16 --cflags`    -c -o src/main.o src/main.c
In file included from /usr/include/libpng12/png.h:321:0,
                 from src/main.c:26:
/usr/include/libpng12/pngconf.h:383:21: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘.’ token
            __pngconf.h__ in libpng already includes setjmp.h;
                     ^
/usr/include/libpng12/pngconf.h:384:12: error: unknown type name ‘__dont__’
            __dont__ include it again.;
            ^
/usr/include/libpng12/pngconf.h:384:29: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘it’
            __dont__ include it again.;
                             ^
/usr/include/libpng12/pngconf.h:384:29: error: unknown type name ‘it’
<builtin>: recipe for target 'src/main.o' failed
make: *** [src/main.o] Error 1

I think I have all the needed dependencies installed, but have no idea how to move forward from here. Thanks for any help.

✔ libpng12-dev  1.2.54-1ubuntu1
✔ zlib1g-dev      1:1.2.8.dfsg-2ubuntu4
✔ pkg-config      0.29.1-0ubuntu1
✔ make             4.1-6

Hi!
Tell me, how to compile dssim for windows?

It would be great if you could expose an API, as we would use it in "gst-validate", an automated Quality Assurance tool for the GStreamer framework :) Ideally we could even wrap it in a gstreamer element and integrate it in complex pipelines.

dssim finds differences in the two all black (as far as I can tell) PNGs below, i.e. instead of 0.000000 it prints 0.03023894. One of the images is truecolor, the other is grayscale. Both were generated with ImageMagick 7.0.2-1 using libpng 1.2.54-1ubuntu1, cropped from the same source image, but one was converted to a jpeg with quality 70 before cropping.

When used with any image with width or height less than or equal to 15, dssim fails with an Assertion:

dssim: src/dssim.c:668: to_dssim: Assertion `ssim > 0' failed.
Aborted (core dumped)

In the process of making changes to formulae in the Homebrew package manager, I noticed that dssim was one of a handful of Rust binary projects without a Cargo.lock file in version control. The Cargo book recommends the following (source):

If you’re building an end product, which are executable like command-line tool or an application, or a system library with crate-type of staticlib or cdylib, check Cargo.lock into git.

More information about the reasoning can be found in the "Why do binaries have Cargo.lock in version control, but not libraries?" section of the Cargo FAQ.

The Cargo.lock file helps package managers to keep builds reproducible, since cargo install simply uses the latest dependency versions unless the --locked flag is added to the command, in which case it will use the versions outlined in Cargo.lock. Without a Cargo.lock file, there's a chance that a dependency update will break the build sometime in the future, which is something I've already encountered with other Rust binary projects.

Would you please consider checking Cargo.lock into version control?

Would you consider licencing under Apache 2.0 so that we can consider adding it to Guetzli?

Helps downstream notice newer versions. For example, on GitHub one can watch "Releases only".

See the similar issue in libjxl.

It would be great to evaluate DSSIM on the CLIC-2021 perceptual quality task. This should provide additional information to he community with respect to its performance characteristics when compared to other potentially usable perceptual quality metrics.

Please use the test data from the CLIC 2021 perceptual challenge to generate a CSV file with the decisions (see link below for the exact instructions):

https://github.com/fab-jul/clic2021-devkit/blob/main/README.md#perceptual-challenge

Please email them to George Toderici (or me) to get the final results / ranks. We'll publish these at: http://compression.cc/leaderboard/perceptual/test/

...and of course update this bug tracker.

The last official release on Github is 1.1 while there are newer tags. Would you please offer releases with source archives for integration with homebrew?Thga

Homebrew/homebrew-core#1004

Hello,

I tried the last version dssim-2.8.0 using Rust released and found a small issue , for now i'm not sure what is going on.

On previous version 1.3.2 comparing two .png's with the option -o to visualize the difference was giving me this :
original

modified

-o option to visualize the differences :

Now using the new 2.8.0 provided windows .exe in the release page and comparing the two same images it creates 4 small pictures with the size decreasing when i use the -o option, this is what i get :

The DSSIM score :
v1.3.2 score = 0.00289185
v2.8.0 score = 0.10827

Well i'm lost with the 4 pictures created, i don't understand
If it helps i'm under win7 x64.

And thanks a lot for this nice little tool, something i use regularly and very helpful :)

Edited original post :
found out what was the issue for the second problem i reported when using a bat file, silly me... so i just removed this unnecessary part, remains the creation of those 4 small pictures now.

Thank you.

It's probably a color profile or gamma issue or something, if I convert to .pam first and then to .png (to make sure that the PNG does not contain any such metadata), it works fine.

E.g. comparing these two images causes a segfault:

when i try to build dssim and type this command on Ubuntu bash :
cargo build --release --verbose
i get this error
error: Could not compile rayon-core.

Caused by:
process didn't exit successfully: rustc --crate-name build_script_build /root/.cargo/registry/src/github.com-1ecc6299db9ec823/rayon-core-1.3.0/build.rs --crate-type bin --emit=dep-info,link -C opt-level=3 -C metadata=29a42b65b777dc05 -C extra-filename=-29a42b65b777dc05 --out-dir /mnt/d/sarya2017/dssim/target/release/build/rayon-core-29a42b65b777dc05 -L dependency=/mnt/d/sarya2017/dssim/target/release/deps --cap-lints allow (exit code: 101)
warning: build failed, waiting for other jobs to finish...
error: build failed`

i dont know what the problem , Any help i appreciate it

Tested successfully on Windows 7 64 bits, compiled with libpng 1.6.12 and zlib 1.2.8.
Link: http://css-ig.net/tools/zip/dssimv0.4.zip

The compiled version for windows is very old.
Please, give a compile of the last verision or give a makefile.vc (makefile for microsoft visual C)

After updating to dssim 3.0.0 two of my tests fail with:

assertion failed: i <= 1.0 && i >= 0.0

One of them compares an image to itself, and the other compares that image to itself rotated by 90 degrees.

This failure seems to occur only when dssim is built in debug mode.

It can be reproduced by building the cli v3.0.0 in debug mode and running:

$ dssim beer-solid.png beer-solid.png

or

$ dssim beer-solid.png beer-solid-sideways.png

If the cli is built in release mode and the same commands are run, the process completes as expected, reporting the dssim values: 0.00075077 and 1.64705301, respectively.

These images are rendered from the Font Awesome Free beer icon in the Solid style.

Font Awesome Free 5.15.2 by @FontAwesome - https://fontawesome.com License - https://fontawesome.com/license/free (Icons: CC BY 4.0, Fonts: SIL OFL 1.1, Code: MIT License)

When comparing images with different dimensions we trigger the debug assert in impl Channable<f32, f32> for DssimChan

So I was looking into fixing this issue either by changing the visibility of DssimImage & DssimChanScale's proprieties to public so I can inspect the sizes before calling into Dssim::compare.

Or to change it on the Dssim side by either returning Dssim(1.0) or whatever flag value inside Dssim itself.

What approach you think it's best?

I will make a PR for the fist approach as it's a lot less work and adds a lot more flexibility to use this crate as a lib.

For example:
• compare chroma in full resolution (without subsampling) — useful for images where subsampling of chroma is actually visible
• making the comparison single-scale — useful for use cases where it is definitely known that only small details might change

running cargo build --release --jobs=2 results in

warning: use of deprecated item 'imgref::Img::buf': Don't access struct fields directly. Use buf(), buf_mut() or into_buf()
   --> src\blur.rs:131:20
    |
131 |         let src = &src.buf[..];
    |                    ^^^^^^^
    |
    = note: `#[warn(deprecated)]` on by default

warning: use of deprecated item 'imgref::Img::buf': Don't access struct fields directly. Use buf(), buf_mut() or into_buf()
   --> src\blur.rs:132:24
    |
132 |         let dst = &mut dst.buf[..];
    |                        ^^^^^^^

warning: use of deprecated item 'imgref::Img::buf': Don't access struct fields directly. Use buf(), buf_mut() or into_buf()
   --> src\blur.rs:158:37
    |
158 |             do_blur(srcdst.new_buf(&srcdst.buf[..]), tmp_dst);
    |                                     ^^^^^^^^^^

warning: variable does not need to be mutable
   --> src\blur.rs:143:17
    |
143 |             let mut dstrow = &mut dst[y*dst_stride..y*dst_stride+width];
    |                 ----^^^^^^
    |                 |
    |                 help: remove this `mut`
    |
    = note: `#[warn(unused_mut)]` on by default

warning: 4 warnings emitted

   Compiling dssim v2.11.0 (C:\media-autobuild_suite-master\build\dssim-git)
error[E0277]: `?` couldn't convert the error to `lodepng::ffi::Error`
  --> src/main.rs:46:59
   |
46 |     let img = load_image::load_image(path.as_ref(), false)?;
   |                                                           ^ the trait `std::convert::From<lodepng::error::Error>` is not implemented for `lodepng::ffi::Error`
   |
   = note: the question mark operation (`?`) implicitly performs a conversion on the error value using the `From` trait
   = help: the following implementations were found:
             <lodepng::ffi::Error as std::convert::From<std::io::Error>>
   = note: required by `std::convert::From::from`

error: aborting due to previous error

For more information about this error, try `rustc --explain E0277`.
error: could not compile `dssim`.

To learn more, run the command again with --verbose.

I cannot test *-msvc since trying to use rust's msvc target will require installing msvc build tools and does not work inside a msys2 shell because cargo tries to use GNU link rather than the one from msvc and it seems installing the 5GB msvc build tools inside a VM doesn't work either since it errors out on LINK : fatal error LNK1181: cannot open input file 'advapi32.lib' from the x64 Native Tools Command Prompt for VS 2019 after setting the proper toolchain.

running cargo build from stable-x86_64-unknown-linux-gnu works fine.

Just logging that version 1.3.1 fixes the munmap_chunk error found in 1.1 (which is latest in ppa:lkwg82/dssim)

n@nathanael-xeon:/Documents/imazen/imageflow$ dssim /home/n/Documents/imazen/imageflow/tests/visuals/000000007E535E4D_000000000FA8D6DC.png /home/n/Documents/imazen/imageflow/tests/visuals/00000000AC6E6E56_000000000FA8D6DC.png
*** Error in `dssim': munmap_chunk(): invalid pointer: 0x000000000201cc80 ***
Aborted (core dumped)
n@nathanael-xeon:/Documents/imazen/imageflow$ pngcheck /home/n/Documents/imazen/imageflow/tests/visuals/000000007E535E4D_000000000FA8D6DC.png
OK: /home/n/Documents/imazen/imageflow/tests/visuals/000000007E535E4D_000000000FA8D6DC.png (700x525, 32-bit RGB+alpha, non-interlaced, 52.7%).
n@nathanael-xeon:/Documents/imazen/imageflow$ pngcheck /home/n/Documents/imazen/imageflow/tests/visuals/00000000AC6E6E56_000000000FA8D6DC.png
OK: /home/n/Documents/imazen/imageflow/tests/visuals/00000000AC6E6E56_000000000FA8D6DC.png (700x525, 32-bit RGB+alpha, non-interlaced, 51.0%).
n@nathanael-xeon:/Documents/imazen/imageflow$ dssim -v
Usage: dssim original.png modified.png [modified.png...]
or: dssim -o difference.png original.png modified.png

Compares first image against subsequent images, and outputs
1/SSIM-1 difference for each of them in order (0 = identical).

Images must have identical size, but may have different gamma & depth.

Version 1.1 http://pornel.net/dssim

The documentation states "The value returned is 1/SSIM-1, where 0 means identical image". However, comparing with an identical image gives a non-zero result, and the absolute value varies by quite a bit depending on the image image, by enough of a factor that high quality compression is closer to the compared input value that that is to zero.

As different metrics (and different compression methods) these examples below can't be very usefully compared. However, note that the two other metrics give a 0 result (and butteraugli a black heatmap) when comparing against the input image.

As the difference images are not black-backed either (they have an edge-detected background of some kind?) this makes comparing outputs of different compression methods less useful than if the metric was either cleaner or perhaps better documented?

Thanks for all your work on this project, has been very useful today for examining different compression options.

Tested successfully on Windows 7 64 bits, compiled with libpng 1.6.3 and zlib 1.2.8.
[EDIT - Better optimization] : http://css-ig.net/tools/zip/dssim.zip

I have ran dssim on the attached images (one of them is a PNG of color type 6, and the other is the same PNG after pngquant).
I have gotten a negative value as the dssim score. These image have an ssim score (using the C++ implementation) of 100, and visually they are identical, so I assume a negative dssim score is equivalent to 0.

Still, this is somewhat confusing, especially when running averages.

Thanks!

I saw issue #41 and as far as I understand it's related to v1 implementation
May be it can be easier now to add this feature

Trying to compile the file:

extern crate dssim;
extern crate imgref;

use dssim::{Dssim, RGBLU};
use imgref::{Img, ImgRef, ImgVec};

fn main() {
    let mut ctx = Dssim::new();
    let im: ImgVec<RGBLU> = Img::new(vec![], 0, 0);
    let imr: ImgRef<RGBLU> = im.as_ref();
    ctx.create_image(&imr);
}

gives me a

error[E0277]: the trait bound `imgref::Img<std::vec::Vec<rgb::RGB<f32>>>: dssim::ToLABBitmap` is not satisfied
  --> src/main.rs:14:9
   |
14 |     ctx.create_image(&imr);
   |         ^^^^^^^^^^^^ the trait `dssim::ToLABBitmap` is not implemented for `imgref::Img<std::vec::Vec<rgb::RGB<f32>>>`
   |
   = help: the following implementations were found:
             <imgref::Img<std::vec::Vec<rgb::RGBA<f32>>> as dssim::ToLABBitmap>
             <imgref::Img<&'a [rgb::RGBA<f32>]> as dssim::ToLABBitmap>
             <imgref::Img<&'a [rgb::RGB<f32>]> as dssim::ToLABBitmap>
             <imgref::Img<std::vec::Vec<f32>> as dssim::ToLABBitmap>

error.

The error message is extremely confusing, but:
The type signature of create_image is essentially

fn create_image<In, Out>(bitmap: &In) -> ...
  where
    In:  ToLABBitmap + Downsample<Output=Out>,
    Out: ToLABBitmap + Downsample<Output=Out>,

ToLABBitmap is implemented for ImgVec<RGBAPLU>, ImgVec<f32>, ImgRef<RGBAPLU> and ImgRef<RGBLU>
But it's not implemented for ImgVec<RGBLU>.

Downsample has Output=ImgVec<RGBLU> for ImgRef<RGBLU>, so providing an ImgRef as the In type in create_image makes Out = ImgVec<RGBLU>, for which ToLABBitmap is unimplemented.

I assume this is unintentional.

I believe the fix should be implementing ToLABBitmap for ImgVec<RGBLU>, (and possibly ImgRef<f32> - those impls are not symmetrical)

As a sidenote, there is no ToRGBLU trait, so working with RGB values is less nice than RGBA values.

It's unclear whether JPEG's are supported by dssim. I'm using this on MacOS and getting this error:

Image modified.jpg has different size than original.jpg

While the site says nothing about supporting JPEGs, only PNGs, there seems to be some anecdotal evidence that it is supported.

Please advise whether JPEGs are supported, and if so, how do I get around this error above?

Hi, how to run it on Windows? I installed libpng(http://gnuwin32.sourceforge.net/packages/libpng.htm) but running the command
dssim file-original.png file-modified.png
the command dssim is not recognized...
How can I solve?

👋 it looks like 3.0.2 is not marked as the latest release? Thanks!

The dssim CLI depends on the load_image crate which in turn relies on multiple *-sys crates. This makes compilation to WebAssembly fail. I am not sure why crate is compiling the CLI when I am only using it as a library, but it is.

Would it be feasible to separate the CLI and library into separate crates? Or maybe another solution is to put the CLI behind a (default-enabled) feature?

Calculating SSIM for lightness and color channels separately seems fishy, since sum of differencs in each channel (3x1D distances) is not the same as difference in 3D RGB or LAB space.