Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Understanding and writing a JPEG decoder in Python

yasoob.me

Post reply on HN
Print view View original

21–30 of 48 posts

Re: Understanding and writing a JPEG decoder in Python

#21

Post by kerkeslager »

pansa2 wrote: post #16
kerkeslager wrote: post #14

Earlier quoted context omitted.

I think being executable is really key, because one way I check my understanding of code is to make modifications to the code and see if they do what I expect them to do.

IMO the ideal setup would be for an article to contain pseudocode and to have supplementary executable code. This would allow the article to explain concepts without boilerplate and unnecessary details, but also ensure that those details are available for readers who wish to investigate further. I still think it's an advantage to write the executable code as close to pseudocode as possible. There is further discussio…

So, what elements of Python do you consider boilerplate?

I say this not as someone defending Python, but as someone writing a programming language.

Re: Understanding and writing a JPEG decoder in Python

#23

Post by smabie »

userbinator wrote: post #10
enriquto wrote: post #8

Earlier quoted context omitted.

> Even if you do write code, it is in C/C++ and not accessible to a wide group of people. To be honest, writing a jpeg decoder in C seems easier and more natural than doing it in python.

As someone who has done it in C, I would both agree and disagree --- reading the file format will definitely be easier since C lets you pick bits/bytes/words/etc. off the stream directly, but on the other hand the high-level structures (looping, etc.) would probably be easier with Python. Overall, seeing as OP's Python implementation is less than 300 LoC while my C implementation was closer to 750, the Python might b…

Using Haskell and a parser combinator would probably be the easiest

Re: Understanding and writing a JPEG decoder in Python

#24

Post by pjmlp »

yasoob wrote: post #2

Hi everyone! OP here. Why write another article on JPEG when there are already hundreds of articles on the internet? Well, normally when you read articles on JPEG, the author just gives you details about what the format looks like. You don’t implement any code to do the actual decompression and decoding. Even if you do write code, it is in C/C++ and not accessible to a wide group of people. I tried to change that thr…

Very good article, congratulations on doing it and choosing a more approachable language as well.

Re: Understanding and writing a JPEG decoder in Python

#25

Post by smabie »

kerkeslager wrote: post #21
pansa2 wrote: post #16

Earlier quoted context omitted.

IMO the ideal setup would be for an article to contain pseudocode and to have supplementary executable code. This would allow the article to explain concepts without boilerplate and unnecessary details, but also ensure that those details are available for readers who wish to investigate further. I still think it's an advantage to write the executable code as close to pseudocode as possible. There is further discussio…

So, what elements of Python do you consider boilerplate? I say this not as someone defending Python, but as someone writing a programming language.

Lack of function currying and anonymous function arguments. Also having to explicitly convert a zip, map, etc to a list. Also the lambda keyword.

Re: Understanding and writing a JPEG decoder in Python

#26

Post by enriquto »

smabie wrote: post #23
userbinator wrote: post #10

Earlier quoted context omitted.

As someone who has done it in C, I would both agree and disagree --- reading the file format will definitely be easier since C lets you pick bits/bytes/words/etc. off the stream directly, but on the other hand the high-level structures (looping, etc.) would probably be easier with Python. Overall, seeing as OP's Python implementation is less than 300 LoC while my C implementation was closer to 750, the Python might b…

Using Haskell and a parser combinator would probably be the easiest

Easier for whom? Most programmers would not be able to follow that code. On the other hand, a really simple C or Python algorithm is more or less universally readable.

Re: Understanding and writing a JPEG decoder in Python

#27

Post by deepaksurti »

userbinator wrote: post #12
yasoob wrote: post #2

Hi everyone! OP here. Why write another article on JPEG when there are already hundreds of articles on the internet? Well, normally when you read articles on JPEG, the author just gives you details about what the format looks like. You don’t implement any code to do the actual decompression and decoding. Even if you do write code, it is in C/C++ and not accessible to a wide group of people. I tried to change that thr…

It's great to see more people complete the "JPEG decoder challenge" --- and document it too. Have you read the official T.81 spec[1]? It is one of the easier standards to read, and it has flowcharts of all the algorithms which mean you can implement without really understanding the theory. As you mentioned there are lots of other articles about writing JPEG decoders, as well as for the other popular image formats GIF…

And have more fun by doing the encoding/decoding on GPU [1]

[1] https://github.com/CESNET/GPUJPEG

Re: Understanding and writing a JPEG decoder in Python

#28

Post by cgrealy »

yasoob wrote: post #2

Hi everyone! OP here. Why write another article on JPEG when there are already hundreds of articles on the internet? Well, normally when you read articles on JPEG, the author just gives you details about what the format looks like. You don’t implement any code to do the actual decompression and decoding. Even if you do write code, it is in C/C++ and not accessible to a wide group of people. I tried to change that thr…

> Even if you do write code, it is in C/C++ and not accessible to a wide group of people.

Eh??

There are literally millions of C++ programmers and high quality C++ compilers are available on almost every platform for free.

How is that “not accessible”?

Re: Understanding and writing a JPEG decoder in Python

#29

Post by smcl »

cgrealy wrote: post #28
yasoob wrote: post #2

Hi everyone! OP here. Why write another article on JPEG when there are already hundreds of articles on the internet? Well, normally when you read articles on JPEG, the author just gives you details about what the format looks like. You don’t implement any code to do the actual decompression and decoding. Even if you do write code, it is in C/C++ and not accessible to a wide group of people. I tried to change that thr…

> Even if you do write code, it is in C/C++ and not accessible to a wide group of people. Eh?? There are literally millions of C++ programmers and high quality C++ compilers are available on almost every platform for free. How is that “not accessible”?

Equally there are millions who don't use C or C++. I think it’s pretty fair to describe this as a "wide group of people" who would consider C or C++ inaccessible.

Re: Understanding and writing a JPEG decoder in Python

#30

Post by pansa2 »

kerkeslager wrote: post #21
pansa2 wrote: post #16

Earlier quoted context omitted.

IMO the ideal setup would be for an article to contain pseudocode and to have supplementary executable code. This would allow the article to explain concepts without boilerplate and unnecessary details, but also ensure that those details are available for readers who wish to investigate further. I still think it's an advantage to write the executable code as close to pseudocode as possible. There is further discussio…

So, what elements of Python do you consider boilerplate? I say this not as someone defending Python, but as someone writing a programming language.

It’s not so much that Python requires boilerplate - all executable code does. For example, the article includes code to read the input data from a file, which is not relevant to the algorithm and could be omitted from a pseudocode version.

Similarly, executable code requires unnecessary detail, like the article’s `Stream` class. In pseudocode this could be replaced by simply saying “get the next N bits”.

Post reply on HN