add QOI.jl to read and save the qoi image format

[KristofferC]

Requires QOI.jl to be registered and KristofferC/QOI.jl#2 to be merged

[codecov]

Codecov Report

Merging #354 (b7b09e3) into master (13a22ac) will decrease coverage by 0.84%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #354      +/-   ##
==========================================
- Coverage   88.34%   87.50%   -0.85%     
==========================================
  Files          10       10              
  Lines         695      696       +1     
==========================================
- Hits          614      609       -5     
- Misses         81       87       +6     

Impacted Files	Coverage Δ
src/registry.jl	93.22% <ø> (ø)
src/deprecated.jl	37.50% <0.00%> (-10.42%)	⬇️
src/mimesave.jl	75.00% <0.00%> (-2.78%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 13a22ac...b7b09e3. Read the comment docs.

[johnnychen94]

Love this! I was planning to give it a try during this winter vacation; maybe we can also include it in ImageIO and ship it to all users of Images?

[KristofferC]

Sounds good to me!

[KristofferC]

@johnnychen94 This should be good to go.

[KristofferC]

Or @timholy.

[johnnychen94]

Because this format doesn't have magic numbers (does it?), I think we need to have some tests here to ensure we don't break it in the future. It can be as simple as

FileIO.jl/test/query.jl

Lines 463 to 472 in 13a22ac

	@testset "OpenEXR detection" begin
	q = query(joinpath(file_dir, "rand.exr"))
	@test typeof(q) <: File{format"EXR"}
	@test magic(format"EXR") == UInt8[0x76, 0x2F, 0x31, 0x01]
	open(q) do io
	@test position(io) == 0
	skipmagic(io)
	@test position(io) == 4
	end
	end

---

Curious to ask, how stable do you think the current QOI specification (not QOI.jl implementation) is? This format is quite promising but it seems to me that it's still experimental.

[johnnychen94]

We're trying to make ImageIO a replacement for ImageMagick and make ImageIO the only interface for normal users, would you mind registering this package to ImageIO instead?

An OpenEXR example can be found in JuliaIO/ImageIO.jl#30 and #328.

[KristofferC]

JuliaIO/ImageIO.jl#42, so does this mean it should not be registered in FileIO? I don't immidiately see the benefit of ImageIO over just using FileIO. Should I still have https://github.com/KristofferC/QOI.jl/blob/577645ab3e5930231f4043543d1c622824ceca48/src/QOI.jl#L364-L365 in the package? Should this PR be merged in addition to the ImageIO one, or only ImageIO?

[johnnychen94]

JuliaIO/ImageIO.jl#42, so does this mean it should not be registered in FileIO? I don't immediately see the benefit of ImageIO over just using FileIO.

That's a good question. I'm not sure if my answer satisfies you: the primary goal is to provide an image-related IO toolbox as an alternative to ImageMagick so that when new users come up, we can save the efforts and tell them to ]add ImageIO instead of ]add PNGFiles QOI ....
The latter can sometimes be inconvenient if we have new formats supported. For instance, when QOI.jl is introduced in ImageIO, all ImageIO users automatically get QOI supports.

Should I still have https://github.com/KristofferC/QOI.jl/blob/577645ab3e5930231f4043543d1c622824ceca48/src/QOI.jl#L364-L365 in the package? Should this PR be merged in addition to the ImageIO one, or only ImageIO?

It depends on how you plan to use or advertise QOI.jl:

• If you like the unified ImageIO way then there's no need to register QOI.jl here.
• If you want people to have load("img.qoi") to work with only ]add FileIO QOI, then you can keep registering QOI.jl here.

[KristofferC]

It does have magic numbers (which this PR) adds. The format is done and new changes are not accepted. So the qoi format will stay as it is.

[timholy]

If I'm thinking about this correctly, the issue of "merge here or via ImageIO" isn't something that we have to decide in this PR. If we want to make ImageIO the all-in-one solution, can't we just make QOI a dependency of ImageIO? So that anytime users install ImageIO they get QOI for free?

If that's right, registering it independently here gives people more freedom if they want a more stripped-down experience. I guess the one issue would be the advice that FileIO dispenses: maybe FileIO could recommend ImageIO first and QOI second?

[timholy]

@KristofferC, thanks for implementing this!

[KristofferC]

If we want to make ImageIO the all-in-one solution, can't we just make QOI a dependency of ImageIO? So that anytime users install ImageIO they get QOI for free?

I think this is done in JuliaIO/ImageIO.jl#42.

@johnnychen94, I also think it makes sense to register here so that the normal FileIO interface works as well.

[timholy]

OK to tag 1.12?

[KristofferC]

Good from my p.o.v (the FileIO tests in QOI.jl pass with the master branch). #356 suggests the sixel format should be merged as well before 1.12.