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

DeepSeek OCR

github.com

Post reply on HN
Print view View original

231–240 of 252 posts

Re: DeepSeek OCR

#231

Post by emptyhandeddev »

numpad0 wrote: post #75
jdthedisciple wrote: post #39

Earlier quoted context omitted.

Sibling comment has the second part as 後天下之樂而樂 Which one is correct?

a) 后天下之乐而乐 b) 後天下之樂而樂 c) 後天下之楽而楽 a) is clearly Simplified Chinese from a sibling comment, b) is Traditional copied from your comment, and c) is as I just typed in my own language. Unicode Hanzi/Kanji are a mess and there are characters same or different, in appearance or in binary, depending on intended variants, languages, fonts, systems, keyboard, distance between Earth and Alpha Centauri, etc.

a) Simplified Chinese

b) Traditional Chinese

c) 楽 is a variation of 樂, which is now widely used in Japanese Kanji but deprecated in Traditional Chinese.

Note:

A variation means some people write 樂 as 楽 in ancient China, but not widely adopted.

Kanji is a Japanese word, means "Chinese Character".

Re: DeepSeek OCR

#232

Post by Thma »

Is this only at the level of visual compression? For example, are there any applications in terms of understanding (being able to represent the actual meaning it stands for) and reasoning? Technically, it seems to have no connection with current reinforcement learning and other techniques. The model is quite small, yet there appears to be no explanation regarding its understanding capabilities. If it is merely for compression, what impact will it have on the current large models?

Re: DeepSeek OCR

#233

Post by emptyhandeddev »

Y_Y wrote: post #74
jdthedisciple wrote: post #38

Earlier quoted context omitted.

Sibling comment has the second part as 后天下之乐而乐 which one is correct?

It depends on who you think is the rightful successor to the Qing dynasty

Wrong. It merely depends on whether the local policy maker before computer age prioritize reducing illiteracy and convenience over other considerations.

Macau, HK and Taiwan uses traditional Chinese character.

Mainland China, Singapore, Malaysia use simplified Chinese character.

Japan uses its own version, some simplified, some traditional, and also invented over 100 Japanese-made-Kanji following the same logic how Chinese characters are formed.

As a matter of fact, simplification of Chinese characters started when KMT/Republic of China was in control of the whole China. Politics gets in the way later and RoC stopped this simplification process while PRC kept it going, Macau & HK were not involved since the Portuguese and British colonial government doesn't care. Singapore and Malaysia pick the simplified version out of convenience.

Re: DeepSeek OCR

#234

Post by est »

_vqpz wrote: post #93
ellisd wrote: post #36

The paper makes no mention of Anna’s Archive. I wouldn’t be surprised if DeepSeek took advantage of Anna’s offer granting OCR researchers access to their 7.5 million (350 TB) Chinese non-fiction collection ... which is bigger than Library Genesis. https://annas-archive.org/blog/duxiu-exclusive.html

Why do they need to grant access for people to use copies of books they don’t own?

> The books from Duxiu have long been pirated on the Chinese internet. Usually they are being sold for less than a dollar by resellers. They are typically distributed using the Chinese equivalent of Google Drive, which has often been hacked to allow for more storage space

Ownership laundering.

Re: DeepSeek OCR

#235

Post by ah27182 »

graeme wrote: post #177
hakunin wrote: post #116

Earlier quoted context omitted.

Wish someone benchmarked Apple Vision Framework against these others. It's built into most Apple devices, but people don't know you can actually harness it to do fast, good quality OCR for you (and go a few extra steps to produce searchable pdfs, which is my typical use case). I'm very curious where it would fall in the benchmarks.

Interesting. How do you harness it for that purpose? I've found apple ocr to be very good.

Apple shortcuts allows you to use OCR on images you pass into it. Looking for “ Extract Text from Image”

Re: DeepSeek OCR

#236

Post by rsp1984 »

intalentive wrote: post #224
rsp1984 wrote: post #152

