Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.compression > #2847 > unrolled thread

JPEG announces availablility of CD Text for JPEG XT lossless and alpha

Back to article view | Back to comp.compression

Contents

  JPEG announces availablility of CD Text for JPEG XT lossless and alpha Thomas Richter <thor@math.tu-berlin.de> - 2015-02-06 04:59 +0100
    Re: JPEG announces availablility of CD Text for JPEG XT lossless and alpha BGB <cr88192@hotmail.com> - 2015-02-06 15:52 -0600
      Re: JPEG announces availablility of CD Text for JPEG XT lossless and alpha Thomas Richter <thor@math.tu-berlin.de> - 2015-02-07 10:28 +0100
        Re: JPEG announces availablility of CD Text for JPEG XT lossless and alpha BGB <cr88192@hotmail.com> - 2015-02-07 11:14 -0600
          Re: JPEG announces availablility of CD Text for JPEG XT lossless and alpha Thomas Richter <thor@math.tu-berlin.de> - 2015-02-08 12:54 +0100
            Re: JPEG announces availablility of CD Text for JPEG XT lossless and alpha BGB <cr88192@hotmail.com> - 2015-02-08 08:18 -0600
    Re: JPEG announces availablility of CD Text for JPEG XT lossless and alpha Mark Nelson <snorkelman@gmail.com> - 2015-02-06 14:54 -0800
      Re: JPEG announces availablility of CD Text for JPEG XT lossless and alpha BGB <cr88192@hotmail.com> - 2015-02-06 18:01 -0600
      Re: JPEG announces availablility of CD Text for JPEG XT lossless and alpha Thomas Richter <thor@math.tu-berlin.de> - 2015-02-07 10:24 +0100
    Re: JPEG announces availablility of CD Text for JPEG XT lossless and alpha "Dex" <admin@127.0.0.1> - 2015-02-08 11:36 +0800
      Re: JPEG announces availablility of CD Text for JPEG XT lossless and alpha Thomas Richter <thor@math.tu-berlin.de> - 2015-02-08 06:20 +0100
        Re: JPEG announces availablility of CD Text for JPEG XT lossless and alpha "Dex" <admin@127.0.0.1> - 2015-02-08 15:36 +0800
        Re: JPEG announces availablility of CD Text for JPEG XT lossless and alpha BGB <cr88192@hotmail.com> - 2015-02-08 02:18 -0600
    Re: JPEG announces availablility of CD Text for JPEG XT lossless and alpha Aaron Boxer <boxerab@gmail.com> - 2016-01-26 08:02 -0800
      Re: JPEG announces availablility of CD Text for JPEG XT lossless and alpha Thomas Richter <thor@math.tu-berlin.de> - 2016-01-27 16:04 +0100
        Re: JPEG announces availablility of CD Text for JPEG XT lossless and alpha Aaron Boxer <boxerab@gmail.com> - 2016-01-28 05:02 -0800
        Re: JPEG announces availablility of CD Text for JPEG XT lossless and alpha Aaron Boxer <boxerab@gmail.com> - 2016-01-28 05:02 -0800

#2847 — JPEG announces availablility of CD Text for JPEG XT lossless and alpha

Hi folks,

just some news flash from the latest JPEG meeting here in Sydney. We're 
proud to announce that the CD text (committee draft) of JPEG XT parts 8 
and 9 became available today.

JPEG XT is a whole backward compatible extension to the well-known JPEG 
compression standard for full images, that is, all images compressed in 
this form will be reconstructable by any legacy JPEG decoder.

Part 8 is a lossless extension for JPEG, for bit depths of 8 and beyond, 
including floating point. A legacy decoder will of course only 
reconstruct a lossy 8-bit version of the image, but a XT-8 decoder is 
able to reconstruct to full quality and full bitdepth.

Part 9 adds the long-missing support for alpha channels in JPEG. It 
allows you to compress the opacity information with or without loss, at 
bit depth of 8 or beyond.

A reference implementation of part-8 (still pending changes due to some 
last-minute requests) can be found on our website at http://www.jpeg.org

The implementation will be updated in the near future to support part-9. 
I especially want to thank members of the community for helping to 
define, review and update the CD text, this was a nice experience I 
would prefer to repeat in the future.

In case you want to subscribe to JPEG news, please go to

https://listserv.uni-stuttgart.de/mailman/listinfo/jpeg-news

This is a hassle-free, read-only reflector for our activities.

