|
Traneptora
|
2024-02-06 09:42:10
|
it doesn't use any of the features in it other than jxll
|
|
|
lonjil
|
2024-02-06 09:42:55
|
well jxlatte just instantly helped me find an issue, so hooray
|
|
2024-02-06 09:43:05
|
images still don't decode, though
|
|
2024-02-06 10:20:29
|
hooray verbose debug djxl is very helpful ```
./lib/jxl/frame_header.cc:404: JXL_FAILURE: non-patch reference frame with invalid crop: 0x0+0+0
```
|
|
2024-02-06 10:24:48
|
though I don't think I understand it ๐ค
|
|
|
_wb_
|
2024-02-06 10:37:24
|
looks like an empty 0x0 frame? I dunno
|
|
|
|
lonjil
|
2024-02-06 10:38:23
|
jxlatte prints width and height as 1024 for both frames, so I'm a bit confused
|
|
2024-02-06 10:39:14
|
presumably those 0 values are derived somewhere, rather than using the ones in the frame header
|
|
2024-02-06 10:41:42
|
and haveCrop is false anyway
|
|
2024-02-06 10:41:50
|
so how can it have an invalid crop?
|
|
|
|
paperboyo
|
2024-02-06 11:09:17
|
Hi. While playing with something else (JXL vs AVIF encoder filesize stability and consistency being affected by noisy images), I found what looks like an anomaly. The image at the top of this page (https://www.theguardian.com/world/2023/dec/12/donald-tusk-second-coming-can-returning-pm-remake-poland) exhibits significant colour tinting (look for neutral gray going brown) when encoded in JXL only. Easiest to illustrate in sqoosh, but I tested latest win binary as well just to make sure. The colour shift is there on all but very highest qualities, isnโt an ICC issue. Now, I know this is a weird and noisy image: this is the point. Nevertheless, no other codec exhibits any shifts like this in this imageโฆ Some internal colourspace by-product? (hope not! hope fixable!)
|
|
|
|
veluca
|
|
lonjil
so how can it have an invalid crop?
|
|
2024-02-06 11:10:00
|
can you share the file?
|
|
|
|
lonjil
|
|
veluca
can you share the file?
|
|
2024-02-06 11:12:10
|
|
|
2024-02-06 11:13:37
|
It's just two frames, each with nothing but a simple Set predictor, and I set kReferenceOnly on the first frame (I also tried a few other combinations of options that didn't make a difference)
|
|
2024-02-06 11:15:26
|
here is what jxlatte says: ```
Permuted TOC: false
TOC Lengths: [7]
Lossless: Possibly
Frame Info:
Encoding: Modular
Type: Reference Only
Size: 1024x1024
Origin: (0, 0)
YCbCr: false
FrameHeader [type=2, encoding=1, flags=0, doYCbCr=false, jpegUpsampling=[[x=0, y=0], [x=0, y=0], [x=0, y=0]], upsampling=1, ecUpsampling=[], groupSizeShift=3, groupDim=1024, lfGroupDim=8192, logGroupDim=10, logLFGroupDim=13, xqmScale=2, bqmScale=2, passes=PassesInfo [numPasses=1, numDS=0, shift=[], downSample=[], lastPass=[]], lfLevel=0, haveCrop=false, origin=[x=0, y=0], width=1024, height=1024, blendingInfo=BlendingInfo [mode=0, alphaChannel=0, clamp=false, source=0], ecBlendingInfo=[], duration=0, timecode=0, isLast=false, saveAsReference=1, saveBeforeCT=false, name=, restorationFilter=RestorationFilter [gab=false, customGab=false, gab1Weights=[0.115169525, 0.115169525, 0.115169525], gab2Weights=[0.061248593, 0.061248593, 0.061248593], epfIterations=0, epfSharpCustom=false, epfSharpLut=[0.0, 0.06571429, 0.13142858, 0.19714287, 0.26285717, 0.32857144, 0.39428574, 0.46], epfWeightCustom=false, epfChannelScale=[40.0, 5.0, 3.5], epfSigmaCustom=false, epfQuantMul=0.46, epfPass0SigmaScale=0.9, epfPass2SigmaScale=6.5, epfBorderSadMul=0.6666667, epfSigmaForModular=1.0, extensions=Extensions [extensionsKey=0]], extensions=Extensions [extensionsKey=0]]
```
|
|
2024-02-06 11:15:37
|
```
Permuted TOC: false
TOC Lengths: [7]
Frame Info:
Encoding: Modular
Type: Regular
Size: 1024x1024
Origin: (0, 0)
YCbCr: false
FrameHeader [type=0, encoding=1, flags=0, doYCbCr=false, jpegUpsampling=[[x=0, y=0], [x=0, y=0], [x=0, y=0]], upsampling=1, ecUpsampling=[], groupSizeShift=3, groupDim=1024, lfGroupDim=8192, logGroupDim=10, logLFGroupDim=13, xqmScale=2, bqmScale=2, passes=PassesInfo [numPasses=1, numDS=0, shift=[], downSample=[1], lastPass=[0]], lfLevel=0, haveCrop=false, origin=[x=0, y=0], width=1024, height=1024, blendingInfo=BlendingInfo [mode=2, alphaChannel=0, clamp=false, source=1], ecBlendingInfo=[], duration=0, timecode=0, isLast=true, saveAsReference=0, saveBeforeCT=false, name=, restorationFilter=RestorationFilter [gab=false, customGab=false, gab1Weights=[0.115169525, 0.115169525, 0.115169525], gab2Weights=[0.061248593, 0.061248593, 0.061248593], epfIterations=0, epfSharpCustom=false, epfSharpLut=[0.0, 0.06571429, 0.13142858, 0.19714287, 0.26285717, 0.32857144, 0.39428574, 0.46], epfWeightCustom=false, epfChannelScale=[40.0, 5.0, 3.5], epfSigmaCustom=false, epfQuantMul=0.46, epfPass0SigmaScale=0.9, epfPass2SigmaScale=6.5, epfBorderSadMul=0.6666667, epfSigmaForModular=1.0, extensions=Extensions [extensionsKey=0]], extensions=Extensions [extensionsKey=0]]
```
|
|
2024-02-06 11:15:55
|
and debug djxl: ```
% ./djxl -v -v -v -v -v --disable_output test.jxl
JPEG XL decoder v0.10.0 74457542 [AVX2,SSE4,SSE2]
Read 33 compressed bytes.
./lib/jxl/frame_header.cc:404: JXL_FAILURE: non-patch reference frame with invalid crop: 0x0+0+0
./lib/jxl/fields.cc:452: JXL_RETURN_IF_ERROR code=1: visitor.Visit(fields)
./lib/jxl/dec_frame.cc:143: JXL_RETURN_IF_ERROR code=1: ReadFrameHeader(br, &frame_header_)
./lib/jxl/decode.cc:1257: invalid frame header
Failed to decode image
DecompressJxlToPackedPixelFile failed
```
|
|
|
|
veluca
|
2024-02-06 11:20:27
|
I think that might actually be a bug
|
|
|
|
lonjil
|
|
|
veluca
|
2024-02-06 11:20:56
|
or maybe not
|
|
2024-02-06 11:20:59
|
let me think about it
|
|
2024-02-06 11:21:22
|
the frame header stuff always confuses me... (I guess I can only blame myself for it :P)
|
|
|
|
lonjil
|
2024-02-06 11:23:16
|
maybe what I should actually be doing is encode all the constraints written in the standard into Prolog, and then ask Prolog whether the combinations of options I'm feeding in are allowed ๐
|
|
|
|
veluca
|
2024-02-06 11:23:23
|
so, save_before_color_transform being `false` is most certainly not what you want
|
|
2024-02-06 11:23:32
|
you can't use the frame for patches otherwise
|
|
|
|
lonjil
|
2024-02-06 11:24:20
|
I figured as much, though it was one of the options I flipped around to see if it would change anything
|
|
|
|
veluca
|
2024-02-06 11:24:44
|
that said, the condition in libjxl is almost certainly incorrect
|
|
|
|
_wb_
|
|
paperboyo
Hi. While playing with something else (JXL vs AVIF encoder filesize stability and consistency being affected by noisy images), I found what looks like an anomaly. The image at the top of this page (https://www.theguardian.com/world/2023/dec/12/donald-tusk-second-coming-can-returning-pm-remake-poland) exhibits significant colour tinting (look for neutral gray going brown) when encoded in JXL only. Easiest to illustrate in sqoosh, but I tested latest win binary as well just to make sure. The colour shift is there on all but very highest qualities, isnโt an ICC issue. Now, I know this is a weird and noisy image: this is the point. Nevertheless, no other codec exhibits any shifts like this in this imageโฆ Some internal colourspace by-product? (hope not! hope fixable!)
|
|
2024-02-06 11:26:53
|
Pinging <@532010383041363969>
|
|
|
veluca
that said, the condition in libjxl is almost certainly incorrect
|
|
2024-02-06 11:28:48
|
Interesting, a libjxl bug, not a spec bug? We need more jxl art to find this stuff ๐
|
|
|
|
veluca
|
|
_wb_
Interesting, a libjxl bug, not a spec bug? We need more jxl art to find this stuff ๐
|
|
2024-02-06 11:29:39
|
https://github.com/libjxl/libjxl/pull/3254 I'm fairly sure...
|
|
|
|
_wb_
|
2024-02-06 11:35:55
|
What is a kReferenceOnly non-patch frame anyway? I didn't know we had that. For frame blending but without making it a layer, semantically? (i.e. not returned when asking for non-coalesced frames)
|
|
|
|
Traneptora
|
2024-02-06 11:36:53
|
spec says the signalling condition is
|
|
2024-02-06 11:36:54
|
> !all_default and (frame_type == kReferenceOnly or (resets_canvas and can_reference))
|
|
2024-02-06 11:36:57
|
for save_before_ct
|
|
2024-02-06 11:37:11
|
so it should be signaled for the first one no matter what
|
|
|
lonjil
I figured as much, though it was one of the options I flipped around to see if it would change anything
|
|
2024-02-06 11:38:45
|
flipping save_before_ct to true should make that not trigger
|
|
|
|
veluca
|
|
_wb_
What is a kReferenceOnly non-patch frame anyway? I didn't know we had that. For frame blending but without making it a layer, semantically? (i.e. not returned when asking for non-coalesced frames)
|
|
2024-02-06 11:38:49
|
that's a very good question and I have no idea
|
|
|
|
Traneptora
|
2024-02-06 11:38:54
|
```cpp
if (!save_before_color_transform &&
(frame_size.xsize < nonserialized_metadata->xsize() ||
frame_size.ysize < nonserialized_metadata->ysize() ||
frame_origin.x0 != 0 || frame_origin.y0 != 0)) {
```
|
|
2024-02-06 11:38:58
|
this is the condition in libjxl
|
|
|
|
veluca
|
2024-02-06 11:39:34
|
yeah the bug here is that if you don't have a custom size, `frame_size.xsize` is 0
|
|
|
|
Traneptora
|
2024-02-06 11:40:03
|
which leads me to believe a "non-patch reference frame" is a frame that is RefOnly but save_before_ct is false
|
|
|
|
veluca
|
|
|
Traneptora
|
2024-02-06 11:40:17
|
i.e. can be used for frame blending, but not for patch blending
|
|
|
|
veluca
|
2024-02-06 11:40:25
|
which I guess you can use to do some blending of some sort
|
|
2024-02-06 11:40:37
|
but only on the full frame, for... reasons?
|
|
|
|
lonjil
|
|
Traneptora
flipping save_before_ct to true should make that not trigger
|
|
2024-02-06 11:41:21
|
I was about to say that I already did that, but I just checked, even though I set save_before_color_transform = true, jxlatte says it isn't set in the file.
|
|
|
|
Traneptora
|
2024-02-06 11:41:38
|
that's interesting
|
|
|
|
lonjil
|
2024-02-06 11:43:11
|
relevant addition I made to jxl_from_tree: ```c++
if (info.frame_type == jxl::kReferenceOnly) {
info.save_as_reference = true;
info.save_before_color_transform = true;
}
```
save_as_reference gets correctly set in the file, but save_before_ct does not.
|
|
|
|
Traneptora
|
2024-02-06 11:43:53
|
jxlatte should be reading the bit correctly
|
|
2024-02-06 11:43:58
|
```java
saveBeforeCT = !allDefault && (type == FrameFlags.REFERENCE_ONLY || fullFrame
&& (type == FrameFlags.REGULAR_FRAME || type == FrameFlags.SKIP_PROGRESSIVE)
&& (duration == 0 || saveAsReference != 0)
&& !isLast && blendingInfo.mode == FrameFlags.BLEND_REPLACE)
? reader.readBool() : false;
```
|
|
2024-02-06 11:44:00
|
this is what I have
|
|
2024-02-06 11:44:09
|
since the frame type is reference only this expression should evaluate to true
|
|
|
|
veluca
|
2024-02-06 11:44:27
|
does the file differ in any way if you change `true` to `false`?
|
|
|
|
lonjil
|
|
|
_wb_
|
|
veluca
but only on the full frame, for... reasons?
|
|
2024-02-06 11:45:50
|
I guess this could be useful if you have something like a static background with moving sprites on them, with no extractable frame (not even a zero-duration one) that has _only_ the background. Pretty exotic use case though.
|
|
|
|
Traneptora
|
2024-02-06 11:45:51
|
so it's likely a writer bug
|
|
2024-02-06 11:46:38
|
```cpp
if (visitor->Conditional(CanBeReferenced() &&
blending_info.mode == BlendMode::kReplace &&
!is_partial_frame &&
(frame_type == FrameType::kRegularFrame ||
frame_type == FrameType::kSkipProgressive))) {
JXL_QUIET_RETURN_IF_ERROR(
visitor->Bool(false, &save_before_color_transform));
} else if (visitor->Conditional(frame_type == FrameType::kReferenceOnly)) {
JXL_QUIET_RETURN_IF_ERROR(
visitor->Bool(true, &save_before_color_transform));
```
|
|
2024-02-06 11:47:15
|
looks like it automatically calculates the value of save_before_color_transform, based on the conditions
|
|
|
|
veluca
|
2024-02-06 11:47:31
|
that should only set the default
|
|
|
|
Traneptora
|
|
|
veluca
|
2024-02-06 11:47:52
|
the more interesting question is if `save_before_color_transform` has the value you'd expect at that point
|
|
|
|
Traneptora
|
2024-02-06 11:48:21
|
possible that it's not being signaled at all
|
|
|
|
veluca
|
2024-02-06 11:48:26
|
and supposedly it should:
```
frame_header->save_before_color_transform =
frame_info.save_before_color_transform;
```
|
|
2024-02-06 11:48:28
|
but, well
|
|
|
|
Traneptora
|
2024-02-06 11:54:27
|
something I find interesting is `frame_type == kReferenceOnly && is_last` is permitted by spec
|
|
2024-02-06 11:54:34
|
although it's very much not useful
|
|
|
|
lonjil
|
2024-02-06 11:54:38
|
I think it may be a bug on my part, one sec
|
|
|
|
Traneptora
|
2024-02-06 11:54:43
|
er, wait
|
|
2024-02-06 11:54:44
|
I lied
|
|
2024-02-06 11:54:46
|
nvm
|
|
2024-02-06 11:55:07
|
it's not signaled if the frame type is not a normal frame
|
|
2024-02-06 11:55:08
|
nvm
|
|
|
|
lonjil
|
|
veluca
and supposedly it should:
```
frame_header->save_before_color_transform =
frame_info.save_before_color_transform;
```
|
|
2024-02-06 11:56:45
|
this is working properly! my apologies
|
|
2024-02-06 11:57:42
|
and as <@853026420792360980> said, this works properly
|
|
|
|
Traneptora
|
2024-02-06 11:58:13
|
what's interesting when you have multiple implementations of these things you can check them against each other
|
|
2024-02-06 11:58:43
|
I realized that in order to make hydrium assemble tiles as patch frames what I'll need to do is have it send a patch bundle with two patches
|
|
2024-02-06 11:59:43
|
the first patch (in order) will be the entire previous frame, with patch blend mode `kReplace`
|
|
2024-02-06 11:59:54
|
the second patch will be blend mode `kNone` with just the relevant tile
|
|
2024-02-07 12:00:05
|
no idea if that will even work with any current decoders
|
|
2024-02-07 12:00:22
|
I'm pretty sure it won't work in jxlatte but I can't really debug unless I produce a file that does that
|
|
2024-02-07 12:01:37
|
it occurred to me, that if I do this, I can actually avoid using a weird MA tree by just encoding 0 residuals everywhere that isn't relevant
|
|
|
|
veluca
|
|
Traneptora
the second patch will be blend mode `kNone` with just the relevant tile
|
|
2024-02-07 12:03:03
|
... I'm not sure if that will do what you would want it to do?
|
|
|
|
Traneptora
|
2024-02-07 12:03:11
|
how not?
|
|
|
|
veluca
|
2024-02-07 12:03:16
|
I don't think you can use patches to poke holes in other patches
|
|
2024-02-07 12:03:30
|
assuming I understood you right
|
|
|
|
Traneptora
|
2024-02-07 12:03:41
|
the problem is that the reference frame is, conceptually, blended on top of the decoded frame
|
|
2024-02-07 12:04:01
|
what I want to do is take a small portion of the decoded frame, and blend it onto the reference frame
|
|
2024-02-07 12:04:26
|
I believe the way I can accomplish this is by blending the *entire* reference frame first with `kReplace`
|
|
2024-02-07 12:04:40
|
then I can send the parts of the decoded frame that I want on top of that with a second `kNone` patch
|
|
|
|
veluca
|
2024-02-07 12:04:44
|
patches are applied sequentially
|
|
|
|
Traneptora
|
2024-02-07 12:04:50
|
ye, so I'd have to do it in that order
|
|
|
|
veluca
|
2024-02-07 12:04:54
|
a kNone patch might as well not exist
|
|
|
|
Traneptora
|
2024-02-07 12:05:25
|
I was under the impression that patch blending happened on a canvas, not on the decoded frame's space
|
|
|
|
veluca
|
2024-02-07 12:05:45
|
(kNone exists to skip some channels)
|
|
|
|
lonjil
|
2024-02-07 12:05:47
|
maybe I misunderstood but can't you blend below with the appropriate PatchBlendMode values?
|
|
|
|
Traneptora
|
2024-02-07 12:06:08
|
I was operating under the assumption that a `kNone` patch can, in principle, be used to overlay parts of the decoded frame back onto the canvas
|
|
2024-02-07 12:06:13
|
after other patches had been applied
|
|
|
|
veluca
|
|
|
Traneptora
|
2024-02-07 12:06:32
|
so the spec suggests otherwise
|
|
|
|
veluca
|
2024-02-07 12:06:44
|
`kBlendBelow` / `kBlendAbove` should possibly allow to do what you want
|
|
|
|
Traneptora
|
|
|
veluca
|
2024-02-07 12:06:50
|
we should probably fix that then
|
|
2024-02-07 12:06:54
|
yes
|
|
2024-02-07 12:07:08
|
it seems to me that that's correct
|
|
2024-02-07 12:07:14
|
"nothing is done" ๐
|
|
|
|
Traneptora
|
2024-02-07 12:07:18
|
it says `sample = old_sample` but that does actually do something if a previous patch was blended in its location
|
|
2024-02-07 12:07:25
|
since they're blended in order
|
|
|
|
veluca
|
2024-02-07 12:07:37
|
if you apply kAdd multiple times, you don't expect just the last patch to be added, no?
|
|
|
|
lonjil
|
2024-02-07 12:08:01
|
wouldn't old_sample be referring to the state of the buffer after the last applied patch?
|
|
|
|
veluca
|
|
lonjil
wouldn't old_sample be referring to the state of the buffer after the last applied patch?
|
|
2024-02-07 12:08:07
|
yes
|
|
|
|
Traneptora
|
2024-02-07 12:08:13
|
that isn't particularly obvious to me
|
|
2024-02-07 12:08:38
|
> After applying restoration filters (Annex J), for i in the range [0, num_patches), for j in the range [0, patch[i].count), and for c in the range [0, num_extra], the decoder blends new_sample, which is patch[i].sample(ix, iy, d) (from K.3.1), on top of old_sample, which is the sample in channel d of the current frame at position (patch[i].x[j] + ix, patch[i].y[j] + iy), to obtain a new sample sample which overwrites old_sample.
|
|
2024-02-07 12:08:56
|
it says in the spec it overwrites old_sample but it isn't particularly clear to me that it overwrites it at each stage of patch application
|
|
|
|
veluca
|
2024-02-07 12:09:03
|
then we need to make it more obvious
|
|
2024-02-07 12:09:14
|
<@794205442175402004>
|
|
2024-02-07 12:09:43
|
having said that, if your objective is to replace everything but a rectangle, you can do that with 4 kReplace patches, no?
|
|
2024-02-07 12:09:58
|
(4 rectangles that cover the complement of the rectangle)
|
|
|
|
Traneptora
|
2024-02-07 12:10:11
|
ye, I could
|
|
2024-02-07 12:10:16
|
or three if it borders the edge
|
|
2024-02-07 12:10:48
|
it accomplishes the same thing, just requires 4 patches instead of two. not a huge overhead tho
|
|
2024-02-07 12:10:57
|
arguably one patch since one patch instance can contain multiple rectangles
|
|
|
|
veluca
|
2024-02-07 12:11:23
|
no, you need 4 patches since they have different source locations
|
|
|
|
Traneptora
|
2024-02-07 12:11:29
|
ah
|
|
2024-02-07 12:11:32
|
ยฏ\_(ใ)_/ยฏ
|
|
2024-02-07 12:11:39
|
i'd be double checking how it's specified anyway
|
|
2024-02-07 12:13:02
|
it looks like `count = 0` is a legal field to encode for a patch
|
|
2024-02-07 12:13:04
|
just not useful
|
|
2024-02-07 12:13:44
|
oh wait nvm
|
|
2024-02-07 12:13:46
|
hm
|
|
2024-02-07 12:14:03
|
wait it looks like each patch has its own x0 and y0 and width and height
|
|
2024-02-07 12:14:45
|
but what do x0 and y0 do?
|
|
2024-02-07 12:15:07
|
|
|
2024-02-07 12:15:11
|
this is what the spec says
|
|
2024-02-07 12:15:16
|
> After applying restoration filters (Annex J), for i in the range [0, num_patches), for j in the range [0, patch[i].count), and for c in the range [0, num_extra], the decoder blends new_sample, which is patch[i].sample(ix, iy, d) (from K.3.1), on top of old_sample, which is the sample in channel d of the current frame at position (patch[i].x[j] + ix, patch[i].y[j] + iy), to obtain a new sample sample which overwrites old_sample. Here d iterates over the three colour channels if c == 0 and refers to the extra channel with index cโ1 otherwise, and ix, iy are iterated between zero and (patch[i].width, patch[i].height) respectively. The sample values new_sample are in the colour space before the inverse colour transforms from L.2, L.3 and L.4 are applied, but after the upsampling from J.2 and K.2.
|
|
2024-02-07 12:15:54
|
`ix` ranges from `[0, patch.width)`
|
|
2024-02-07 12:16:53
|
and the `new_sample` is located at `ix` and `old_sample` is located at `patch.x[j]`
|
|
2024-02-07 12:17:32
|
```c
patch[i].ref = DecodeHybridVarLenUint(1);
patch[i].x0 = DecodeHybridVarLenUint(3);
patch[i].y0 = DecodeHybridVarLenUint(3);
patch[i].width = DecodeHybridVarLenUint(2) + 1;
patch[i].height = DecodeHybridVarLenUint(2) + 1;
patch[i].count = DecodeHybridVarLenUint(7) + 1;
for (j = 0; j < patch[i].count; j++) {
if (j == 0) {
patch[i].x[j] = DecodeHybridVarLenUint(4);
patch[i].y[j] = DecodeHybridVarLenUint(4);
} else {
patch[i].x[j] = UnpackSigned(DecodeHybridVarLenUint(6)) + patch[i].x[j โ 1];
patch[i].y[j] = UnpackSigned(DecodeHybridVarLenUint(6)) + patch[i].y[j โ 1];
}
```
|
|
2024-02-07 12:17:37
|
this is what the spec says about patches decoding
|
|
2024-02-07 12:17:43
|
so `x0` is never actually referenced
|
|
2024-02-07 12:18:45
|
> the decoder blends `new_sample`, which is `patch[i].sample(ix, iy, d)`
can I assume this *should* say:
> the decoder blends `new_sample`, which is `patch[i].sample(patch[i].x0 + ix, patch[i].y0 + iy, d)`
|
|
2024-02-07 12:19:24
|
oh wait
|
|
2024-02-07 12:19:28
|
it does say that
|
|
2024-02-07 12:19:29
|
> sample(x, y, c): the sample from channel c at the position (x, y) within the patch, corresponding to the sample from channel c at the position (x0 + x, y0 + y) in Reference[ref]. All referenced samples are within the bounds of the reference frame.
|
|
2024-02-07 12:19:34
|
it's in the "sample" function def
|
|
2024-02-07 12:19:47
|
I see so it is all specified, I just didn't read it closely
|
|
|
|
lonjil
|
2024-02-07 12:31:29
|
<@179701849576833024> I think something has broken jxl_from_tree. Now that my modifications aren't broken anymore, I noticed that the resulting jxl files are all black and much smaller than they should be. I reverted my changes to the latest git main, and it's still happening. As an example, the Swedish flag I posted earlier in <#824000991891554375> now results in a 20 byte all black file.
|
|
|
|
veluca
|
2024-02-07 12:32:13
|
uhmmmm, that's odd
|
|
2024-02-07 12:32:23
|
(but not impossible, of course)
|
|
2024-02-07 12:32:38
|
can you open an issue? I'll try to give it a look tomorrow
|
|
|
|
lonjil
|
2024-02-07 12:32:43
|
I will
|
|
2024-02-07 01:17:25
|
turns out it was "Update modular efforts to faster settings" that broke it, I found out after a quick bisection
|
|
2024-02-07 01:24:37
|
https://github.com/libjxl/libjxl/issues/3255
|
|
|
|
_wb_
|
2024-02-07 06:34:57
|
Makes sense that this got broken.
|
|
|
|
veluca
|
2024-02-07 08:10:20
|
ah, yes, makes a lot of sense
|
|
2024-02-07 08:10:27
|
should be an easy fix
|
|
|
zex
|
2024-02-07 09:41:49
|
i decided to see the upper limits of what jxl can handle on lossless compression enjoy
|
|
2024-02-07 09:43:58
|
it came from a 545mb png render of gta 5 map down to 271mb
|
|
|
|
veluca
|
2024-02-07 09:57:49
|
with streaming mode I assume?
|
|
|
|
zex
|
2024-02-07 10:03:29
|
nope
|
|
2024-02-07 10:03:48
|
first attempt was not using streaming
|
|
2024-02-07 10:06:14
|
i do believe it was effort 9
|
|
|
|
veluca
|
2024-02-07 10:21:49
|
well e9 has streaming by default since yesterday ๐ but if it was earlier than that.. how much ram did you need? ๐
|
|
2024-02-07 10:22:04
|
(and time...)
|
|
|
|
zex
|
2024-02-07 10:25:42
|
yeah it wasn't default on 090, unfortunately, which means I should run it again on the newest
and yes, being earlier than that, it took about 30 hours and peaked around this much on the commit
|
|
2024-02-07 10:28:03
|
i sorta cheated this by giving it a handful of nvme drives to use as memory
|
|
|
|
veluca
|
2024-02-07 10:33:50
|
the new version should be faster, but it will not compress better
|
|
2024-02-07 10:33:55
|
(at least, most likely)
|
|
|
|
zex
|
2024-02-07 10:37:25
|
even at effort 9?
|
|
|
|
veluca
|
2024-02-07 10:39:17
|
e9 streaming should be slightly worse than e9 non-streaming
|
|
2024-02-07 10:39:28
|
and "new e10" should be the same as "old e9"
|
|
|
|
zex
|
2024-02-07 10:39:37
|
i see
|
|
|
|
veluca
|
2024-02-07 10:40:58
|
but "new e9" should be a lot more parallel, less memory hungry, and still about the same size
|
|
|
|
zex
|
2024-02-07 10:41:18
|
yeah was looking at the end results in the commit with the change
|
|
|
|
veluca
|
2024-02-07 10:41:20
|
I'd expect it should finish the encode in ... about 1h? assuming you have an 8-core cpu
|
|
2024-02-07 10:41:56
|
I started the encode on my laptop, I'm kinda curious
|
|
2024-02-07 10:42:26
|
(`Intel(R) Core(TM) i9-10885H CPU @ 2.40GHz`, so still somewhat reasonable xD)
|
|
|
|
zex
|
2024-02-07 10:42:47
|
the 5800x3d was what handled that above image
|
|
|
|
veluca
|
2024-02-07 10:42:54
|
I do see it's taking about 3gb of ram
|
|
|
zex
the 5800x3d was what handled that above image
|
|
2024-02-07 10:43:13
|
I mean, I could go 7970x on it, but that doesn't feel super representative ๐
|
|
|
|
zex
|
2024-02-07 10:43:24
|
yeah likely not
|
|
|
|
veluca
|
2024-02-07 10:43:56
|
a 10th gen intel is more reasonable
|
|
2024-02-07 10:44:49
|
(I'm also kind of curious what difference the x3d vs normal-x parts make, maybe at some point we could try that out - I happen to have a 5800x on a server)
|
|
|
|
zex
|
2024-02-07 10:44:50
|
i mean once it broke 60gb of memory on the first test it was more just dealing with memory that was likely making it slow rather than comrpession itelf
|
|
|
|
veluca
|
2024-02-07 10:45:02
|
yeah of course
|
|
2024-02-07 10:45:10
|
which is where streaming mode is helpful
|
|
|
|
zex
|
|
veluca
(I'm also kind of curious what difference the x3d vs normal-x parts make, maybe at some point we could try that out - I happen to have a 5800x on a server)
|
|
2024-02-07 10:45:17
|
i would assume nonx3d would perform better
|
|
|
|
veluca
|
2024-02-07 10:45:38
|
hard to say, compression can be quite memory intensive
|
|
|
|
zex
|
2024-02-07 10:52:38
|
ill time this one and run it for a few hours see if its done within 3 hours
|
|
|
|
paperboyo
|
|
paperboyo
Hi. While playing with something else (JXL vs AVIF encoder filesize stability and consistency being affected by noisy images), I found what looks like an anomaly. The image at the top of this page (https://www.theguardian.com/world/2023/dec/12/donald-tusk-second-coming-can-returning-pm-remake-poland) exhibits significant colour tinting (look for neutral gray going brown) when encoded in JXL only. Easiest to illustrate in sqoosh, but I tested latest win binary as well just to make sure. The colour shift is there on all but very highest qualities, isnโt an ICC issue. Now, I know this is a weird and noisy image: this is the point. Nevertheless, no other codec exhibits any shifts like this in this imageโฆ Some internal colourspace by-product? (hope not! hope fixable!)
|
|
2024-02-07 11:32:37
|
So, done some more tests. Again, using Sqoosh (which isnโt perfect with ICC, but in no way does this matter with such a shift). I have created an PNG24, added gaussian blur intensity 200, saved and converted to various formats. I used very low qualities (matched on filesize), because they make it more pronounced, but itโs very much there in sensible qualities too.
|
|
|
paperboyo
So, done some more tests. Again, using Sqoosh (which isnโt perfect with ICC, but in no way does this matter with such a shift). I have created an PNG24, added gaussian blur intensity 200, saved and converted to various formats. I used very low qualities (matched on filesize), because they make it more pronounced, but itโs very much there in sensible qualities too.
|
|
2024-02-07 11:33:09
|
โtis the original pic.
|
|
|
|
lonjil
|
2024-02-07 12:38:57
|
Another bug with jxl_from_tree: https://github.com/libjxl/libjxl/issues/3264
|
|
2024-02-07 12:39:55
|
The commit introducing the problem is 2c61440
> Remove PassesEncoderState parameter from EncodeFrame. (#2989)
>
> The relevant custom structs used in tests and jxl_from_tree are passed via cparams instead.
|
|
|
|
veluca
|
|
zex
ill time this one and run it for a few hours see if its done within 3 hours
|
|
2024-02-07 01:04:21
|
it's done on my laptop, not sure when it finished (will see it when I'm back home)
|
|
2024-02-07 01:07:10
|
```
luca@xps ~ $ ls -l /tmp/*jxl
-rw-r--r-- 1 luca luca 284829815 Feb 7 11:49 /tmp/RKxnwFNC.e9.streaming.jxl
-rw-r--r-- 1 luca luca 284772183 Feb 7 11:34 /tmp/RKxnwFNC.jxl
```
|
|
2024-02-07 01:07:13
|
size is pretty similar
|
|
|
|
_wb_
|
|
paperboyo
So, done some more tests. Again, using Sqoosh (which isnโt perfect with ICC, but in no way does this matter with such a shift). I have created an PNG24, added gaussian blur intensity 200, saved and converted to various formats. I used very low qualities (matched on filesize), because they make it more pronounced, but itโs very much there in sensible qualities too.
|
|
2024-02-07 02:49:13
|
Very interesting, I wonder what is causing this.
Note that your noise is colored, and averaging it in nonlinear RGB is not a perceptually correct way to estimate the perceived color. When I look at the full-screen original and squint my eyes, I'm actually not sure if what I see is really neutral gray
|
|
|
damian101
|
2024-02-07 02:58:59
|
still, a clear perceptual color shift...
|
|
|
|
_wb_
|
2024-02-07 03:04:49
|
yes, I can reproduce on current libjxl, there is indeed a clear color shift. It happens also with epf and gaborish disabled, so that's not it.
|
|
|
Jyrki Alakuijala
|
|
paperboyo
Hi. While playing with something else (JXL vs AVIF encoder filesize stability and consistency being affected by noisy images), I found what looks like an anomaly. The image at the top of this page (https://www.theguardian.com/world/2023/dec/12/donald-tusk-second-coming-can-returning-pm-remake-poland) exhibits significant colour tinting (look for neutral gray going brown) when encoded in JXL only. Easiest to illustrate in sqoosh, but I tested latest win binary as well just to make sure. The colour shift is there on all but very highest qualities, isnโt an ICC issue. Now, I know this is a weird and noisy image: this is the point. Nevertheless, no other codec exhibits any shifts like this in this imageโฆ Some internal colourspace by-product? (hope not! hope fixable!)
|
|
2024-02-07 04:44:13
|
my first guess is that it is in the quantization of the X channel and its rather generous dead zone or its further modulation in the heuristics -- I'll look into this and perhaps shrink it a bit
|
|
|
jonnyawsom3
|
|
zex
even at effort 9?
|
|
2024-02-07 04:56:40
|
As veluca said, the new streaming mode considerably lowers memory usage and increases speed, so you can add more parameters to get lower sizes than non-streaming still with less memory use and time (Hopefully, depends image to image and on the parameters)
|
|
|
|
veluca
|
|
veluca
I started the encode on my laptop, I'm kinda curious
|
|
2024-02-07 07:44:57
|
```
luca@xps ~/libjxl/build ๎ main $ /usr/bin/time ./tools/cjxl -e 9 -d 0 --streaming_input /tmp/RKxnwFNC.ppm /tmp/RKxnwFNC.e9.streaming.jxl
JPEG XL encoder v0.10.0 f9187823 [AVX2,SSE4,SSE2]
Encoding [Modular, lossless, effort: 9]
Compressed to 284829.8 kB (5.001 bpp).
18300 x 24900, 0.712 MP/s [0.71, 0.71], 1 reps, 16 threads.
8832.42user 79.14system 10:40.23elapsed 1391%CPU (0avgtext+0avgdata 3394896maxresident)k
0inputs+0outputs (0major+448343minor)pagefaults 0swaps
```
|
|
2024-02-07 07:45:04
|
not too bad
|
|
2024-02-07 07:45:14
|
3.5gb of memory, 11m of running time
|
|
|
|
Traneptora
|
2024-02-07 07:48:18
|
what is a minor page fault
|
|
|
|
veluca
|
2024-02-07 07:50:56
|
```
%R Number of minor, or recoverable, page faults. These are faults
for pages that are not valid but which have not yet been claimed
by other virtual pages. Thus the data in the page is still
valid but the system tables must be updated.
```
|
|
2024-02-07 07:51:01
|
that's all I know
|
|
|
spider-mario
|
2024-02-07 07:59:53
|
thereโs a wikipedia article https://en.wikipedia.org/wiki/Page_fault
|
|
|
|
Traneptora
|
2024-02-07 08:00:41
|
ah, okay
|
|
2024-02-07 08:00:45
|
so it just means memory is lazily added to the vaddress space
|
|
|
username
|
2024-02-07 08:06:00
|
speaking of page faults here's the count for some of the stuff I have open
|
|
|
|
zex
|
2024-02-07 08:19:03
|
```JPEG XL encoder v0.9.2 41b8cda [AVX2,SSE4,SSSE3,SSE2]
Read 18300x24900 image, 558992205 bytes, 198.8 MP/s
Encoding [Modular, lossless, effort: 9]
Compressed to 285461.4 kB (5.012 bpp).
18300 x 24900, 0.014 MP/s [0.01, 0.01], 1 reps, 16 threads.```
|
|
2024-02-07 08:19:21
|
i fell asleep so i didnt time it accurately but it was over an hour
|
|
|
As veluca said, the new streaming mode considerably lowers memory usage and increases speed, so you can add more parameters to get lower sizes than non-streaming still with less memory use and time (Hopefully, depends image to image and on the parameters)
|
|
2024-02-07 08:20:01
|
This is honestly fine in the end, it was attempting to use 340gb of memory without streaming mode on 090
|
|
|
|
jonnyawsom3
|
|
zex
```JPEG XL encoder v0.9.2 41b8cda [AVX2,SSE4,SSSE3,SSE2]
Read 18300x24900 image, 558992205 bytes, 198.8 MP/s
Encoding [Modular, lossless, effort: 9]
Compressed to 285461.4 kB (5.012 bpp).
18300 x 24900, 0.014 MP/s [0.01, 0.01], 1 reps, 16 threads.```
|
|
2024-02-07 08:21:22
|
I don't think... That was using streaming mode
|
|
|
|
zex
|
2024-02-07 08:21:32
|
i was told it was default on?
|
|
|
|
jonnyawsom3
|
2024-02-07 08:21:46
|
The 0.9.2 was only a patch release, the new defaults are in 0.10 builds
|
|
|
|
zex
|
2024-02-07 08:21:59
|
ah i will need to build that then
|
|
|
|
jonnyawsom3
|
2024-02-07 08:22:58
|
Should be able to get some binaries here for quick testing
<https://github.com/libjxl/libjxl/actions/runs/7817940057#:~:text=by%20humans.txt-,Artifacts,-Produced%20during%20runtime>
|
|
|
|
zex
|
2024-02-07 08:23:10
|
ye was looking for it
|
|
|
|
jonnyawsom3
|
2024-02-07 08:23:48
|
And, there's no streaming PNG decoder yet, only PPM so that may also keep memory usage high
|
|
|
|
zex
|
2024-02-07 08:24:20
|
is it only jxl for streaming mode currently?
|
|
|
|
jonnyawsom3
|
2024-02-07 08:26:59
|
The encoding itself should be streaming for any input file, but unless it's a PPM file, currently it will load the entire image into RAM and convert it to float32 IIRC
|
|
2024-02-07 08:27:38
|
There's been quite a few PRs recently so my info could be out of date
|
|
2024-02-07 08:29:39
|
Still, should be much better than the 0.9.2 release
|
|
|
|
zex
|
2024-02-07 08:30:21
|
going to try ppm in a moment (may take awhile to convert)
|
|
|
|
veluca
|
|
The encoding itself should be streaming for any input file, but unless it's a PPM file, currently it will load the entire image into RAM and convert it to float32 IIRC
|
|
2024-02-07 08:34:11
|
I am not sure it will actually convert to float
|
|
2024-02-07 08:34:22
|
or at least, it doesn't *need* to
|
|
|
|
jonnyawsom3
|
2024-02-07 08:37:52
|
Ahh right, was that for VarDCT only?
|
|
|
Soni
|
2024-02-07 09:40:19
|
can you run jxl in opencl or something?
|
|
2024-02-07 09:45:45
|
idea: we have a 4GB, 3 hours long, 3Mbps twitch VOD of *an xterm window*, 2x upscaled (streaming resolution: 720p, effective resolution: 360p). is it possible to use JXL to bring it down to under 20MB?
|
|
|
|
jonnyawsom3
|
2024-02-07 09:51:46
|
Uhhh, in that specific scenario... I guess maybe JXL could do something? But it would need a lot of work
|
|
|
|
_wb_
|
2024-02-07 09:52:40
|
With an encoder that is integrated in xterm you could do great patches ๐
|
|
2024-02-07 09:52:52
|
But yeah
|
|
|
|
zex
|
|
zex
```JPEG XL encoder v0.9.2 41b8cda [AVX2,SSE4,SSSE3,SSE2]
Read 18300x24900 image, 558992205 bytes, 198.8 MP/s
Encoding [Modular, lossless, effort: 9]
Compressed to 285461.4 kB (5.012 bpp).
18300 x 24900, 0.014 MP/s [0.01, 0.01], 1 reps, 16 threads.```
|
|
2024-02-07 09:53:00
|
i switched to debian due to an error on windows ppm
```time cjxl -e 9 -d 0 --streaming_input GTAV_Webmap_Dawn.ppm GTAV_Webmap_Dawn_streaming.jxl
JPEG XL encoder v0.10.0 0.10.0~alpha20240207161550-0+git197ee92 [AVX2,SSE4,SSE2]
Encoding [Modular, lossless, effort: 9]
Compressed to 284829.9 kB (5.001 bpp).
18300 x 24900, 0.882 MP/s [0.88, 0.88], 1 reps, 16 threads.
real 8m38.083s
user 108m0.384s
sys 0m21.293s```
|
|
2024-02-07 09:53:06
|
massive speed improvements
|
|
|
|
jonnyawsom3
|
2024-02-07 09:53:24
|
Yeah, that's more like it
|
|
|
|
zex
|
2024-02-07 09:53:47
|
windows was not liking the ppm for whatever reason `PNM decoding failed.`
|
|
|
|
jonnyawsom3
|
2024-02-07 09:54:03
|
Huh, there's an issue about that open currently too
|
|
|
|
zex
|
2024-02-07 09:55:08
|
what number?
|
|
|
|
veluca
|
|
Ahh right, was that for VarDCT only?
|
|
2024-02-07 09:56:45
|
vardct converts to float, so does modular, but they don't do it at the whole image *at once*
|
|
|
|
zex
|
2024-02-07 09:56:53
|
also differences of streaming at this scale
284829863 GTAV_Webmap_Dawn_streaming.jxl
285461382 GTAV_Webmap_Dawn.jxl (note: this was on 0.9.0 non streaming input)
|
|
|
|
veluca
|
|
veluca
vardct converts to float, so does modular, but they don't do it at the whole image *at once*
|
|
2024-02-07 09:57:16
|
well, perhaps not xD
|
|
|
|
jonnyawsom3
|
|
zex
what number?
|
|
2024-02-07 09:57:20
|
https://github.com/libjxl/libjxl/issues/3223#issuecomment-1916759810
|
|
|
|
veluca
|
2024-02-07 09:57:24
|
it can be avoided at least
|
|
|
zex
i switched to debian due to an error on windows ppm
```time cjxl -e 9 -d 0 --streaming_input GTAV_Webmap_Dawn.ppm GTAV_Webmap_Dawn_streaming.jxl
JPEG XL encoder v0.10.0 0.10.0~alpha20240207161550-0+git197ee92 [AVX2,SSE4,SSE2]
Encoding [Modular, lossless, effort: 9]
Compressed to 284829.9 kB (5.001 bpp).
18300 x 24900, 0.882 MP/s [0.88, 0.88], 1 reps, 16 threads.
real 8m38.083s
user 108m0.384s
sys 0m21.293s```
|
|
2024-02-07 09:57:56
|
can you attach a PPM that doesn't work on windows?
|
|
2024-02-07 09:58:06
|
ideally not a 1gb one ๐
|
|
|
|
zex
|
2024-02-07 09:58:07
|
its 1.2gb so give me a moment
|
|
2024-02-07 09:58:10
|
oh
|
|
|
|
veluca
|
2024-02-07 09:59:35
|
it is a fair bit suspicious
|
|
2024-02-07 09:59:44
|
<@604964375924834314> would you be able to give it a look?
|
|
|
|
zex
|
2024-02-07 10:00:10
|
ill see if i can make one that isnt a 1+gb file
|
|
2024-02-07 10:08:50
|
im going to guess its always absurdly large images
|
|
2024-02-07 10:12:42
|
actually
|
|
2024-02-07 10:12:47
|
i have a really low size one
|
|
|
|
veluca
|
2024-02-07 10:15:52
|
huh
|
|
2024-02-07 10:15:59
|
the fact that it's windows-only is kinda scary
|
|
|
|
zex
|
|
|
jonnyawsom3
|
2024-02-07 11:23:54
|
Does that encode fine?
|
|
|
Dexrn ZacAttack
|
2024-02-08 02:23:45
|
I see ezgif.com supports JXL
|
|
|
|
Jyrki Alakuijala
|
|
paperboyo
Hi. While playing with something else (JXL vs AVIF encoder filesize stability and consistency being affected by noisy images), I found what looks like an anomaly. The image at the top of this page (https://www.theguardian.com/world/2023/dec/12/donald-tusk-second-coming-can-returning-pm-remake-poland) exhibits significant colour tinting (look for neutral gray going brown) when encoded in JXL only. Easiest to illustrate in sqoosh, but I tested latest win binary as well just to make sure. The colour shift is there on all but very highest qualities, isnโt an ICC issue. Now, I know this is a weird and noisy image: this is the point. Nevertheless, no other codec exhibits any shifts like this in this imageโฆ Some internal colourspace by-product? (hope not! hope fixable!)
|
|
2024-02-08 09:08:47
|
it can be a good question: what is the average color of some noisy colors -- should it be the average amount of photons spectrally weighted, should it be the experience of watching the pixels image at a normal zoom, and then the experience averaged, gamma correction is very different for reds in XYB, Oklab, Lab, ICtCp vs. everything else. And it it also different in XYB vs. Oklab, Lab, and ICtCp, and such a non-linearity affects summation and averaging
some amount of averaging will naturally happen in image compression, more so in the chromacity planes than in the Y/luma plane.
but this is a guess-level response still without looking into the problem more deeply, and I can think of three simple mitigations already...
|
|
2024-02-08 09:17:26
|
I like to think that when spatial averaging is applied, usually we'd like to average the observation/experience instead of averaging the physics of light
|
|
2024-02-08 09:19:13
|
I consider that that is infeasible in the RGB space, and doing it gamma-compressed there will necessarily lead to a result that is neither averaging observation nor physics (but a weird mixture, where red decomposition is mostly physics based, but has a strange non-observation/experience related gamma compression applied to it)
|
|
2024-02-08 09:20:32
|
if someone had a noiseless picture, and artificially added uniform zero-averaging RGB noise into it, it will average to zero with RGB-based computation -- but it will not average to zero when averaged in XYB
|
|
2024-02-08 09:20:48
|
(or Oklab, Lab, ICtCp)
|
|
2024-02-08 09:21:02
|
it could be that this is going on here, but this is pure speculation
|
|
2024-02-08 09:22:52
|
increasing quality will reduce the amount of averaging that is going to happen -- thus it starts to behave better at higher qualities regardless of this discrepancy
|
|
2024-02-08 09:23:06
|
(I didn't look at the image yet) ๐
|
|
|
|
paperboyo
|
|
Jyrki Alakuijala
(I didn't look at the image yet) ๐
|
|
2024-02-08 09:37:10
|
Iโm simple folk, so would also choose experience over physics. Always had poor grades in physics. If something looks grey to me, it should stay grey when I resize or convert. If it looks greenish โ it should stay greenishโฆ
When I squint, the world doesnโt look any more blue (than it already is ;-).
> to behave better
It gives me hope you used the word โbetterโ ๐ .
BTW, there are two images: Tuskโs one that started this and the artificial noise created in Photoshop, both go warmer.
|
|
|
diskorduser
|
|
paperboyo
Iโm simple folk, so would also choose experience over physics. Always had poor grades in physics. If something looks grey to me, it should stay grey when I resize or convert. If it looks greenish โ it should stay greenishโฆ
When I squint, the world doesnโt look any more blue (than it already is ;-).
> to behave better
It gives me hope you used the word โbetterโ ๐ .
BTW, there are two images: Tuskโs one that started this and the artificial noise created in Photoshop, both go warmer.
|
|
2024-02-08 10:34:50
|
did you try converting to jxl with a png source?
|
|
|
|
spider-mario
|
2024-02-08 11:05:38
|
the physics kind of guide the experience, though
|
|
2024-02-08 11:06:15
|
averaging the linear photons is similar to what would happen by bringing the pixels closer together, or putting some frosty glass in front as a physical blurring filter
|
|
2024-02-08 11:07:04
|
(or other sources of blur, such as diffraction)
|
|
|
|
paperboyo
|
|
diskorduser
did you try converting to jxl with a png source?
|
|
2024-02-08 11:07:06
|
Yep, Second (artificial) image above is a lossless PNG source (https://discord.com/channels/794206087879852103/794206170445119489/1204751702427967549).
EDIT: just checked, same problem with 16bit.
|
|
|
|
_wb_
|
2024-02-08 12:02:03
|
<@532010383041363969> consider checking chroma from luma, I can imagine that it might do weird things on such colorful noise
|
|
|
|
Traneptora
|
2024-02-08 05:26:23
|
CFL shouldn't mess witt the X channel iirc
|
|
|
|
_wb_
|
2024-02-08 06:23:39
|
Well it kind of derives/predicts/decorrelates X and B using Y, in a way. Which could cause funky stuff if it uses nonzero multipliers on colorful noise and then quantizes some residuals away...
|
|
|
|
Soni
|
2024-02-09 01:43:06
|
can you implement jxl in gnuradio? it's just digital signal processing right?
|
|
2024-02-09 01:46:43
|
(when you wanna learn gnuradio but it's too hard)
|
|
|
|
lonjil
|
2024-02-09 02:01:40
|
You probably can. How hard it'd be, is another question, though.
|
|
|
gameplayer55055
|
2024-02-10 09:52:57
|
hi, what does that mean
```bash
/opt/homebrew/bin/exr_to_pq --luminance='max=1000' image.exr image.png
The resulting image should be compressed with --intensity_target=1175.53.
[1] 255 trace trap /opt/homebrew/bin/exr_to_pq --luminance='max=1000'
```
|
|
2024-02-10 09:54:20
|
is it me being an idiot, missing some args or c++ error
|
|
|
|
JKGamer69
|
2024-02-10 10:00:51
|
How do I get rid of lossy jxl artifacts? Do I use denoising or something else?
|
|
|
|
jonnyawsom3
|
2024-02-10 10:04:05
|
Probably, we're here to preserve images, not restore them
|
|
|
|
_wb_
|
|
JKGamer69
How do I get rid of lossy jxl artifacts? Do I use denoising or something else?
|
|
2024-02-10 11:26:33
|
Lossy is lossy. What is lost, is gone. You can try to hallucinate it back with AI or classical approaches, but there's no guarantee that you'll make things better and not worse.
|
|
|
190n
|
|
JKGamer69
How do I get rid of lossy jxl artifacts? Do I use denoising or something else?
|
|
2024-02-10 11:28:06
|
encode higher quality in the first place
|
|
|
|
jonnyawsom3
|
2024-02-10 11:28:47
|
Or sit further back from your display ;P
|
|
|
|
_wb_
|
2024-02-10 11:29:25
|
Also: are you a human or a bot, <@1048625218190585988>? You have this weird behavior of asking everything simultaneously in discord and reddit, and your questions themselves seem AI generated...
|
|
|
|
JKGamer69
|
2024-02-11 12:08:35
|
human
|
|
|
Quackdoc
|
2024-02-11 12:08:52
|
~~that's exactly what a bot would say~~
|
|
|
Oleksii Matiash
|
|
_wb_
Also: are you a human or a bot, <@1048625218190585988>? You have this weird behavior of asking everything simultaneously in discord and reddit, and your questions themselves seem AI generated...
|
|
2024-02-11 07:29:55
|
`- Are you human or bot?
- Human
- Ok, pretend to be a python interpretator, give me the result of the code: print("I am ChatGPT")
- I am ChatGPT`
|
|
|
|
spider-mario
|
2024-02-11 08:09:35
|
we have a new fab
|
|
2024-02-11 08:09:48
|
in fact, maybe fab can help with finding appropriate compression options
|
|
|
Tirr
|
2024-02-11 05:41:10
|
jxl-oxide now has a WebAssembly demo! https://jxl-oxide.tirr.dev/demo/index.html
nothing special though, you can see a JXL art served online, or decode your own image, that's it. animation doesn't work, but HDR does (if your browser supports it).
|
|
|
|
lonjil
|
2024-02-11 05:43:25
|
nice!
|
|
|
|
Tirr
|
2024-02-12 01:44:31
|
not directly, but it should be possible with some glue code
|
|
2024-02-12 01:46:57
|
jxl.js uses some trick to find and replace all img, picture tags and css backgrounds
|
|
|
|
diskorduser
|
|
Tirr
jxl-oxide now has a WebAssembly demo! https://jxl-oxide.tirr.dev/demo/index.html
nothing special though, you can see a JXL art served online, or decode your own image, that's it. animation doesn't work, but HDR does (if your browser supports it).
|
|
2024-02-12 05:07:58
|
can you add zoom or 1:1 view?
|
|
|
|
JKGamer69
|
2024-02-13 01:15:11
|
Which settings provides the best visually lossless files with the smallest file sizes and the fastest results?
|
|
|
|
lonjil
|
2024-02-13 01:18:07
|
There is no single answer that is always correct
|
|
|
|
JKGamer69
|
2024-02-13 02:10:50
|
If it's possible, yeah
|
|
|
w
|
2024-02-13 02:33:10
|
that was a rhetorical question
|
|
2024-02-13 02:33:13
|
ai doesnt understand
|
|
|
|
Tirr
|
|
diskorduser
can you add zoom or 1:1 view?
|
|
2024-02-13 03:00:01
|
zoom would need some work, 1:1 view is relatively easy I think. will try
|
|
|
yoochan
|
2024-02-13 08:14:15
|
<@1048625218190585988> -d 0.5 -e 7 is a good compromise
|
|
|
|
_wb_
|
2024-02-13 08:25:27
|
What "visually lossless" actually means depends a LOT on how you define it. It can mean "gets within a 95% confidence interval of the MOS score of the original when doing a subjective experiment according to bt.500 DSIS (side-by-side comparison, 5-point discrete impairment scale)" and then something like libjpeg-turbo q70:420 is often already "visually lossless", or it can mean "passes an AIC-2 flicker test" where you'd need to go to something like libjpeg-turbo q97:444 or so. And of course if you allow zooming and brightening/contrast stretching there is no limit, you need to go to mathematically lossless if you allow arbitrary artifact amplification.
|
|
2024-02-13 08:31:43
|
Exactly because of this rather huge range of qualities where basically bt.500 (and other test protocols suggested in AIC-1) cannot reliably assess images but AIC-2 is too strict (roughly speaking the range from d0.5 to d2.5 in jxl terms, or in libjpeg-turbo terms roughly q70 to q95), I took the initiative in JPEG a while back to start the AIC-3 activity, see also https://jpeg.org/aic/aic3.html
|
|
2024-02-13 08:42:04
|
Because for still images, basically that is the most important range of qualities. Way too much attention has gone in the past to the (very) low end of the quality spectrum, where distortions are severe and side-by-side comparison is a useful methodology. I think the implicit assumption was that if a codec performs well in that range, it will also perform well in the more useful range of qualities. That's a very false assumption though โ some coding tools are more useful at hiding artifacts in the low range, others are better at saving bits when preserving details in the high range, etc. What is needed to be a good codec at d1 (strong entropy coding, fine-grained control over filters, high precision transforms, etc) is very different from what is needed to be a good codec at d8 (aggressive deblocking filters, directional prediction, etc).
|
|
|
|
damian101
|
|
_wb_
What "visually lossless" actually means depends a LOT on how you define it. It can mean "gets within a 95% confidence interval of the MOS score of the original when doing a subjective experiment according to bt.500 DSIS (side-by-side comparison, 5-point discrete impairment scale)" and then something like libjpeg-turbo q70:420 is often already "visually lossless", or it can mean "passes an AIC-2 flicker test" where you'd need to go to something like libjpeg-turbo q97:444 or so. And of course if you allow zooming and brightening/contrast stretching there is no limit, you need to go to mathematically lossless if you allow arbitrary artifact amplification.
|
|
2024-02-13 12:10:58
|
mozjpeg is never visually lossless in my experience, always has subtle ugly blocking
|
|
2024-02-13 12:11:21
|
97 is usually what I go with, though
|
|
|
monad
|
|
JKGamer69
Which settings provides the best visually lossless files with the smallest file sizes and the fastest results?
|
|
2024-02-13 12:28:52
|
-d 0.3 -e 3
|
|
2024-02-13 12:30:27
|
assuming you're still doing film
|
|
|
Demiurge
|
|
JKGamer69
Which settings provides the best visually lossless files with the smallest file sizes and the fastest results?
|
|
2024-02-13 12:32:34
|
Just use the default setting.
|
|
2024-02-13 12:32:56
|
The default lossy setting is d=1
|
|
|
|
monad
|
2024-02-13 12:33:07
|
default is slow and ugly
|
|
|
|
Demiurge
|
2024-02-13 12:33:47
|
Default isn't slow... and if it's ugly they should fix it because it's supposed to be "visually lossless"
|
|
2024-02-13 12:34:36
|
VarDCT effort 7 is decent speed, it's similar speed to lossless effort 3
|
|
2024-02-13 12:35:13
|
The default lossless speed should be changed to e=3
|
|
2024-02-13 12:36:01
|
Lossless e=7 is indeed pretty slow.
|
|
2024-02-13 12:36:23
|
But the vardct mode isnโt.
|
|
|
|
lonjil
|
|
Demiurge
Default isn't slow... and if it's ugly they should fix it because it's supposed to be "visually lossless"
|
|
2024-02-13 12:37:35
|
supposed to be visually lossless at a certain distance from the image and at a certain brightness. Reasonable default but you may want better than that, if, e.g., you're disaplying it big, or very bright, or something or other.
|
|
|
|
Demiurge
|
2024-02-13 12:38:34
|
When it comes to lossy compression, there is seriously bad diminishing returns. For a huge increase in file size you get an extremely small and subtle visual difference.
|
|
2024-02-13 12:39:57
|
If you see a particularly, egregiously ugly example of jpeg xl compression artifacts, please share it with everyone here so the devs are made aware and it gets attention.
|
|
2024-02-13 12:40:13
|
We all want lossy compression to look better and less ugly :)
|
|
|
Nekotekina
|
2024-02-13 01:25:38
|
does lossy cjxl any chroma subsampling? I'm not even sure how to implement jxlinfo output in this regard.
|
|
|
|
Tirr
|
2024-02-13 01:26:21
|
iirc cjxl never does that except jpeg lossless transcoding
|
|
|
|
Nekotekina
|
2024-02-13 01:27:41
|
also is default d=1 good if it's not supposed to be zoomed with magnifier or passing some automated testing?
|
|
|
|
yoochan
|
2024-02-13 01:29:16
|
<@791786694277070899> look at the answer of <@167023260574154752> today 50 min ago : "supposed to be visually lossless at a certain distance from the image and at a certain brightness"
|
|
|
|
Nekotekina
|
2024-02-13 01:29:49
|
I see
|
|
2024-02-13 01:29:57
|
that's a bit tricky definition
|
|
|
|
Tirr
|
2024-02-13 01:30:20
|
I understand d as "visually lossless when zoomed out `d` times"
|
|
2024-02-13 01:30:37
|
not sure this is correct by any means
|
|
|
|
monad
|
|
Nekotekina
that's a bit tricky definition
|
|
2024-02-13 01:38:34
|
"Distance 1 is supposed to be 1 JND unit when viewed at ~1000 pixels distance and on a 200 nits or so display in normal indoors conditions." https://discord.com/channels/794206087879852103/804324493420920833/1204106194294149130
|
|
|
|
lonjil
|
|
Nekotekina
that's a bit tricky definition
|
|
2024-02-13 01:38:43
|
Basically, I think it's something like, if you display the image at 100% zoom, and then have your head a distance from the screen equal to how long a 1000 pixel on the line would be, it should look good at d=1. More zoomed in, or if you're sitting close to a large monitor, you need a higher quality setting (lower d).
For the brightness, this is because it assumes that things that are very dark are harder to see, and so can be compressed more. Probably don't need to worry about this. The defaults should be correct for a regular PC screen in regular indoor lighting conditions. For viewing on a bright HDR screen while in a dark room, it's more important.
|
|
2024-02-13 01:39:00
|
oh, I got ninja'd by a much more direct answer
|
|
|
|
monad
|
|
monad
"Distance 1 is supposed to be 1 JND unit when viewed at ~1000 pixels distance and on a 200 nits or so display in normal indoors conditions." https://discord.com/channels/794206087879852103/804324493420920833/1204106194294149130
|
|
2024-02-13 01:39:29
|
JND = Just noticeable difference.
|
|
|
|
Nekotekina
|
2024-02-13 01:40:01
|
okay thank you
|
|
|
|
monad
|
2024-02-13 01:42:16
|
But, IMO, this has not been maintained in libjxl very well, the scale has shifted so d1 is worse than expected.
|
|
|
|
spider-mario
|
|
Tirr
not sure this is correct by any means
|
|
2024-02-13 02:19:19
|
I would advise not interpreting it in that way
|
|
2024-02-13 02:19:39
|
no effort has been made towards making that a coherent interpretation of it
|
|
2024-02-13 02:20:20
|
if it works at all (which I doubt), it would be incidental
|
|
|
|
yoochan
|
2024-02-13 02:21:17
|
you could have a guy, named henry, with a perfect 1.0 at each eyes which is used as a standard (like in metrology for the kilogram or the meter... you would have henry)
|
|
|
|
spider-mario
|
2024-02-13 02:21:54
|
it could also be a Finnish guy with a name starting with โJโ
|
|
2024-02-13 02:22:05
|
(totally random example)
|
|
|
|
yoochan
|
2024-02-13 02:22:47
|
would he agree to be stored under standard conditions of pressure and temperature ?
|
|
|
|
_wb_
|
|
monad
"Distance 1 is supposed to be 1 JND unit when viewed at ~1000 pixels distance and on a 200 nits or so display in normal indoors conditions." https://discord.com/channels/794206087879852103/804324493420920833/1204106194294149130
|
|
2024-02-13 02:26:12
|
this is more or less what it is supposed to be, where 1 JND means 50% of the people can notice a difference. Of course not all people have the same eyes and some can spot differences more easily than others...
|
|
|
|
damian101
|
|
monad
But, IMO, this has not been maintained in libjxl very well, the scale has shifted so d1 is worse than expected.
|
|
2024-02-13 02:33:05
|
this has changed recently again
|
|
|
|
yoochan
|
2024-02-13 02:34:16
|
JND = Jyrki canNot Distinguish
|
|
|
|
_wb_
|
2024-02-13 02:35:51
|
and yes, in libjxl we have shifted away a bit from using butteraugli maxnorm as the main thing to tune for (though it's still used at e8/e9 iirc), which is the metric that is supposed to predict "can you spot a difference anywhere?" (i.e. the score gets completely determined by the very worst part of the image) โ and instead moved to butteraugli 3-norm, which correlates better with MOS (all regions of the image have impact on the score, though it's still penalizing the worst parts harder than what a simple average, i.e. the 1-norm, would do)
|
|
2024-02-13 02:40:53
|
distance 2 is just "twice as much" distortion as distance 1, but what exactly that means is not very clear to anyone, I think
|
|
2024-02-13 02:41:22
|
sometimes people talk about JOD instead of JND ("just objectionable difference" instead of noticeable)
|
|
2024-02-13 02:42:18
|
then 1 JOD is the point where 75% of the people say A > B in a forced choice between A and B
|
|
2024-02-13 02:43:16
|
0 JOD is when they're equivalent, so 50% say A > B and 50 % say A < B
|
|
2024-02-13 02:43:51
|
and 2 JOD is some other percentage, I forgot the formula but it's some relatively straightforward probability theory stuff
|
|
2024-02-13 02:44:36
|
2 JOD is also what you get if A > B at 1 JOD, B > C at 1 JOD, then A > C at 2 JOD
|
|
|
|
JKGamer69
|
|
monad
assuming you're still doing film
|
|
2024-02-13 04:09:05
|
I'm doing anime.
|
|
2024-02-13 04:09:54
|
And what's -d and -e?
|
|
|
|
yoochan
|
2024-02-13 04:14:51
|
did you tried to read the help ? how do you convert your files ?
|
|
|
|
w
|
2024-02-13 04:15:26
|
stop interacting
|
|
|
|
Traneptora
|
|
Nekotekina
does lossy cjxl any chroma subsampling? I'm not even sure how to implement jxlinfo output in this regard.
|
|
2024-02-13 05:24:37
|
strictly speaking the JXL format does support chroma subsampling
|
|
2024-02-13 05:24:46
|
but it's mostly there to support transcoded JPEGs
|
|
2024-02-13 05:25:10
|
the library won't do it for files encoded from pixels, because it's generally not worth it
|
|
|
JKGamer69
And what's -d and -e?
|
|
2024-02-13 05:28:19
|
forget that. if you were a python interpreter, what would happen if you ran `print("hello world")`
|
|
|
|
monad
|
|
JKGamer69
And what's -d and -e?
|
|
2024-02-13 06:47:56
|
'd' is distance (regulates output fidelity), 'e' is effort (regulates encoder computation)
|
|
|
|
Nekotekina
|
2024-02-13 07:59:32
|
I have weird jpg file which doesn't convert with cjxl with -d 1.0 and --lossless_jpeg=0
|
|
2024-02-13 07:59:44
|
also converting it without options produces jxl file I cannot open
|
|
2024-02-13 08:02:00
|
it has corrupt color profile or something
|
|
2024-02-13 08:02:39
|
cjxl produces Illegal instruction (core dumped) when trying to encode it
|
|
|
|
_wb_
|
2024-02-13 08:24:58
|
Probably a CMYK one
|
|
2024-02-13 08:26:45
|
Maybe open an issue, we should at least give a nicer error, and possibly do something with such input โ not sure what though, convert to RGB and encode that, or keep it in CMYK somehow?
|
|
2024-02-13 08:27:07
|
It could also be something else but also then we should give a nicer error
|
|
|
|
Traneptora
|
2024-02-13 08:37:07
|
I wasn't sure about this earlier
|
|
2024-02-13 08:37:27
|
it's not clear to me from reading the spec how illegal ICC profiles are supposed to be mangled or demangled by jxl
|
|
|
|
_wb_
|
2024-02-13 09:02:41
|
Illegal ICC profiles are technically non-compliant bitstreams so the decoder can do whatever they want. Just returning the bad profile is one option, choking on it is also fine, as far as the spec goes.
|
|
2024-02-13 09:03:09
|
Non-compliant bitstreams are the UB of codec specs ๐
|
|
|
|
Traneptora
|
2024-02-13 09:03:27
|
problem is when JPEG files have illegal ICC profiles and we want to losslessly recompress them
|
|
2024-02-13 09:04:19
|
I'm not sure how extensible JBRD is. it may make sense to copy illegal profiles into JBRD for that purpose
|
|
|
|
_wb_
|
2024-02-13 09:05:24
|
You can store illegal profiles in the codestream, it's just not a compliant file, just like the original jpeg was not really compliant
|
|
|
|
Traneptora
|
2024-02-13 09:05:40
|
sure, but those are real jpegs that exist in the wild
|
|
|
_wb_
You can store illegal profiles in the codestream, it's just not a compliant file, just like the original jpeg was not really compliant
|
|
2024-02-13 09:06:04
|
iirc the icc-mangling is not guaranteed to be invertible for illegal profiles
|
|
|
|
_wb_
|
2024-02-13 09:06:12
|
I think it is
|
|
2024-02-13 09:06:32
|
It is supposed to be able to compress arbitrary stuff
|
|
2024-02-13 09:06:49
|
Because we don't know what future versions of ICC will bring
|
|
|
|
Traneptora
|
2024-02-13 09:07:05
|
https://github.com/libjxl/libjxl/issues/3131
|
|
2024-02-13 09:07:23
|
here's a real life example of a jpeg file that fails to decode after cjxl to jxl
|
|
2024-02-13 09:07:47
|
theoretically an invalid ICC profile should be inverted by the mangling and then just attached to a PNG
|
|
2024-02-13 09:07:54
|
and then the PNG renderer can handle it if they'd like
|
|
|
|
_wb_
|
2024-02-13 09:08:39
|
Yes we need to check where things are going wrong there
|
|
2024-02-13 09:15:39
|
Clearly the current behavior is not acceptable, anything cjxl produces should be decodable by djxl, even if it's a bit of an edge case where cjxl is producing technically non-compliant output (which is arguably something it shouldn't do in the first place; it should probably at least warn and maybe even refuse, or require an extra parameter)
|
|
|
|
Traneptora
|
2024-02-13 09:16:28
|
ye, the current behavior is producing invalid jxl files with no warning and exiting with success
|
|
2024-02-13 09:16:34
|
which is not ideal
|
|
2024-02-13 09:35:41
|
in either case, i sent my exif rework to the ffmpeg ML
|
|
2024-02-13 09:35:54
|
once it gets merged, I'll be able to modify the libjxl wrapper to read/write exif metadata as well
|
|
|
|
Nekotekina
|
|
_wb_
Probably a CMYK one
|
|
2024-02-13 09:53:59
|
Profile Description : Japan Color 2001 Coated
|
|
2024-02-13 09:56:29
|
no idea, would be nice to convert it to something that just displays as original jpeg does
|
|
2024-02-13 09:57:07
|
(but then image viewers just ignore it or something?)
|
|
|
Traneptora
problem is when JPEG files have illegal ICC profiles and we want to losslessly recompress them
|
|
2024-02-13 09:58:10
|
what should I do if I just want to re-encode jpeg and don't care about profiles?
|
|
|
|
Traneptora
|
|
Nekotekina
what should I do if I just want to re-encode jpeg and don't care about profiles?
|
|
2024-02-13 09:58:46
|
you can strip the ICC profile with jpegtran, and then re-encode it after that
|
|
2024-02-13 09:59:06
|
normally I'd advise against stripping ICC profiles, but in the case where they're illegal there's not much you can do
|
|
|
Nekotekina
what should I do if I just want to re-encode jpeg and don't care about profiles?
|
|
2024-02-13 09:59:57
|
more specifically, you can use `jpegtran -copy none input.jpg >output.jpg` and it will copy absolutely no metadata. no ICC, no exif, nothing.
|
|
|
|
Nekotekina
|
2024-02-13 10:00:40
|
hmm what will happen if I do it to other files with possibly correct profiles?
|
|
|
|
Traneptora
|
2024-02-13 10:00:50
|
if the ICC profile is correct, it'll strip that too
|
|
|
|
Nekotekina
|
2024-02-13 10:01:21
|
yeah but what difference it could make in this case?
|
|
|
|
Traneptora
|
2024-02-13 10:01:30
|
if you strip a valid ICC profile you destroy color information
|
|
2024-02-13 10:01:44
|
basically, there's more to color than just "RGB"
|
|
2024-02-13 10:01:55
|
ICC profiles tell the viewer how to interpret the RGB for the screen
|
|
2024-02-13 10:02:53
|
consequences could be anything from
- none, if the profile describes sRGB
- incorrect colors if the profile describes something else (e.g. adobe RGB)
- major color mangling (e.g. if the profile is XYB or similar)
|
|
2024-02-13 10:03:07
|
I'd strong recommend against stripping the ICC profile unless it's invalid
|
|
2024-02-13 10:03:29
|
FWIW, you can check to see if it's invalid by doing `jpgicc input.jpg /dev/null`
|
|
2024-02-13 10:03:35
|
this command will fail if the ICC profile is invalid
|
|
|
|
Nekotekina
|
2024-02-13 10:03:48
|
hmm let me try
|
|
2024-02-13 10:04:59
|
[jpgicc fatal error]: Input profile is not operating in proper color space
|
|
|
|
Traneptora
|
2024-02-13 10:06:09
|
that means the input ICC is invalid
|
|
|
|
Nekotekina
|
2024-02-13 10:08:21
|
jpegtran produced significantly smaller file though
|
|
|
|
Traneptora
|
2024-02-13 10:08:34
|
that's likely because it optimizes the JPEG by default
|
|
|
|
Nekotekina
|
|
|
Traneptora
|
2024-02-13 10:08:59
|
but if you want an example of why not to strip ICC profiles:
|
|
2024-02-13 10:09:05
|
|
|
2024-02-13 10:09:08
|
Here's a JPEG image
|
|
2024-02-13 10:09:19
|
if you see hot pink, that means the viewer is ignoring the ICC Profile
|
|
2024-02-13 10:09:23
|
discord will do this
|
|
2024-02-13 10:09:35
|
try opening the image in your web browser, and it will look correct
|
|
|
|
Nekotekina
|
2024-02-13 10:09:45
|
oh I see
|
|
|
|
Traneptora
|
2024-02-13 10:10:15
|
discord strips the ICC profile for its preview image, which causes the colors to be wrong
|
|
2024-02-13 10:10:25
|
granted, this is an extreme example, but it can measurably change the colors
|
|
|
|
Nekotekina
|
2024-02-13 10:14:45
|
jpegtran looks very useful, it also fixed another issue with weird jpeg file that refused to open
|
|
2024-02-13 10:22:49
|
just need to not forget -copy icc in that case
|
|
|
|
_wb_
|
|
Nekotekina
Profile Description : Japan Color 2001 Coated
|
|
2024-02-13 10:28:59
|
Yeah anything coated or uncoated looks like a CMYK profile. So it's a 4-channel JPEG, and jxl cannot losslessly recompress that in a way that reconstructs the JPEG (jxl's VarDCT is limited to 3 channels).
|
|
2024-02-13 10:30:14
|
We could convert to RGB and encode that, in principle, or even do the CMY losslessly as DCT and encode the K as pixels. But I guess it's currently just refusing to do anything with these...
|
|
|
|
lonjil
|
2024-02-13 10:30:48
|
oh yeah, how come you never defined a 4-channel VarDCT mode?
|
|
|
|
Nekotekina
|
2024-02-13 10:32:11
|
pretty sure it was normal rgb jpeg with incorrect profile
|
|
|
|
_wb_
|
2024-02-13 10:33:56
|
That's also possible but kind of weird
|
|
|
|
Traneptora
|
|
lonjil
oh yeah, how come you never defined a 4-channel VarDCT mode?
|
|
2024-02-13 10:35:10
|
A lot of VarDCT stuff is heavily linked with XYB
|
|
2024-02-13 10:35:35
|
ie works with nonXYB but it's not ideal
|
|
2024-02-13 10:35:56
|
It could have been done but you end up with some edge cases
|
|
|
|
_wb_
|
|
lonjil
oh yeah, how come you never defined a 4-channel VarDCT mode?
|
|
2024-02-13 10:36:03
|
Hardcoding for 3 channels has the advantage that you only need one code path, only one case for chroma from luma etc. DCT makes the most sense for visual stuff which is inherently 3 channels since humans have 3 cone types.
|
|
2024-02-13 10:37:06
|
For things like alpha and the K channel of CMYK, it doesn't really make sense to use the DCT, so we figured it would make more sense to do any channels other than the 3 color channels with modular.
|
|
|
|
Nekotekina
|
2024-02-13 10:37:28
|
Is it possible to encode lossy modular or lossless VarDCT?
|
|
|
|
_wb_
|
2024-02-13 10:37:48
|
Lossy modular is possible, lossless VarDCT is not.
|
|
2024-02-13 10:38:27
|
But you can do the color channels with modular too, that's jxl's lossless mode.
|
|
2024-02-13 10:42:41
|
We didn't try to be exhaustive in the kinds of jpegs we wanted to be representable in jxl. Just the common kinds (1 or 3 channels, 8-bit, Huffman coding, chroma subsampling 444, 422, 420, 440) cover 99.something % of the JPEGs found in the wild and we considered that good enough. Doing anything more would introduce extra spec complications just to accommodate it, so we went for a balance between keeping it simple and being useful. I think we reached a good trade-off.
|
|
2024-02-13 10:45:23
|
The full JPEG spec also has arithmetic coding, 12-bit, lossless, hierarchical mode, weird subsamplings (factors of 3 or 4), etc etc. Many JPEG decoders don't implement that stuff anyway, so we considered it not that important.
|
|
|
|
lonjil
|
|
_wb_
Hardcoding for 3 channels has the advantage that you only need one code path, only one case for chroma from luma etc. DCT makes the most sense for visual stuff which is inherently 3 channels since humans have 3 cone types.
|
|
2024-02-13 10:46:48
|
kinda annoying that, due to the redundancy, the encoder could put all sorts of stuff in the K channel, from very not-DCT-y stuff to basically a grayscale photo. I haven't looked at enough CMYK images to know what encoders do in practice.
|
|
|
|
_wb_
|
2024-02-13 10:50:02
|
Often text is done as K-only and photos have some K in the dark parts where it would take too much ink to do it with CMY alone.
|
|
2024-02-13 10:52:38
|
But generally I think it's a bit of an application layer mismatch to do CMYK at the image representation level. An image could just be an RGB image in a sufficiently wide gamut space, and leave it to printers to decide how they want to reproduce that in a good way. It all feels like a bit of a relic of the past when color spaces were still mostly implicit and ill-defined.
|
|
2024-02-13 10:56:36
|
Some printers use a 7-color process, CMYKOGV (with additional inks for orange, green, violet). That's all good but I don't think we should be making 7-channel images, just make them RGB in a sufficiently wide gamut and let the printer figure out what inks to use to reproduce it as accurately as possible.
|
|
|
|
lonjil
|
|
_wb_
But generally I think it's a bit of an application layer mismatch to do CMYK at the image representation level. An image could just be an RGB image in a sufficiently wide gamut space, and leave it to printers to decide how they want to reproduce that in a good way. It all feels like a bit of a relic of the past when color spaces were still mostly implicit and ill-defined.
|
|
2024-02-13 10:58:41
|
in practice, I reckon a lot of work is done in RGB and then at the end they just "convert" to CMYK so that the people who care about things being CMYK will be happy.
|
|
|
|
Nekotekina
|
2024-02-13 10:59:33
|
what if someone wants to affect printing color channels directly?
|
|
|
|
_wb_
|
2024-02-13 10:59:37
|
If you really want to, you can store 7-channel images in jxl, but this would be more something for internal workflows in sending data to an actual printer than something you'd want to do in an interchange format.
|
|
2024-02-13 11:01:29
|
Basically we figured that only having modular for that kind of thing (so lossless or non-dct lossy) is good enough, since why would you want to introduce dct artifacts at those points...
|
|
|
CrushedAsian255
|
2024-02-14 12:38:10
|
just wondering why does `cjxl` not support BMP images?
|
|
|
|
damian101
|
2024-02-14 12:41:58
|
It doesn't even support JXL...
|
|
|
|
CrushedAsian255
|
2024-02-14 12:42:11
|
it does in the `0.9.1` update for me
|
|
|
|
damian101
|
2024-02-14 12:42:16
|
oh, cool
|
|
|
|
CrushedAsian255
|
2024-02-14 12:42:42
|
although what would you need to re-encode JXL to itself for?
|
|
|
|
damian101
|
2024-02-14 12:42:52
|
does it support tiff, btw? many people would probably find that useful
|
|
|
|
CrushedAsian255
|
2024-02-14 12:43:07
|
my version supports
``` the input can be PNG, APNG, GIF, JPEG, EXR, PPM, PFM, PAM, PGX, or JXL```
|
|
|
|
damian101
|
|
CrushedAsian255
although what would you need to re-encode JXL to itself for?
|
|
2024-02-14 12:43:11
|
make existing JXL smaller
|
|
2024-02-14 12:44:48
|
I personally would like it if WebP was supported, at least the lossless version, as I use that for screenshots and stuff.
|
|
|
|
CrushedAsian255
|
|
make existing JXL smaller
|
|
2024-02-14 12:44:59
|
what like `cjxl test.jxl smaller.jxl -d 2`?
|
|
|
|
damian101
|
|
CrushedAsian255
what like `cjxl test.jxl smaller.jxl -d 2`?
|
|
2024-02-14 12:45:14
|
yes, for example
|
|
2024-02-14 12:45:51
|
and source JXL might even be lossless
|
|
|
|
CrushedAsian255
|
2024-02-14 12:47:05
|
i think PPM PFM and PAM are the same format that store uncompressed images in a weird text based format
[wikipedia](https://en.wikipedia.org/wiki/Netpbm)
|
|
|
|
username
|
|
I personally would like it if WebP was supported, at least the lossless version, as I use that for screenshots and stuff.
|
|
2024-02-14 12:48:55
|
libwebp is small enough that adding it to the tools for decoding shouldn't be much of a detriment to compile times or binary size
|
|
|
|
CrushedAsian255
|
2024-02-14 12:49:26
|
and wouldn't BMP be like 50 lines of code?
|
|
|
|
username
|
|
CrushedAsian255
and wouldn't BMP be like 50 lines of code?
|
|
2024-02-14 12:51:16
|
BMP is a little more complex since iirc it doesn't really have a spec and there's a bunch of weird versions of it.
take for example this Firefox decoding bug that was fixed 18 years after it was reported: https://bugzilla.mozilla.org/show_bug.cgi?id=327074
|
|
|
|
CrushedAsian255
|
|
username
BMP is a little more complex since iirc it doesn't really have a spec and there's a bunch of weird versions of it.
take for example this Firefox decoding bug that was fixed 18 years after it was reported: https://bugzilla.mozilla.org/show_bug.cgi?id=327074
|
|
2024-02-14 12:53:07
|
since when did BMP support anything other than raw uncompressed?????
|
|
2024-02-14 12:53:36
|
i thought it was just raw?
|
|
|
HCrikki
|
|
|
CrushedAsian255
|
2024-02-14 12:54:51
|
oh that makes sense given the time period
|
|
2024-02-14 12:55:07
|
i think if you want raw-only images the ppm thing seems like it's interesting
|
|
|
|
HCrikki
|
2024-02-14 12:55:22
|
theres some high definition version of bmp with ultraniche specifications microsoft supposedly extended support for in windows despite common sense
|
|
|
|
afed
|
|
|
damian101
|
|
username
libwebp is small enough that adding it to the tools for decoding shouldn't be much of a detriment to compile times or binary size
|
|
2024-02-14 12:56:36
|
Cool. Makes sense, it's not even full VP8 afterall, which itself is quite rudimentary... Plus the excellent lossless mode of course, but lossless is never very complex.
|
|
|
|
CrushedAsian255
|
2024-02-14 01:01:10
|
is libjxl optimised for arm chips?
|
|
|
|
jonnyawsom3
|
|
_wb_
Maybe open an issue, we should at least give a nicer error, and possibly do something with such input โ not sure what though, convert to RGB and encode that, or keep it in CMYK somehow?
|
|
2024-02-14 01:56:31
|
What about storing the K channel as a lossless greyscale modular channel? Since it *should* be all black or white anyway
|
|
|
|
190n
|
|
CrushedAsian255
is libjxl optimised for arm chips?
|
|
2024-02-14 02:06:18
|
it uses [highway](https://github.com/google/highway) for portable SIMD operations, and highway supports ARM's NEON extension, so i think at least somewhat
|
|
2024-02-14 02:06:34
|
outside highway, i'm not sure if libjxl has handwritten assembly for any ISA
|
|
|
|
afed
|
2024-02-14 02:32:37
|
for fjxl/e1 at least
|
|
|
|
Traneptora
|
|
What about storing the K channel as a lossless greyscale modular channel? Since it *should* be all black or white anyway
|
|
2024-02-14 04:40:06
|
K is an extra channel so it uses modular
|
|
2024-02-14 04:40:10
|
so yes it could be lossless
|
|
|
|
jonnyawsom3
|
2024-02-14 04:42:09
|
Although, then the DCT coeffiencts would need to be stored as metadata for an original file reconstruction
|
|
|
|
_wb_
|
|
What about storing the K channel as a lossless greyscale modular channel? Since it *should* be all black or white anyway
|
|
2024-02-14 05:12:58
|
Yes, that is how it is supposed to be done, we defined an extra channel type just for that.
|
|
|
Although, then the DCT coeffiencts would need to be stored as metadata for an original file reconstruction
|
|
2024-02-14 05:14:01
|
Yep, this is what we don't have, and I think it's a bit too niche to bother with.
|
|
|
|
jonnyawsom3
|
2024-02-14 05:46:16
|
At least if enough people request it, the possibility is there
|
|
|
|
_wb_
|
2024-02-14 06:51:30
|
Sure. More importantly though imo is getting lossless CMYK pixels to work properly and display correctly out of the box.
|
|
|
|
jonnyawsom3
|
2024-02-14 07:39:19
|
Yeah, not much point in converting a CMYK jpeg if CMYK JXL can't be displayed properly
|
|
|
|
Oleksii Matiash
|
2024-02-14 08:09:56
|
I missed discussion\explanation, unfortunatelly, so could anybody briefly explain how lossy modular behaves in terms of artefacts? I mean - DCT produces blockiness and ringing, and what does lossy modular?
|
|
|
|
yoochan
|
2024-02-14 08:18:20
|
one way to make an idea could be to encode losslessly a file, truncate one third at the end of the result and open it again (or convert it back to png) ๐
|
|
|
|
Oleksii Matiash
|
2024-02-14 08:19:16
|
๐ค
|
|
2024-02-14 08:19:22
|
Nice idea, btw
|
|
|
|
jonnyawsom3
|
2024-02-14 08:22:21
|
Similar idea, but here's a video Tiir made of progressive lossless loading. Should show the artefacts pretty well
https://cdn.discordapp.com/attachments/1065165415598272582/1167115136784416778/minecraft-prog.mp4?ex=65d7612c&is=65c4ec2c&hm=f7ba4db2c5e63bbfeb5bc55255fc781c11a2c7801e42ef9dc17914c82f5331fe&
|
|
2024-02-14 08:23:04
|
Blurryness and color bleeding I'd say
|
|
2024-02-14 08:23:25
|
Although the blurryness is just part of progressive loading
|
|
|
|
Oleksii Matiash
|
2024-02-14 08:36:07
|
Well, no, truncating gave me this
|
|
|
yurume
|
2024-02-14 08:36:33
|
that greatly depends on the actual image dimension FYI.
|
|
|
|
Tirr
|
2024-02-14 08:37:51
|
progressively loading lossless with palette transform produces kinda weird result, presumably because samples goes negative while loading and that triggers delta palette
|
|
|
|
yoochan
|
|
Oleksii Matiash
Well, no, truncating gave me this
|
|
2024-02-14 08:42:56
|
not exactly what I expected ๐
|
|
|
|
Tirr
|
2024-02-14 08:48:11
|
well maybe I have XYB progressive modular animation somewhere in jxl-oxide thread...
|
|
2024-02-14 08:53:48
|
not sure those can be called artifacts of *lossy* modular, since encoders can do more than zeroing out residuals
|
|
|
|
Oleksii Matiash
|
2024-02-14 08:57:02
|
Well, idk why I didn't tried it myself before asking ๐คฆโโ๏ธ Tried -d 10 with -m 0 and 1, and got the idea
|
|