Can someone ELI5 to me (someone who doesn't have the time to keep up with all the latest research) what this is and why it's a big deal? It's very hard to guess from the github and paper. For example, there is OCR in the title but the abstract and readme.md talk about context compression for LLMs, which I find confusing. Somebody care to explain the link and provide some high-level context?

Suppose you have an image with 1000 words in it, and suppose for simplicity that every word is 1 token. Then the image is “worth” 1000 tokens. But under the hood, the image will have to be transformed into features / embeddings before it can be decoded into text. Suppose that the image gets processed into 100 “image tokens”, which are subsequently decoded into 1000 “text tokens”. Now forget that we are even talking a…

Excellent, thanks. So basically this is saying: "our pixels-to-token encoding is so efficient (information density in a set of "image tokens" is much higher as compared to a set of text tokens), why even bother representing text as text?"

Correct?

Re: DeepSeek OCR

#237

Post by Werkzeug »

imjonse wrote: post #17
krackers wrote: post #11

Earlier quoted context omitted.

But naively wouldn't you expect the representation of a piece of text in terms of vision tokens to be roughly the same number of bits (or more) than the representation as textual token? You're changing representation sure, but that by itself doesn't give you any compute advantages unless there is some sparsity/compressability you can take advantage of in the domain you transform to right? So I guess my question is wh…

I wonder if text written using chinese characters is more compatible with such vision centric compression than latin text.

I think it's not the case. Chinese characters have the highest information entropy of all writing systems. However, Chinese characters are all independent symbols, which means if you want the LLM to support 5000 Chinese characters, you need to put 5000 characters into the lookup table (obviously there's no root, prefix, and suffix in Chinese, you cannot split the character into multiple reusable word pieces). As a result, you may need fewer characters to represent the same meaning compared to latin languages, but LLMs may also need to activate more token embeddings.

Re: DeepSeek OCR

#238

Post by h14h »

This feels like another one of those stairstep ML/AI advances that makes computers behave eerily more like humans.

We tend to think in images rather than plaintext, and here we are discovering it's more efficient for a computer to do so as well.

Re: DeepSeek OCR

#239

Post by mapleshamrock »

psb217 wrote: post #37
krackers wrote: post #11

Earlier quoted context omitted.

But naively wouldn't you expect the representation of a piece of text in terms of vision tokens to be roughly the same number of bits (or more) than the representation as textual token? You're changing representation sure, but that by itself doesn't give you any compute advantages unless there is some sparsity/compressability you can take advantage of in the domain you transform to right? So I guess my question is wh…

The trick is that the vision tokens are continuous valued vectors, while the text tokens are elements from a small discrete set (which are converted into continuous valued vectors by a lookup table). So, vision tokens can convey significantly more bits per token than text tokens. This allows them to pack the content of multiple text tokens into a single vision token.

Couldn't you do something like add a bidirectional encoder after your embedding look up table to compress your text into some smaller token-count semantic space before feeding your transformer blocks to get a similar effect, then?

Re: DeepSeek OCR

#240

Post by intalentive »

rsp1984 wrote: post #236
intalentive wrote: post #224

Earlier quoted context omitted.

Suppose you have an image with 1000 words in it, and suppose for simplicity that every word is 1 token. Then the image is “worth” 1000 tokens. But under the hood, the image will have to be transformed into features / embeddings before it can be decoded into text. Suppose that the image gets processed into 100 “image tokens”, which are subsequently decoded into 1000 “text tokens”. Now forget that we are even talking a…

Excellent, thanks. So basically this is saying: "our pixels-to-token encoding is so efficient (information density in a set of "image tokens" is much higher as compared to a set of text tokens), why even bother representing text as text?" Correct?

Basically. Some people are even saying, hey, if you encode text as an image then you don’t need tokenizers any more, and you get more expressivity from the graphic styling.

Another takeaway is that you don’t need to pass a tensor of shape (batch_size, sequence_length, d_model) through your transformer. Not every token needs its own dedicated latent embedding. You can presumably get away with dividing sequence_length by a constant.

This isn’t super ground breaking but it does reinforce the validity of a middle ground between recurrent models, where context is compressed into a single “memory token”, and transformers, where context is uncompressed. 1 < n/k < n

Post reply on HN