For JPEG internal discussion on JPEG XT, the committee opened its 
internal mail reflectors for external participation last meeting. You 
can subscribe at:

https://listserv.uni-stuttgart.de/mailman/listinfo/jpeg-extensions

For the latter, please allow a one-week (at most) review process, were 
you will be asked on your motivation and background. That's only to keep 
spammers out of our process.

Thanks a lot and greetings,

Thomas

[toc] | [next] | [standalone]

#2849

On 2/5/2015 9:59 PM, Thomas Richter wrote:
> Hi folks,
>
> just some news flash from the latest JPEG meeting here in Sydney. We're
> proud to announce that the CD text (committee draft) of JPEG XT parts 8
> and 9 became available today.
>
> JPEG XT is a whole backward compatible extension to the well-known JPEG
> compression standard for full images, that is, all images compressed in
> this form will be reconstructable by any legacy JPEG decoder.
>
> Part 8 is a lossless extension for JPEG, for bit depths of 8 and beyond,
> including floating point. A legacy decoder will of course only
> reconstruct a lossy 8-bit version of the image, but a XT-8 decoder is
> able to reconstruct to full quality and full bitdepth.
>
> Part 9 adds the long-missing support for alpha channels in JPEG. It
> allows you to compress the opacity information with or without loss, at
> bit depth of 8 or beyond.
>
> A reference implementation of part-8 (still pending changes due to some
> last-minute requests) can be found on our website at http://www.jpeg.org
>
> The implementation will be updated in the near future to support part-9.
> I especially want to thank members of the community for helping to
> define, review and update the CD text, this was a nice experience I
> would prefer to repeat in the future.
>
> In case you want to subscribe to JPEG news, please go to
>
> https://listserv.uni-stuttgart.de/mailman/listinfo/jpeg-news
>
> This is a hassle-free, read-only reflector for our activities.
>
> For JPEG internal discussion on JPEG XT, the committee opened its
> internal mail reflectors for external participation last meeting. You
> can subscribe at:
>
> https://listserv.uni-stuttgart.de/mailman/listinfo/jpeg-extensions
>
> For the latter, please allow a one-week (at most) review process, were
> you will be asked on your motivation and background. That's only to keep
> spammers out of our process.
>

both lists want can't be read by non-members and require being approved 
it seems...


but, yeah, links to the CD text or similar would be nice, as I wasn't 
able to find anything publicly accessible.


I am mostly interested in how alpha was done in XT.

as-noted, in my variant, I had stuffed another JPEG sub-image into the 
JPEG via APPn markers to encode the alpha channel.


> Thanks a lot and greetings,
>
> Thomas

[toc] | [prev] | [next] | [standalone]

#2855

On 06.02.2015 22:52, BGB wrote:

>>
>
> both lists want can't be read by non-members and require being approved
> it seems...

You need to be subscribed to be able to read it. jpeg-news is open for 
all subscribers, but yes, you need to provide your mail (obviously) and 
your name.

