• Welcome to the Chevereto user community!

    Here users from all over the world gather around to learn the latest about Chevereto and contribute with ideas to improve the software.

    Please keep in mind:

    • 😌 This community is user driven. Be polite with other users.
    • 👉 Is required to purchase a Chevereto license to participate in this community (doesn't apply to Pre-sales).
    • 💸 Purchase a Pro Subscription to get access to active software support and faster ticket response times.

Request to add HEIC format image support before V4.

Code is also DCMA protected in the most countries, FYI.. :rolleyes:

And the browsers still not support HEIC/HEIF.... NINJAD by @Rodolfo :cool:

Imgbb doesn't support HEIC as you can see in attachment..
View attachment 4125
a code can only be DMCA if the code is stolen or exactly copied after same layout as the one imgbb uses. But if another site adds PDF and HEIC support then imgbb can try filing a DMCA complaint but if review of source on new site doesen't match layout after one at imgbb then owners of imgbb will mostlikely lose the case and case will be dismissed.

So code cannot allways be DMCA.
 
Off topic!

Before jumping into jurisdictions and a lot of non-sense (and VERY off topic, the topic is about HEIC support not what copyright law means)... Keep in mind that imgbb modified my copyrighted work, not the opposite.
 
Keep in mind that imgbb modified my copyrighted work, not the opposite.
Isn't it allowed to modify your code for themself, but not for sharing?

They extended your code for converting uploaded images from HEIC to whatever.
 
Off topic!

Isn't it allowed to modify your code for themself, but not for sharing?
You can modify it at will, but not re-distribute your modifications (sharing with third-parties). My post was about the alleged copyright infringement, you mentioned that the code can be DMCA protected which I believe is not the case for modified Chevereto V3.X software as you can't re-license my work. Based on that, you can't claim your copyright on modifications made on top of it.

Note that this is only because the current architecture of the software (V3.X) is all glued together, is like soldered components in a computer board (hope makes sense). With V4, we will start going to modules so you will be able to re-distribute these bits of your creation as it will be separate components that merely interact with the core, so is way easier for modifications and to distribute those on your own licensing.
 
So, back to topic, with v4 it would be much easier to implement something like an HEIC converter and share this as a plugin.
 
So, back to topic, with v4 it would be much easier to implement something like an HEIC converter and share this as a plugin.
I don't know how outdated this may be, but to support HEIC to X (jpg, webp, etc) requires ImageMagick with manual provided support for it. A lot of customers can't even get it to work properly (from packages) for the official supported formats so I believe that we are in a very bad stand for getting support for this, also considering the hassle for those wanting to rely in an early implementation that doesn't come with any package maintainer.

With V4 I had the idea to modernize the system provisioning but I'm facing too much resistance to upgrade the machines so I'm not taking from granted that I will have the machine freedom that I wanted, at least not in the first half of the next cycle (V4.X).

In any case, V4 ships with a powerful API so the HEIC to supported_format can happen on client-side, before sending the task to the server. We should seek this, like provide a desktop uploader and leave the web-based upload as failover and focus to solve the problem before it is a problem in the server layer.
 
I don't know how outdated this may be, but to support HEIC to X (jpg, webp, etc) requires ImageMagick with manual provided support for it. A lot of customers can't even get it to work properly (from packages) for the official supported formats so I believe that we are in a very bad stand for getting support for this, also considering the hassle for those wanting to rely in an early implementation that doesn't come with any package maintainer.

Is this still the case today with the latest imagick? Perhaps the best way to handle this would be to add an experimental option in the dashboard for heic conversion support with big bold letters about how to enable it.
 
What you mean by with the latest imagick? Is no a lib the issue, but how package maintainers provide it. If you build it from source it will always work for you.
You're right, it's not provided by default. But it's not hard to compile imagick with the proper support either (just looking at that document).

It would be nice to see support for heic in chevereto but I can see why you're reluctant to add it.
 
Besides the low support due to not being included by default in the package, it requires another layer for handling original + converted. Also, it requires to extend the image handling lib as it doesn't handle any exotic format.

But that doesn't matter, all what matters is how badly is this wanted and there's no RFC for this.

😔 I don't understand why some suggest new features here at Feedback.
 
Back
Top