There is a mail archive for subscribers. But, as jpeg-news is new (i.e. 
it didn't exist before yesterday) there isn't anything in it.

> but, yeah, links to the CD text or similar would be nice, as I wasn't
> able to find anything publicly accessible.

We are no longer allowed (ISO regulation) to make the specs available 
for free. I know this is silly, but that is how it is. There is, 
however, a reference implementation on www.jpeg.org (with some changes 
still pending).

> I am mostly interested in how alpha was done in XT.

Pretty trivial stuff. Use the file-format embedding that is defined in 
18477-3, then take a single-channel grey-scale image, embed that into a 
box and mark it as alpha with some signalling syntax. It's really that 
trivial. If you want lossless alpha, then the whole side channel needs 
to be (essentially) JPEG XT part-8.

Greetings,
	Thomas

[toc] | [prev] | [next] | [standalone]

#2859

On 2/7/2015 3:28 AM, Thomas Richter wrote:
> On 06.02.2015 22:52, BGB wrote:
>
>>>
>>
>> both lists want can't be read by non-members and require being approved
>> it seems...
>
> You need to be subscribed to be able to read it. jpeg-news is open for
> all subscribers, but yes, you need to provide your mail (obviously) and
> your name.
>

when I tried registering, "news" also gave a message saying approval was 
needed.


> There is a mail archive for subscribers. But, as jpeg-news is new (i.e.
> it didn't exist before yesterday) there isn't anything in it.
>

ok.


>> but, yeah, links to the CD text or similar would be nice, as I wasn't
>> able to find anything publicly accessible.
>
> We are no longer allowed (ISO regulation) to make the specs available
> for free. I know this is silly, but that is how it is. There is,
> however, a reference implementation on www.jpeg.org (with some changes
> still pending).
>

ok.
annoying.


>> I am mostly interested in how alpha was done in XT.
>
> Pretty trivial stuff. Use the file-format embedding that is defined in
> 18477-3, then take a single-channel grey-scale image, embed that into a
> box and mark it as alpha with some signalling syntax. It's really that
> trivial. If you want lossless alpha, then the whole side channel needs
> to be (essentially) JPEG XT part-8.
>

ok, so I interpret this to mean:
do something similar to what I am already doing (embed another JPEG 
image inside the parent image in APPn markers).

for lossless, mostly I have a marker to indicate use of RDCT and (if 
relevant) the use of an alternate colorspace (mostly N/A for alpha).


as-is, in my case, I have mostly been using my variant for lossy images 
(generally stored at 85 or 90% quality, with quality in the 101-127 
range indicating a few different lossless settings, *).


*: partly as an artifact, in my encoder, I send quality and flags as a 
single integer, with the low bits encoding the quality level, and higher 
bits used as flags.

I have several implementations in existance:
a simpler single-file version, which does lossy RGB+alpha (no layers), 
and only decodes/encodes to RGBA;
an implementation that is much bigger and more complex, and partially 
integrated with a lot of my "BTIC" stuff.


the more complex version supports more features, but a lot have ended up 
rarely used in my case.

one of the more vaguely-relevant features (for use in my 3D engine), is 
direct-decoding to DXTn and BCn, though this is better for faster 
lower-quality encoding (it is actually slightly faster than converting 
to RGBA, as well as it can be sent to the graphics card a little faster 
as well).

for higher quality DXTn or BCn output (better for static images), it is 
needed to decode to RGBA and then use a separate step to convert to DXTn 
or BCn, but this is slower.

much slower is BC7 encoding with block-partitions enabled, which is slow 
enough that (rather than do it each time the image was loaded), I made a 
hacked version of BMP with BC7 image data which is stored 
Deflate-compressed, which was used to store cached versions of the 
images. this is messy, but can give slightly higher image quality than 
when using a faster encoder (which doesn't support block partitions).


one of my more-successful video codec designs for this use-case (BTIC1C) 
was also considered for still images (it being designed mostly for DXTn 
and BCn output), but is incapable of giving full-quality BC7 output, and 
didn't really offer enough over JPEG here to be worthwhile (speed is 
less important, and JPEG wins in terms of superior size/quality for 
still images, although M-JPEG falls behind when it came to animated 
textures or video).

well, and then more recent VQ variants:
BTIC1F, intended mostly to try to be better for, well, video playback 
(mostly by trying to play better with the Deflate/BTLZH backend, and 
using a cheaper strategy for the color endpoints).

BTIC1G, intended mostly for real-time incremental encoding on a 
resource-constrained device (it needs to operate in 10us timesteps on a 
700MHz ARM chip, is limited to around 20% CPU load, and the video is to 
be transmitted piecewise via UDP datagrams over WiFi). (it was this, or 
using a BTIC1C subset, or another RPZA variant, over TCP). the datagrams 
will include a frame-number and starting-block number to help sort 
things out, and will be transmitted once a certain target-size is 
reached, probably without any entropy coding. worst-case bitrate will be 
slightly lower than RPZA (3.5 bpp vs 4.0 bpp), and I suspect perceived 
image quality should be slightly higher.


> Greetings,
>      Thomas
>

[toc] | [prev] | [next] | [standalone]

#2865

Am 07.02.2015 um 18:14 schrieb BGB:

> when I tried registering, "news" also gave a message saying approval was
> needed.

Yes, though the moderation policy is different. You are approved.

For the other mailing list, please don't forget to send the complete 
information (you have mail), but shorter, and with real name.

>> We are no longer allowed (ISO regulation) to make the specs available
>> for free. I know this is silly, but that is how it is. There is,
>> however, a reference implementation on www.jpeg.org (with some changes
>> still pending).
>>
>
> ok.
> annoying.

I know... can't fix the ISO, though.

>> Pretty trivial stuff. Use the file-format embedding that is defined in
>> 18477-3, then take a single-channel grey-scale image, embed that into a
>> box and mark it as alpha with some signalling syntax. It's really that
>> trivial. If you want lossless alpha, then the whole side channel needs
>> to be (essentially) JPEG XT part-8.
>>
>
> ok, so I interpret this to mean:
> do something similar to what I am already doing (embed another JPEG
> image inside the parent image in APPn markers).

Yes, but with an ISO stamp on it.

Greetings,
	Thomas

[toc] | [prev] | [next] | [standalone]

#2867

On 2/8/2015 5:54 AM, Thomas Richter wrote:
> Am 07.02.2015 um 18:14 schrieb BGB:
>
>> when I tried registering, "news" also gave a message saying approval was
>> needed.
>
> Yes, though the moderation policy is different. You are approved.
>
> For the other mailing list, please don't forget to send the complete
> information (you have mail), but shorter, and with real name.
>

yeah...

forgot name, and I don't think I have an affiliation, basically having 
never worked in "the industry", and not currently having a job (and no 
real work experience).

also, where I am living, there is no real software industry stuff, and 
don't want to relocate (would prefer avoid densely populated areas). 
most of what is around where I am living is related to agriculture, and 
the manufacturing and oil industries.


last time I had a job was years ago, once briefly doing IT type stuff 
for a church. currently, most likely I will end up with a maintenance 
type job or similar (currently in college for "mechatronics", which is 
mostly focused on maintaining industrial machinery).

besides classes, IRL, I am also working on things like building custom 
electronics, mostly intended to build robots, but also working some on 
building a CNC milling machine, mostly to make some types of parts. some 
of my other parts are made on a 3D printer.


one of my more recent codec designs is intended mostly to stream video 
data from a robot back to the control program (running on a PC or laptop).

main robot I have now is basically a rolling cardboard box powered by a 
UPS battery.

I had intended to build a large quadrotor (mostly intended for lifting 
things), but this is currently stalled, as the propellers would be 
absurdly expensive, and I basically need to build a CNC mill to make 
them (and they are too big for the 3D printer and would likely need to 
be made of hardwood or similar).


my 3D game project exists, but it kind of sucked, and I never got any 
money from this.


>>> We are no longer allowed (ISO regulation) to make the specs available
>>> for free. I know this is silly, but that is how it is. There is,
>>> however, a reference implementation on www.jpeg.org (with some changes
>>> still pending).
>>>
>>
>> ok.
>> annoying.
>
> I know... can't fix the ISO, though.
>

yep.


>>> Pretty trivial stuff. Use the file-format embedding that is defined in
>>> 18477-3, then take a single-channel grey-scale image, embed that into a
>>> box and mark it as alpha with some signalling syntax. It's really that
>>> trivial. If you want lossless alpha, then the whole side channel needs
>>> to be (essentially) JPEG XT part-8.
>>>
>>
>> ok, so I interpret this to mean:
>> do something similar to what I am already doing (embed another JPEG
>> image inside the parent image in APPn markers).
>
> Yes, but with an ISO stamp on it.
>

yes, ok.

[toc] | [prev] | [next] | [standalone]

#2850

On Thursday, February 5, 2015 at 10:59:30 PM UTC-5, Thomas Richter wrote:
> JPEG XT is a whole backward compatible extension to the well-known JPEG 
> compression standard for full images, that is, all images compressed in 
> this form will be reconstructable by any legacy JPEG decoder.

Here I was imagining there was nothing left to do for JPEG.

This is pretty cool, and making it backwards compatible must have taken a fair amount of ingenuity.

Can't wait to see some implementation.

- Mark

[toc] | [prev] | [next] | [standalone]

#2852

On 2/6/2015 4:54 PM, Mark Nelson wrote:
> On Thursday, February 5, 2015 at 10:59:30 PM UTC-5, Thomas Richter wrote:
>> JPEG XT is a whole backward compatible extension to the well-known JPEG
>> compression standard for full images, that is, all images compressed in
>> this form will be reconstructable by any legacy JPEG decoder.
>
> Here I was imagining there was nothing left to do for JPEG.
>
> This is pretty cool, and making it backwards compatible must have taken a fair amount of ingenuity.
>

luckily, the JPEG format has "some" room for extension (unlike some 
other formats), namely in the form of APPn markers. JPEG decoders can 
safely ignore them if they don't care what they contain, and there are 
some general conventions for avoiding "false positives", namely using 
some sort of marker/tag (such as an ASCIIZ string or FOURCC or similar) 
to identify the type of marker.

so, if you make the format extensions as optional markers, then normal 
decoders can reasonably safely ignore them, and if the basic image looks 
about like what they expect, then it is possible for them to still 
decode the base image.

> Can't wait to see some implementation.
>

dunno about JPEG XT.


I have my own extended JPEG variant (BTJPG), which does "basically 
something similar" (HDR, alpha channel, ...).

for the most part though, I have just ended up using it as a sort of 
lossy PNG alternative.

in my case, it uses a few markers, namely:
APP11, "CompLayer", "Alpha", 0
APP12, FCC("LDAT"), Image Data...
APP12, FCC("LDAT"), ...
...

where the sub-image is basically a mono JPEG in this case, but is FF 
escape-coded, and broken up into pieces and stuffed into the JPEG (APPn 
markers are limited to around 64kB due to only having a 16-bit size).

the APP11 marker there basically indicates that the following image 
(given in the "LDAT" markers) represents an alpha image. otherwise, the 
markers may also be used to give other information.


additonally, there may be an optional "RGB" CompLayer marker, where a 
decoder which uses this format will use this image instead of the base 
image for the RGB components (this is a more friendly way to do lossless 
images in the format, leaving the base image as a lossy version. the 
base image may also be encoded losslessly, but in conventional JPEG 
decoders, the image colors come out slightly-off and a little 
over-saturated due to the use of a different color-space, namely RCT 
instead of YCbCr).


> - Mark
>

[toc] | [prev] | [next] | [standalone]

#2854

On 06.02.2015 23:54, Mark Nelson wrote:
>
> This is pretty cool, and making it backwards compatible must have taken a fair amount of ingenuity.

It's actually not so complicated. There are two models for lossless 
encoding, an "open loop model" that requires a 1-1 integer DCT, and a 
"closed loop model" that requires an additional residual side channel 
that is embedded into the APPx markers.

> Can't wait to see some implementation.

Go to www.jpeg.org, there on JPEG XT, and you'll find a (preliminary) 
reference implementation.

Greetings,
	Thomas

[toc] | [prev] | [next] | [standalone]

#2861

So now if I may, allow me to ask the obvious Joe User question :-) ...
Now that it does transparency, how does JPEG XT compare with GIF and PNG?
I see that JPEG XT has no animation, so there's one difference



--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#2862

On 08.02.2015 04:36, Dex wrote:
> So now if I may, allow me to ask the obvious Joe User question :-) ...
> Now that it does transparency, how does JPEG XT compare with GIF and PNG?

Same ballpark. But that goes for any lossless compression, it is always 
approximately 2:1, no matter what you do.

> I see that JPEG XT has no animation, so there's one difference

No, not in this part. Is there much use of animation? Would we need it? 
There is always a possibility to extend it for animation, but I probably 
don't quite see the point. There are many better formats for animated 
pictures (aka movies) right now.

Greetings,
	Thomas

[toc] | [prev] | [next] | [standalone]

#2863

>> I see that JPEG XT has no animation, so there's one difference
>
> No, not in this part. Is there much use of animation? Would we need it? 
> There is always a possibility to extend it for animation, but I probably 
> don't quite see the point. There are many better formats for animated 
> pictures (aka movies) right now.

I agree with you that there's no need for animation, I was just using that 
as a (quickly n poorly thought) example of differences



--- news://freenews.netfront.net/ - complaints: news@netfront.net ---

[toc] | [prev] | [next] | [standalone]

#2864

On 2/7/2015 11:20 PM, Thomas Richter wrote:
> On 08.02.2015 04:36, Dex wrote:
>> So now if I may, allow me to ask the obvious Joe User question :-) ...
>> Now that it does transparency, how does JPEG XT compare with GIF and PNG?
>
> Same ballpark. But that goes for any lossless compression, it is always
> approximately 2:1, no matter what you do.
>

personally, I have seen some variation, but it is hit-or-miss.
for example, PNG does a bit better with some types of images, and a 
lossless JPEG variant does better with different images.

granted, yes, there is a limit as to how much something can be 
compressed losslessly.


>> I see that JPEG XT has no animation, so there's one difference
>
> No, not in this part. Is there much use of animation? Would we need it?
> There is always a possibility to extend it for animation, but I probably
> don't quite see the point. There are many better formats for animated
> pictures (aka movies) right now.
>

yeah.

for my JPEG variant, I had stuck it in an AVI container and used this 
for animations (in my 3D engine, if an AVI is used as a texture, it is 
interpreted as being a looping animation).

stuffing things in an AVI personally makes more sense then having to 
develop a special animated version of a given file-format (and, if 
really needed, a person could just give the AVI a different 
file-extension or something).


though, lack of interframe compression with JPEG can quickly become a 
problem (since every frame has a complete image, it doesn't really scale 
well to longer sequences).


not sure why AVI never really caught on for short looping animations.

though, yes, many conventional video codecs aren't really ideally suited 
to the short-animated-loop use-case either (as-in, using it like an 
animated GIF).

some of my custom codecs are derived from old-style video codecs, and 
work pretty good for short animations, though bitrate becomes a little 
more of an issue for longer sequences.

what works best for a 5 second loop, is not necessarily the best option 
for a 5 minute video. but, what works good for a 5 minute video, may 
also pose significant overhead if a large number of them are playing at 
the same time (favoring an emphasis on low decoder complexity).

[toc] | [prev] | [next] | [standalone]

#3365

Have you guys thought of hosting the reference software on Github?  Would you take pull requests for changes ?




On Thursday, February 5, 2015 at 10:59:30 PM UTC-5, Thomas Richter wrote:
> Hi folks,
> 
> just some news flash from the latest JPEG meeting here in Sydney. We're 
> proud to announce that the CD text (committee draft) of JPEG XT parts 8 
> and 9 became available today.
> 
> JPEG XT is a whole backward compatible extension to the well-known JPEG 
> compression standard for full images, that is, all images compressed in 
> this form will be reconstructable by any legacy JPEG decoder.
> 
> Part 8 is a lossless extension for JPEG, for bit depths of 8 and beyond, 
> including floating point. A legacy decoder will of course only 
> reconstruct a lossy 8-bit version of the image, but a XT-8 decoder is 
> able to reconstruct to full quality and full bitdepth.
> 
> Part 9 adds the long-missing support for alpha channels in JPEG. It 
> allows you to compress the opacity information with or without loss, at 
> bit depth of 8 or beyond.
> 
> A reference implementation of part-8 (still pending changes due to some 
> last-minute requests) can be found on our website at http://www.jpeg.org
> 
> The implementation will be updated in the near future to support part-9. 
> I especially want to thank members of the community for helping to 
> define, review and update the CD text, this was a nice experience I 
> would prefer to repeat in the future.
> 
> In case you want to subscribe to JPEG news, please go to
> 
> https://listserv.uni-stuttgart.de/mailman/listinfo/jpeg-news
> 
> This is a hassle-free, read-only reflector for our activities.
> 
> For JPEG internal discussion on JPEG XT, the committee opened its 
> internal mail reflectors for external participation last meeting. You 
> can subscribe at:
> 
> https://listserv.uni-stuttgart.de/mailman/listinfo/jpeg-extensions
> 
> For the latter, please allow a one-week (at most) review process, were 
> you will be asked on your motivation and background. That's only to keep 
> spammers out of our process.
> 
> Thanks a lot and greetings,
> 
> Thomas

[toc] | [prev] | [next] | [standalone]

#3366

On 26.01.2016 17:02, Aaron Boxer wrote:
> Have you guys thought of hosting the reference software on Github?  Would you take pull requests for changes ?

It is on github:

https://github.com/thorfdbg/libjpeg

Greetings,
	Thomas

[toc] | [prev] | [next] | [standalone]

#3367

On Wednesday, January 27, 2016 at 10:04:39 AM UTC-5, Thomas Richter wrote:
> On 26.01.2016 17:02, Aaron Boxer wrote:
> > Have you guys thought of hosting the reference software on Github?  Would you take pull requests for changes ?
> 
> It is on github:
> 
> https://github.com/thorfdbg/libjpeg
> 
> Greetings,
> 	Thomas

ahhh, thanks.  

Also, I like Diff test next generation, exactly the tool I have been looking for. Thanks for making this public.

Aaron

[toc] | [prev] | [next] | [standalone]

#3368

On Wednesday, January 27, 2016 at 10:04:39 AM UTC-5, Thomas Richter wrote:
> On 26.01.2016 17:02, Aaron Boxer wrote:
> > Have you guys thought of hosting the reference software on Github?  Would you take pull requests for changes ?
> 
> It is on github:
> 
> https://github.com/thorfdbg/libjpeg
> 
> Greetings,
> 	Thomas

ahhh, thanks.  

Also, I like Diff test next generation, exactly the tool I have been looking for. Thanks for making this public.

Aaron

[toc] | [prev] | [standalone]

Back to top | Article view | comp.compression

csiph-web